Tartományvezérelt tervezés

A Wikipédiából, a szabad enciklopédiából
(Domain-driven design szócikkből átirányítva)

A tartományvezérelt tervezés vagy tartományalapú tervezés[1] (angolul: Domain Driven Design, röviden DDD) egy fontos szoftverfejlesztési módszertan, melyben az architektúra elemei (modulok, objektumok, metódusok stb) elnevezésükben és szerkezetükben lekövetik annak a területnek, iparágnak, hivatalnak, kutatásnak a terminológiáját és szemléletét (ez maga a tartomány, vagyis domain), melyhez a szoftver készül. Így a fejlesztők és a terület szakértői „egy nyelvet beszélnek”, sokkal egyszerűbb a közös gondolkodás, és a szoftver természetesebben illeszkedik a terület mindennapjaihoz. A DDD-vel a területen bekövetkező változásokra is jobban tud reagálni a fejlesztőcsapat.[2]

A tartományvezérelt tervezés a következő célkitűzéseken alapul:

  • a projekt elsődleges fókuszának az alapvető tartományra és a tartományi logikára való helyezése
  • az összetett terveknek a tartomány modelljére való alapozása
  • kreatív együttműködés kezdeményezése a műszaki és a szakterületi szakértők között egy olyan koncepcionális modell iteratív finomítása érdekében, amely a szakterület konkrét problémáira ad választ

A tartományvezérelt tervezés során a szoftverkód szerkezetének és nyelvének (osztályok nevei, metódusai, változói) megfelelnek az üzleti területnek. Például ha egy szoftver hitelkérelmeket dolgoz fel, akkor lehetnek olyan osztályai, mint Hitelkérelem, Ügyfelek, és olyan metódusai, mint Ajánlat_elfogadása és Visszavonás.

A kifejezés Eric Evans Domain Driven Design című könyvéből származik.[3]

Fogalmak[szerkesztés]

A modell legfontosabb alapfogalmai a következők:[3]

  • Kontextus: a környezet, amelyben egy szó vagy állítás szerepel. Behatárolja az adott szó vagy állítás jelentését
  • Tartomány: a tevékenység tárgyköre, szférája (ontológia)
  • Modell: absztrakt struktúra, amely leírja a tartomány valamely aspektusát, és a tartományhoz kapcsolódó problémák megoldásához használható
  • Általános nyelv: terminológia, amely a tartománymodell köré van felépítve. Minden szereplő ezt a közös terminológiát használja

Áttekintés[szerkesztés]

A tartományvezérelt tervezés számos magas szintű koncepciót és gyakorlatot fogalmaz meg.[4] Elsődleges fontosságú a tartomány, az a tárgykör, amelyre a felhasználó egy számítógépes programot alkalmaz. A szoftver tartománya szabályozza a kontextust, azt a környezetet, amelyben egy szó vagy állítás megjelenik, és amely meghatározza annak jelentését. Ebből a fejlesztők felépítenek egy tartománymodellt: egy olyan absztrakciós rendszert, amely leírja a tartomány kiválasztott aspektusait, és amely felhasználható az adott tartományhoz kapcsolódó problémák megoldására.

A tartományvezérelt tervezés ezen aspektusainak célja, hogy elősegítsék egy olyan „általános nyelv” (ubiquitous language) kialakítását, amelyet a terület szakértői, a felhasználók és a fejlesztők használhatnak, és amelyet a tartománymodellhez és a rendszerkövetelmények leírásához használnak. Ez a nyelv a DDD egyik pillére a stratégiai tervezés és a taktikai tervezés mellett.

A tartományvezérelt tervezésben a tartományi réteg az objektumorientált többrétegű architektúra egyik közös rétege.

Modelltípusok[szerkesztés]

A területvezérelt tervezés többféle modellt ismer. Az entitás például egy olyan objektum, amelyet nem az attribútumai, hanem az identitása határoz meg. A legtöbb légitársaság például minden járaton egyedi számot rendel az ülőhelyekhez: ez az ülőhely identitása. Ezzel szemben az értékobjektum olyan megváltoztathatatlan objektum, amely attribútumokat tartalmaz, de nincs fogalmi identitása. Amikor az emberek például névjegykártyákat cserélnek, csak a kártyán lévő információkkal (attribútumokkal) törődnek, nem pedig azzal, hogy megpróbálják megkülönböztetni az egyes egyedi kártyákat.

A modellek meghatározhatnak eseményeket is (valami, ami a múltban történt). A tartományi esemény olyan esemény, amellyel a tartomány szakértői foglalkoznak.

A modelleket össze lehet kötni egy gyökérentitással, hogy aggregátummá váljanak. Az aggregátumon kívüli objektumok hivatkozhatnak a gyökérre, de az aggregátum más objektumaira nem. A gyökér-aggregátum ellenőrzi az aggregátumban bekövetkező változások konzisztenciáját. A sofőröknek például nem kell külön-külön irányítaniuk egy autó minden egyes kerekét: egyszerűen csak vezetik az autót. Ebben az összefüggésben az autó több más objektum (motor, fékek, fényszórók stb) aggregátuma.

