Üzleti logika

A számítógépes szoftverekben az üzleti logika (másképpen ügyviteli logika) a program azon része, amely a valós üzleti szabályokat kódolja, amelyek meghatározzák, hogyan lehet adatokat létrehozni, tárolni és megváltoztatni. Ellentétben a szoftver többi részével, azaz az adatbázist kezelő vagy a felhasználói felületet megjelenítő réteggel, ez a réteg a rendszerinfrastruktúra megjelenítésének vagy általánosságban a program különböző részeinek összekapcsolásának alacsonyabb szintű részleteivel foglalkozik.

Üzleti logika:

• Leírja, hogy az üzleti objektumok hogyan lépnek kapcsolatba egymással
• Meghatározza azokat az útvonalakat és módszereket, amelyekkel az üzleti objektumokat elérik és frissítik

Üzleti szabályok:

• A valós üzleti objektumok (például számlák, kölcsönök, útitervek és készletek) modellezése

Az üzleti logika a következőket tartalmazza:^[1]

• Munkafolyamatok, amelyek a dokumentumok vagy adatok egyik résztvevőtől (egy személytől vagy egy szoftverrendszertől) a másikhoz történő továbbításának rendezett feladatai.

Az üzleti logikát meg kell különböztetni az üzleti szabályoktól.^[2] Az üzleti logika a vállalati rendszer azon része, amely meghatározza az adatok átalakításának vagy kiszámításának módját, valamint az emberekhez vagy a szoftverekhez történő továbbítás módját (munkafolyamat). Az üzleti szabályok az üzletpolitika hivatalos kifejezése. Bármi, ami folyamat vagy eljárás, üzleti logika, és bármi, ami nem folyamat vagy eljárás, üzleti szabály. Az új látogatók fogadása egy folyamat (munkafolyamat), amely lépésekből áll, míg üzleti szabály, hogy minden új látogatót üdvözölni kell. Továbbá az üzleti logika procedurális, míg az üzleti szabályok deklaratívak.^[3]

Például egy e-kereskedelmi webhely lehetővé teheti a látogatók számára, hogy tételeket vegyenek fel a bevásárlókosárba, megadják a szállítási címet és megadják a fizetési információkat. A webhely üzleti logikája tartalmazhat olyan munkafolyamatot, mint például:

• A fizetés során bekövetkező események sorrendje, például egy többoldalas űrlap, amely először a szállítási címet kéri, majd a számlázási címet, a következő oldalon a fizetési mód lesz, az utolsó oldalon pedig a rendelés befejezése.

A weboldalnak üzleti szabályai is lesznek:

• Ha egy elemet többször is hozzáad a kosárhoz, akkor nő az adott tétel mennyisége.
• Meghatározott formátumok, melyeket a látogató címének, e-mail-címének és hitelkártyaadatainak követniük kell.
• Speciális kommunikációs protokoll a hitelkártyához kapcsolódó hálózattal

A webhely szoftvere más kódokat is tartalmaz, amelyek nem tekinthetők az üzleti logika vagy az üzleti szabályok részének:

• Az üzleti alapadatokhoz nem kapcsolódó perifériás tartalom, például a webhely színét, megjelenését, háttérképét és navigációs struktúráját meghatározó HTML
• Általános hibakezelő kód (pl. amely megjeleníti a HTTP hibakód 500. oldalt)
• Inicializáló kód, amely akkor fut le, amikor a webszerver elindítja a webhelyet, amely felállítja a rendszert
• Az infrastruktúra figyelése annak biztosítása érdekében, hogy a webhely minden része megfelelően működjön (pl. rendelkezésre áll a számlázási rendszer)
• Általános kód hálózati kapcsolatok létrehozására, objektumok továbbítására az adatbázisba, a felhasználó bemenetének elemzése HTTP POST eseményeken keresztül stb.

Az üzleti logika bárhol lehet egy programban. Például egy cím bizonyos formátumával létrehozható egy adatbázistábla, amelynek oszlopai pontosan megfelelnek az üzleti logikában megadott mezőknek, és típusellenőrzéseket adhatunk hozzá, hogy megbizonyosodjunk arról, hogy érvénytelen adatokat nem adunk hozzá.

