Mit értek a területvezérelt tervezésből
On november 15, 2021 by adminDDD 101
Minél nagyobb a projekt, annál nehezebb a karbantartása. Ezen segíthet, ha az alkalmazást kisebb területekre bontjuk az üzleti szabályaik, az úgynevezett tartományok szerint.
A tartomány alapvetően a tudás egy területe, amely vagy nyilvános, mint például a sakk szabályai, vagy privát, mint például egy nonprofit szervezet üzleti szabályai.
Egy összetett tartomány valószínűleg más tartományok tudását használja. Például egy nonprofit szervezet, amely online sakkot tanít, tud a sakkról, az online platformokon keresztül történő tanításról, és – még akkor is, ha Önt mint hallgatót nem terheli – a pénzügyeiről.
A DDD-ben a tartomány minden egyes részterületét kötött kontextusoknak nevezik, mindegyiknek saját modellje van a világról, amely speciális kódegységekből, úgynevezett építőelemekből épül fel. Itt az entitásokra és az értékobjektumokra fogok koncentrálni, mindkettőre objektumként lehet hivatkozni.
Az entitások olyan objektumok, amelyek a tartományon belül egyedinek hivatottak lenni. Ezt úgy érjük el, hogy egy vagy több tulajdonságot használunk egy adott entitás azonosítására. Például két felhasználónak, akik ugyanazt a nevet használják egy rendszerben, mindig különböző e-mail címei lesznek, mivel az e-mail címek nem ismétlődhetnek – az entitásokat leggyakrabban egy azonosítóval, néha pedig a proprieties kombinációjával különböztetik meg.
Az értékobjektumok ezzel szemben nem rendelkeznek azonosítóval, így csak a tulajdonságaik segítségével lehet megkülönböztetni két példányt. Vegyünk például két gyalogot (a sakkfigurát), ugyanúgy néznek ki, ha ugyanabból a játékkészletből származnak és ugyanolyan színűek, tehát nem számít, ha felcseréljük őket. A DDD-ben az értékobjektumok megváltoztathatatlanok, így könnyebb velük érvelni.
Adatintegritás
Egy lehatárolt kontextus nem tárja fel minden objektumát, hogy garantálja az adatintegritását. Ehelyett néhány aggregátumgyökeret egyfajta nyilvános interfészként tár fel saját magához.
Az aggregátum nem más, mint egy más objektumokból álló entitás. Pontosabban, egy aggregátum olyan kapcsolódó objektumok csoportja, amelyeket az adatok megváltoztatásakor egységként kezelünk.
A gyakorlatban az aggregátumok a fa néven ismert adatszerkezet alakját veszik fel. És ezért minden aggregátumnak van egy gyökere.
Az aggregátum egyetlen olyan tagja, amelyre más objektumok hivatkozhatnak, a gyökere, és ezért ezt tesszük ki. Ezt azért csináljuk így, mert így megakadályozzuk, hogy más objektumok olyan módon piszkálhassák az adatokat, amit az aggregátum nem tud ellenőrizni.
Fontos tisztázni, hogy egy lehatárolt kontextus sok aggregátumot használhat még akkor is, ha azok gyökere nem exponálódik közvetlenül a külvilág felé.
A több lehatárolt kontextus kezelése
De a dolgok ennél bonyolultabbak is lehetnek, igaz? Minden egyes körülhatárolt kontextus ugyanannak az objektumnak egy kissé eltérő modelljét kapja, különböző tulajdonságokkal és viselkedéssel. Így egy felhasználónak egy játék-kontextusban lehet olyan tulajdonsága a pontszámának kezelésére, ami egy pénzügyi kontextusban irreleváns, tehát nem létezik.
És ez még nem minden. Az is lehetséges, hogy egy tartományi fogalom, amelyet egy korlátozott kontextusban entitásként reprezentálnak, egy másikban objektum-értékként reprezentálódik, vagy éppen teljesen elmarad.
Míg például a tanítási kontextus megköveteli, hogy a tanárokat entitásokként reprezentáljuk, hogy az azonosítójuk alapján hozzárendelhetők legyenek a diákokhoz, addig a pénzügyi kontextus inkább az alkalmazott entitás pozíció tulajdonságának értékeként szeretné látni a “tanár”-t.
A DDD további építőkövei közé tartoznak a szolgáltatások, a tárolók, a gyárak és az események. Megpróbálom röviden leírni őket.
A szolgáltatások egy tartomány olyan képességei, amelyek természetesen nem illeszkednek sem az entitásokhoz, sem az objektum-értékekhez. Vigyázzunk, hogy ezek tartományi szolgáltatások, nem pedig alkalmazás- vagy infrastruktúra-szolgáltatások.
A tárolók hidak a tárolóegységekhez – hello CRUD!.
A gyárak módszerek a tartományi objektumok létrehozására, hogy azok soha ne legyenek érvénytelen értékek. Ez a rész indított el a termékvezérelt tesztekről való gondolkodásra.
Az események olyan objektumok, amelyek a tartományban történt valamit reprezentálnak – a szakértői törődnek velük. Nagyszerű lehetőségek egy eseményvezérelt alkalmazás létrehozására .
Noha nem emlékszem, hogy Evans ezt kijelentette volna, a kötött kontextusok jó lehetőséget nyújtanak arra, hogy a kódot mikroszolgáltatásokra osszuk fel, ahol minden egyes szolgáltatás egy saját kontextus. Az első lépés lehet egy “virtuális” felbontás, ahol minden egyes kontextus egy másik modulba kerül ugyanabban az alkalmazásban, majd ha azt észleled, hogy valóban elszigeteltek, áthelyezheted őket más-más modulba.
A nyelv, ami mindet uralja
Az egyik első dolog, amit az emberek megtanulnak a DDD tanulmányozásakor, hogy a rendszerüket egy mindenütt használt nyelvvel kell leírni. Vagyis a kódot ugyanazokkal az igékkel (a módszerek vagy szolgáltatások esetében) és főnevekkel (az objektumok esetében) kell írnunk, amelyeket a domain-szakértők használnak, amikor hozzánk beszélnek.
Az ilyen kódírásnak megvan az az előnye, hogy lezárja a kommunikációs szakadékot a fejlesztők és a szakértők között, amikor beszélgetnek, de ez a valós élet túlzott leegyszerűsítése, ezért én személy szerint iránymutatásként használom, de nem végleges megoldásként.
Azért tartogattam a végére, mert számomra a DDD-ről a legfontosabb dolgok általában nem olvashatók, mivel a könyv “komplex” részében vannak.
Még nemrég tudtam meg, hogy maga a szerző mondta, hogy az a sorrend, ahogyan a könyvben bemutatja a dolgokat, nem optimális, és amit itt leírtam, az közelebb áll ahhoz, ami ideális lett volna 😍. Egy podcastban hallottam erre utalva
Vélemény, hozzászólás?