Domainvezérelt tervezés

A Wikipédiából, a szabad enciklopédiából
Ugrás a navigációhoz Ugrás a kereséshez

A domainvezérelt tervezés (angolul: Domain Driven Design, röviden DDD) egy 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 stb. a terminológiáját és szemléletét (ez maga a 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.

Sajátosságok[szerkesztés]

A DDD egy fejlődő modellhez köti az implementációt.[1]

A DDD a következőket célozza meg:

  • a projekt fő fókuszát az alapdomainre és a domain logikára helyezni
  • az összetett architektúrát a domain modelljére alapozni
  • lehetővé tenni a kreatív együttműködést műszaki és domain szakértők között, hogy folyamatosan finomíthassák a domain problémákhoz igazított modellt

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

Fogalmak[szerkesztés]

A modell legfontosabb alapfogalmai a következők:

Tartalom/Kontextus[szerkesztés]

A környezet, amiben egy szó vagy állítás szerepel. Behatárolja az adott szó vagy állítás jelentését.

Domain[szerkesztés]

A tudás, befolyás, vagy tevékenység szférája/köre (ontológia). A tárgykört, amiben a felhasználó használja a programot, a szoftver domain-jének hívják

Modell[szerkesztés]

Egy absztrakt struktúra, amely leírja a domain valamely aspektusát, és a domainhez kapcsolódó problémák megoldásához használható.

Mindenütt jelenlévő nyelv[szerkesztés]

Egy nyelv, terminológia, amely a domain modell köré van felépítve. Minden szereplő ezt a közös terminológiát használja.

Építőelemek[szerkesztés]

A Domain-Driven Design (DDD) című könyvben számos magasszintű koncepció és gyakorlat található, mint például a mindenütt jelenlévő nyelv, ami azt jelenti, hogy egy modellen belül egy közös nyelvet kell használni.[2] Ezzel írhatók le legtermészetesebben a rendszer követelményei, és az üzleti felhasználók, szponzorok és fejlesztők ugyanúgy eligazodnak benne.

Entitás (Entity)

Önálló identitással rendelkező objektum, referencia (nem az attribútumai határozzák meg).

Példa: a legtöbb légitársaság foglaláskor minden egyes járat minden egyes ülését külön-külön megkülönbözteti. Ebben az értelemben minden ülés egy önálló entitás. Más társaságok viszont nem tesznek különbséget az ülések között, ebben az esetben minden ülés „ugyanolyan” (vagyis értékobjektum).

Értékobjektum (Value Object)

Egy olyan objektum, amely nem rendelkezik identitással, csak az adattartalma, a tulajdonságai lényegesek. Általában megoszthatók és módosíthatatlanok (immutable).

Példa: Amikor az emberek névjegykártyát osztogatnak, általában nem tesznek különbséget közöttük. Kizárólag a kártyán lévő információ a fontos. Ebben az esetben a névjegykártya egy értékobjektum.

Aggregátum (Aggregate)

Objektumok csoportja, melyeket egy entitás fog össze, ez az aggregátor (aggregate root). A külső objektumok hivatkozhatnak az aggregátumra, de az aggregált elemekre közvetlenül nem. Az aggregátor felelős az aggregátum változásainak konzisztenciájáért.

Példa: Amikor egy autót vezetünk, nem kell azzal foglalkozni, hogy mi magunk mozgassuk a kerekeket, indítsjuk be a motort stb. Ezeket mind elvégzik helyettünk az autó belső rendszerei. Ebben az értelemben az autó sok apró objektum aggregatumát tartalmazza, a rendszerek aggregátoraként működik.

Domain esemény (Domain Event)

Egy domain objektum, mely valamilyen időbeli eseményt reprezentál.

Szolgáltatás (Service)

Műveletek, melyek nem illeszthetők szorosan egyik domain objektumhoz sem.

Adattár (Repository)

Az entitások lekérdezésére szolgáló objektum. Az entitások bármilyen külső forrásból származhatnak, például egy adatbázisból.

Gyár (Factory)

Domain objektumok példányosítását végző objektum.

Hátrányok[szerkesztés]

Hogy segítsük fenntartani a modell nyelvének tisztaságát és érthetőségét, a csapatnak általában nagyfokú izolációt és egységbezárást kell alkalmaznia a domain modellen belül. Ebből kifolyólag egy DDD-n alapuló rendszer sokba kerülhet. Míg a DDD számos technikai előnnyel szolgál, mint például a fenntarthatóság/karbantarhatóség, a Microsoft azt javasolja, hogy kizárólag olyan összetett domain-ekre használjuk, ahol a modell és a terminológia egyértelmű előnyöket biztosít a domain egységes értelmezéséhez.[3]

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

Objektumorientált elemzés és tervezés

Habár elméletben a DDD nem korlátozódik kizárólag az objektumorientált megközelítésre, a gyakorlatban a DDD mégis kihasználja azokat az előnyöket, amelyeket a objektumorientált technikák tesznek lehetővé.

Modell irányította fejlesztés és architektúra (Model Driven Engineering/Architecture, MDE/MDA)

Bár a DDD kompatibilis a modellorientált fejlesztéssel és architektúrával, az MDE/MDA koncepciók célja kissé eltérő. Az MDA sokkal inkább a modellnek a különböző technológiai platformok programnyelveire történő lefordítására fókuszál, és semmiképp nem arra, hogy megtalálja a lehető legjobb domain modellt. Az MDE által biztosított technikák (domainek modellezése, DSL-ek kialakítása a domain szakértők és fejlesztők közti jobb kommunikáció kialakítása érdekében) elősegítik a DDD gyakorlati alkalmazását, és segítenek a DDD használóinak, hogy többet kihozzanak a modelljeikből.

POJO-k és POCO-objektumok (Plain Old Java Objects and Plain Old CLR Objects)

A fenti két koncepció a Java és a .NET keretrendszerben népszerű, de a POJO és POCO kifejezések más platforomokon is egyre népszerűbbek. A koncepció lényege, hogy a domain objektumok szerkezetét a domain koncepció kellene hogy meghatározza, nem pedig valamely konkrét technológiai keretrendszer követelményei.

A csupasz objektum minta

A csupasz objektum minta alapfeltevése, hogy ha elég jó a domain modell, akkor a felhasználói felület is közvetlenül ezt a domain modellt tükrözi.[4]

Domain-specifikus modellezés (Domain-specific modeling, DSM)

A DSM a DDD valamilyen (gép által feldolgozható) domain-specifikus nyelven keresztüli alkalmazását jelenti.

Domain-specifikus nyelv (Domain-specific language, DSL)

Habár a DDD nem követeli meg a DSL használatát, hasznos lehet kiválasztani vagy megalkotni egy ilyen nyelvet, esetleg olyan módszereket is támogatva, mint például a domain-specifikus multimodellezés.

Aspektus-orientált programozás (Aspect-oriented programming, AOP)

Az AOP könnyebbé teszi a technikai vonatkozások (például biztonság, tranzakciók kezelése, loggolás) elkülönítését a domain modell implementációjától.

Parancs és lekérdezés felelősségének elkülönítése (Command Query Responsibility Segregation)

A CQRS egy olyan architekturális minta, melyben az adatolvasási (lekérdezés) és -írási (parancs) műveletek elkülönülnek. A parancs változást idéz elő az állapotban, az aggregátumok és entitások metódusainak hívásához hasonlóan. A lekérdezések olvassák, de nem módosítják az állapotot. A CQRS a CQS minta egy változata, melyet Bertrad Meyer dolgozott ki.

Event Sourcing, ES

Az ES egy architekturális minta, melyben az objektumok a saját belső állapotukat nem a teljes tartalmuk mappelésével, hanem események olvasásán/írásán keresztül követik.

  1. Domain driven design.
  2. a b Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley (2004). ISBN 978-032-112521-7 .
  3. Microsoft Application Architecture Guide, 2nd Edition. Retrieved from http://msdn.microsoft.com/en-us/library/ee658117.aspx#DomainModelStyle.
  4. Haywood, Dan. Domain-Driven Design using Naked Objects. Pragmatic Programmers (2009)  Archiválva 2017. szeptember 9-i dátummal a Wayback Machine-ben.

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 jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.