Az üzleti logika gyakran változik. Például az engedélyezett címformátumok halmaza megváltozhat, amikor egy online kereskedő termékeket kezd szállítani egy új országba. Ezért gyakran kívánatosnak tartják, hogy az üzleti logikát megvalósító kód viszonylag elszigetelt vagy lazán legyen összekapcsolva. Ez valószínűbbé teszi, hogy az üzleti logika megváltoztatásához kis számú kódváltozásra lesz szükség. A távoli, de erősen összekapcsolt kód nagyobb kockázatot jelent arra nézve is, hogy a programozó csak néhány szükséges változtatást végrehajt, és kihagyja a rendszer egy részét, ami helytelen működéshez vezet.^[4]

A többlépcsős architektúra ezt a szétválasztást formalizálja egy olyan üzleti logikai réteg létrehozásával, amely elkülönül a többi szinttől vagy rétegtől, például az adatelérési rétegtől vagy a szolgáltatási rétegtől. Minden réteg csak minimális mennyiséget "tud" a többi réteg kódjáról - éppen annyit, amennyi a szükséges feladatok elvégzéséhez szükséges. Például egy Modell-nézet-vezérlő paradigmában a vezérlő és a nézet rétegek a lehető legkisebbek, az összes üzleti logika a modellben összpontosul. Az e-kereskedelmi példában a vezérlő meghatározza a weblapok sorrendjét a fizetési sorrendben, és felelős azért is, hogy az e-mail, a cím és a fizetési információk megfeleljenek az üzleti szabályoknak (ahelyett, hogy bármelyiket magára az adatbázisra hagyná vagy egy alacsonyabb szintű adatbázis-hozzáférési kódra).

Alternatív paradigmák lehetségesek. Például viszonylag egyszerű üzleti entitásokkal egy általános nézet és vezérlő hozzáférhet az adatbázis-objektumokhoz, amelyek maguk tartalmazzák az összes releváns üzleti logikát arról, hogy milyen formátumokat fogadnak el és milyen változtatások lehetségesek (az úgynevezett adatbázis-modell).

Egyes többszintű sémák vagy különálló alkalmazási réteget vagy szolgáltatási réteget használnak, vagy az üzleti logikai réteget azonosnak tekintik ezekével.

Az üzleti logika kivonható az eljárási kódból egy üzleti szabálykezelő rendszer (BRMS) segítségével.^[5]

A szoftverfejlesztés üzleti szabályainak szemlélete BRMS-eket használ, és kényszeríti a nagy erős elválasztást az üzleti logikát és az egyéb kódoktól. A felhasználói felület kezelő rendszerei egy másik technológia, amelyet az üzleti logika és az egyéb kódok közötti szoros elválasztás érvényesítésére használnak. A mágikus gomb antimintának számít: olyan technika, amely ebben az esetben nemkívánatos korlátokat hoz létre, amelyek megnehezítik az üzleti logika könnyen karbantartható kódolását.

A domain modell az üzleti szabályok által megkövetelt adattárolási típusok elvont ábrázolása.

Ez a szócikk részben vagy egészben a Business logic című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

• Brett McLaughlin. Business Logic, Part 1, Building Java Enterprise Applications, Vol I: Architecture. O'Reilly and Associates (2002. március 1.). ISBN 0-596-00123-1  — McLaughlin discusses the façade pattern for implementing the business layer of an application.
• Kathy Bohrer (1997. november 1.). „Middleware isolates business logic”. Object Magazine, New York, USA 7 (9), 41–46. o, Kiadó: SIGS Publications, Inc.. ISSN 1055-3614. 
• Harumi Kuno (2001. december 7.). „Conversations + Interfaces = Business Logic”., Springer Berlin / Heidelberg. 
• Volker Turau. „A framework for automatic generation of web-based data entry applications based on XML”., ACM Press.  — Turau presents an application framework implemented using Java Servlets and JavaServer Pages that enables the separation between business logic and presentation logic, allowing development of each to proceed in parallel along relatively independent but cooperating tracks.
• Pau, L.-F. (2003. december 8.). „Network-based business process management: embedding business logic in communications networks”, Kiadó: Erasmus University.  — Pau and Vervest develop an approach for the embedding of business logic into the communications network that underlies a distributed application with a multiplicity of actors, in order to optimise the allocation of business resources from a network point of view.

• Üzleti réteg irányelvek