Modellekkel való munka[szerkesztés]

A tartományvezérelt tervezésben az objektum létrehozása gyakran elkülönül magától az objektumtól.

A tároló (repository) például egy olyan objektum, amely metódusokkal rendelkezik a tartományi objektumok adattárolóból (pl. adatbázisból) történő lekérdezésére. Hasonlóképpen, a gyár (factory) egy olyan objektum, amelynek módszerei közvetlenül a tartományi objektumok létrehozására (példányosítására) szolgálnak.

Ha egy program funkcionalitásának egy része fogalmilag nem tartozik egyetlen objektumhoz sem, akkor azt általában szolgáltatásként fogalmazzák meg.

Más megközelítésekhez való viszony[szerkesztés]

Bár a tartományvezérelt tervezés nem kötődik eredendően az objektumorientált megközelítésekhez, a gyakorlatban kihasználja az ilyen technikák előnyeit. Ezek közé tartoznak a gyökér-entitások/aggregátumok, mint a parancsok/metódusok hívásainak címzettjei, az állapot egységbe zárása a legfontosabb gyökér-aggregátumokon belül, és magasabb architekturális szinten a határolt kontextusok (bounded contexts).

Ennek eredményeképpen a tartományvezérelt tervezés gyakran társul Plain Old Java Objects és Plain Old CLR Objects (POJO és POCO) objektumokkal. Bár műszakilag a Java és a .NET keretrendszer technikai megvalósítási részletei, ezek a kifejezések azt az egyre inkább terjedő nézetet tükrözik, hogy a tartományi objektumokat pusztán a tartomány üzleti viselkedése, nem pedig egy specifikusabb technológiai keretrendszer alapján kell meghatározni.

Hasonlóképpen, a csupasz objektumok mintája szerint a felhasználói felület egyszerűen egy megfelelő tartománymodell tükörképe lehet. Ha megköveteljük, hogy a felhasználói felület a tartománymodell közvetlen tükörképe legyen, az egy jobb tartománymodell megtervezését eredményezi.[5]

A DDD a szoftverfejlesztés más megközelítéseire is hatással volt. A tartományspecifikus modellezés (domain-specific modeling, DSM) például a doménspecifikus nyelvekkel történő tartományvezérelt tervezés. A DDD nem követeli meg kifejezetten egy doménspecifikus nyelv használatát, bár felhasználható egy ilyen nyelv meghatározásának segítésére és a doménspecifikus multimodellezés támogatására. Másrészt az aspektusorientált programozás megkönnyíti a technikai aggályok (például biztonság, tranzakciókezelés, naplózás) kiszűrését a tartománymodellből, és lehetővé teszi, hogy kizárólag az üzleti logikára összpontosítsanak.

Modellvezérelt tervezés és architektúra[szerkesztés]

Bár a tartományvezérelt tervezés összeegyeztethető a modellvezérelt tervezéssel és a modellvezérelt architektúrával,[6] a két koncepció mögött álló szándék eltérő. A modellvezérelt architektúra inkább a modell kóddá alakításával foglalkozik a különböző technológiai platformok számára, mintsem a megfelelő tartománymodellek meghatározásával.

A modellvezérelt tervezés által biztosított technikák (tartományok modellezése, doménspecifikus nyelvek létrehozása a szakértők és a fejlesztők közötti kommunikáció megkönnyítése érdekében) azonban megkönnyítik a gyakorlatban a tartományvezérelt tervezést, és segítenek a szakembereknek abban, hogy többet hozzanak ki a modelljeikből. A modellvezérelt tervezés modellátalakítási és kódgenerálási technikáinak köszönhetően a tartománymodell felhasználható a tartományt kezelő tényleges szoftverrendszer létrehozására.[7]

Parancs és lekérdezés elválasztása[szerkesztés]

A Command Query Responsibility Segregation (CQRS) egy architekturális minta az adatok olvasásának („lekérdezés”) és az adatok írásának („parancs”) szétválasztására. A parancsok módosítják az állapotot, és megközelítőleg egyenértékűek az gyökér-aggregátumokon vagy -entitásokon történő metódushívással. A lekérdezések olvassák az állapotot, de nem módosítják azt. A CQRS a Bertrand Meyer által megalkotott Command and Query Separation (CQS) elvből származik.

Bár a CQRS nem követeli meg a tartományvezérelt tervezést, a parancsok és a lekérdezések közötti különbséget az aggregátum fogalmával teszi egyértelművé. Az elképzelés lényege, hogy egy adott gyökér-aggregátumnak van egy metódusa, amely megfelel egy parancsnak, és egy parancskezelő hívja meg a metódust. A gyökér felelős a művelet logikájának végrehajtásáért, és vagy egy sor eseményt, vagy egy hibaválaszt ad, vagy csak a saját állapotát módosítja, amely egy adattárolóba írható. A parancskezelő átveszi az állapot mentésével és a szükséges kontextusok (pl. tranzakciók) létrehozásával kapcsolatos infrastrukturális problémákat.

