Tartományvezérelt tervezés
 |
Ez a szócikk vagy szakasz lektorálásra, tartalmi javításokra szorul. |
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.
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]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,[5] 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.[6]
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.[7]
Jegyzetek
[szerkesztés]- ↑ DDD-orientált mikroszolgáltatás tervezése, microsoft.com
- ↑ Vernon, Vaughn. Implementing Domain-Driven Design. Upper Sadle River, NJ: Addison-Wesley, 3. o. (2013). ISBN 978-0-321-83457-7
- ↑ a b Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley (2004). ISBN 978-032-112521-7
- ↑ Domain driven design.
- ↑ MDE can be regarded as a superset of MDA
- ↑ Cabot, Jordi: Comparing Domain-Driven Design with Model-Driven Engineering. Modeling Languages, 2017. szeptember 11.
- ↑ 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]- Domain Driven Design, Definitions and Pattern Summaries, Eric Evans, 2015
- An Introduction to Domain Driven Design, Methods & tools
- Implementing Aggregate root in C# language