Event sourcing[szerkesztés]

Az event sourcing (kb. események forrásolása) olyan architekturális minta, amelyben az entitások belső állapotukat nem közvetlen szerializálással vagy objektum-reláció leképezéssel követik nyomon, hanem események olvasásával és egy eseménytárolóba való bevitelével.

Amikor az event sourcingot kombinálják a tartományvezérelt tervezéssel és a CQRS-sel, a gyökér-aggregátumok felelősek a parancsok érvényesítéséért és alkalmazásáért (gyakran úgy, hogy a példánymetódusokat egy parancskezelőből hívják meg), majd az események közzétételéért. Ez az alap, amelyre a metódusmeghívások kezelésének logikáját alapozzák. A bemenet tehát egy parancs, a kimenet pedig egy vagy több esemény, amelyeket egy eseménytárolóba mentenek, majd gyakran egy üzenetközvetítőn közzéteszik az érdeklődők számára (például egy alkalmazás nézetében).

Az aggregátumok kimeneti eseményekre történő modellezése még jobban elszigetelheti a belső állapotot, mint az entitásokból származó olvasott adatok kivetítése esetén (mint a szabványos n-szintű adattovábbítási architektúrákban). Ennek egyik jelentős előnye, hogy az axiomatikus tételbizonyítók (pl. Microsoft Contracts és CHESS)[8] könnyebben alkalmazhatók, mivel az gyökér átfogón elrejti belső állapotát. Az események gyakran a gyökér-aggregátum példányának verziója alapján tárolódnak, ami olyan tartománymodellt eredményez, amely optimista konkurrencia révén szinkronizálódik az elosztott rendszerekben.

Fontosabb eszközök[szerkesztés]

Bár a tartományvezérelt tervezés nem függ egyetlen konkrét eszköztől vagy keretrendszertől sem, a figyelemre méltó példák közé tartoznak:

  • Actifsource, egy Eclipse plugin, amely lehetővé teszi a DDD-t modellvezérelt tervezéssel és kódgenerálással kombináló szoftverfejlesztést
  • CubicWeb, egy nyílt forráskódú szemantikus webes keretrendszer, amelyet teljes egészében egy adatmodell vezérel. Magas szintű irányelvek teszik lehetővé az adatmodell iteratív finomítását, kiadásról kiadásra. Az adatmodell meghatározása elegendő egy működő webalkalmazás elkészítéséhez. További munkára van szükség az adatok megjelenítéséhez, ha az alapértelmezett nézetek nem felelnek meg.
  • OpenMDX, egy nyílt forráskódú, Java-alapú, Java SE, Java EE és .NET támogatású MDA-keretrendszer. Az OpenMDX abban különbözik a tipikus MDA keretrendszerektől, hogy „modelleket használ a működési rendszerek futásidejű viselkedésének közvetlen vezérlésére”.
  • Restful Objects, egy szabvány a Restful API leképezésére egy tartományi objektummodellre (ahol a tartományi objektumok entitásokat, nézeti modelleket vagy szolgáltatásokat képviselhetnek). Két nyílt forráskódú keretrendszer (egy Java, egy .NET számára) képes automatikusan, tükrözés segítségével tartománymodellekből Restful Objects API-kat létrehozni.

Hátrányok[szerkesztés]

A tartományvezérelt tervezés kritikái szerint a fejlesztőknek általában nagyfokú elszigetelést és egységbe zárást kell végrehajtaniuk ahhoz, hogy a modell tiszta és hasznos konstrukcióként maradjon fenn. Bár a DDD számos technikai előnnyel szolgál, mint például a karbantarthatóság, a Microsoft csak olyan összetett tartományok esetében ajánlja, ahol a modell és a terminológia egyértelmű előnyökkel jár a tartomány közös értelmezésének megfogalmazásában.[9]

Jegyzetek[szerkesztés]

  1. ↑ DDD-orientált mikroszolgáltatás tervezése, microsoft.com
  2. ↑ Vernon, Vaughn. Implementing Domain-Driven Design. Upper Sadle River, NJ: Addison-Wesley, 3. o. (2013). ISBN 978-0-321-83457-7 
  3. ↑ a b Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley (2004). ISBN 978-032-112521-7 
  4. ↑ Domain driven design.
  5. ↑ Haywood, Dan. Domain-Driven Design using Naked Objects. Pragmatic Programmers (2009) .
  6. ↑ MDE can be regarded as a superset of MDA
  7. ↑ Cabot, Jordi: Comparing Domain-Driven Design with Model-Driven Engineering. Modeling Languages, 2017. szeptember 11.
  8. ↑ CHESS, a MS bug finding tool
  9. ↑ Microsoft Application Architecture Guide, 2nd Edition.

Fordítás[szerkesztés]

Ez a szócikk részben vagy egészben a Domain-driven design című angol Wikipédia-szócikk 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.

További információk[szerkesztés]

A lap eredeti címe: „https://hu.wikipedia.org/w/index.php?title=Tartományvezérelt_tervezés&oldid=26227088”