Mapper Contexts Supercontexts: Tartomány-specifikus és Domain-Generic Bounded Contexts szétválasztása

(2019. augusztus 1.)

Új rendszert épít, és a csapat két tagja alternatív architektúrát javasol az értesítések küldésére. Melyik a helyes?

Az első fejlesztő egy push modellt javasol: a behatárolt összefüggéseknek arra kell utasítaniuk az értesítési környezetet, hogy küldjenek értesítést. Az Értesítések kontextusnak (Értesítések) egyszerűen be kell tartania a többi kontextusból származó parancsokat, és értesítéseket kell küldenie, ha erre utasítást kap.

A második fejlesztő nem kedveli a push modellt, és koreográfiai megoldást javasol: amikor a korlátozott összefüggések eseményeket vetnek fel, az értesítéseknek meg kell hallgatniuk és meg kell határozniuk, hogy mikor küldjenek értesítést.

Hogyan építené fel a megoldást? Ennél is fontosabb, hogyan oldanád meg ezt a döntést a csapatban? Hogyan tervezi meg a leghatékonyabb architektúrát, amely támogatja a rövid távú célokat és a hosszú távú evolúciót?

A DDD képességek megléte a csapatban nagy előny. Ha elemezheti a domainjét az alapvető, támogató és általános képességek megértése érdekében, akkor megalapozott mérnöki kompromisszumokat köthet.

Vizsgáljuk meg tovább ezt a forgatókönyvet DDD perspektívával.

Domain Képességelemzés

Az 1. opció (leküldött parancsok) érve az, hogy az általános (Értesítések) nem függhetnek konkrétaktól. Ha valami általános a sok tartományban, logikailag nem megfelelő, ha valamihez egyetlen tartományban kapcsolódik.

Az elvont érvelésen túl, mi ez a heurisztikus figyelmeztetés? Milyen mérnöki következményekkel kell tisztában lennünk?

Két forgatókönyvet szeretnénk elkerülni:

  1. Kerüljük a tartományspecifikus logika általános kontextusba való kiszivárgását, ami együtt -változtatás
  2. Az általános összefüggések újrafelhasználása vagy a polc nélküli megoldással való helyettesítés képtelensége, mivel túl szorosan kapcsolódnak a tartományspecifikusan korlátozott kontextusokhoz

Tartomány és általános felelősségek összekapcsolása

Az 1. opcióval nincs együttváltás a tartományspecifikus és a tartománygenerikus API-k között. Ha új értesítésre van szükség, csak a tartományspecifikus kontextusok változnak. De ez nem így van a 2. opcióval.

A 2. opcióval (koreográfus), ha új eseményt vezetünk be, amely értesítéseket igényel, akkor egy tartományspecifikus API-nak közzé kell tennie az új eseményt és az értesítési szolgáltatást. fel kell iratkoznia az eseményre, és értesítést kell küldenie. Ez nem tűnik helyesnek – a tartomány ismerete az általános kontextusban rejtőzik.

Általános képességek izolálása

Ha az értesítési szolgáltatás valóban általános, és sok csapatban, vagy akár szervezetnek, több száz domaines eseményről kell tudnia. És ha az értesítési kontextustól függően ennyi csapat működik, ez biztosan szűk keresztmetszet lesz, ami csökkenti az újrafelhasználás lehetőségét egy szervezetben.

A tervezési visszacsatolás egy másik darabja az, hogy nem helyettesíthetjük az általános kontextust egy polc nélküli megoldás. Ha valóban sok területen általános, mégsem tudjuk lecserélni egy olyan polcon elérhető megoldásra, amely nagyobb funkcionalitással és kevesebb futtatással jár, a tervezés visszajelzést ad arról, hogy valami nincs rendben.

Tehát a parancsok a specifikusaktól az általánosig a legjobb gyakorlat?

Az összes bizonyíték azt sugallja, hogy az 1. opció helyes: a tartományspecifikus kontextusoknak parancsokat kell küldeniük tartomány-generikus kontextusoknak, hogy leválasszák őket a tartományi logikáról. Elemzésünk azonban sekély volt. Tovább kell elemeznünk a domaint, hogy bizalmat kapjunk arról, hogy jó mérnöki döntéseket hozunk.

Mélyebb tartományelemzés

Alaposabban megvizsgálva az 1. lehetőséget (specifikus általános utasítások), minden tartomány – az értesítések küldéséhez szükséges sajátos kontextus további felelősséget vállalt. Tudnia kell, hogy mikor küldjön értesítéseket, és milyen típusú értesítéseket küldjön.

Ésszerű-e, ha az értesítések logikája szétszórt az összes behatárolt környezetben? A kusza kód mellett ez sok csapatot érintő nagymértékű koordinációt jelenthet, ha az értesítések megközelítése megváltozik.

Megnövekedett kockázat vagy következetlenségek, valamint a megkettőzés / pazarlás is előfordulhat, ha minden csapat a saját megközelítését alkalmazza az értesítésekre. A megosztott könyvtárak lehetőségek, de nem oldják meg az összes problémát, és kompromisszumokat is hoznak.

Néhány tartománykoncepció egyértelműen particionálódik (piros, szürke, sárga háromszögek; kék körök), de vannak átfedik a különböző dimenziókat, és többféleképpen kategorizálható (kék háromszögek)

Amikor nehézséget okoz annak eldöntése, hogy egy felelősségnek egy vagy másik kontextusba kell-e tartoznia, Nagyítson és bontsa tovább a felelősséget. Keressen olyan részfeladatokat, amelyek szétválaszthatók – lehet, hogy van egy rejtett tartomány-koncepció.

Ha egy fogalom nem illeszkedik tisztán egyetlen korlátozott kontextusba, elemezze tovább az alfeladatok azonosítása érdekében. Talán van egy rejtett tartománykoncepció, amely tisztán particionált modellt eredményezhet.

Az értesítések küldésének vitatott felelősségére való nagyítás, esetleg hiányzik-e koncepció ? Talán van egy harmadik koncepció, amely a tartományspecifikusat a domain-generichoz kapcsolja, hogy elegánsabb modellt nyújtson.

Domain Mapper Contexts

Az egyik minta a domain-specifikus szétválasztására használható a domain-generic pedig a Domain Mapper Context. Amikor egy kontextus felveszi ezt a szerepet, meghatározott tartományi eseményeket hallgat meg, és egy általános kontextusba küldött parancsokra térképezi fel őket.

Figyelje meg, hogy ennek a mintának a kompromisszumai hogyan viszonyulnak az első két lehetőség előnyeihez és hátrányához. Ez biztosítja mindkettő előnyeit – szabadon változtathatja meg az értesítések küldésének módját anélkül, hogy minden tartományspecifikus kontextust elrontana az értesítésekkel kapcsolatos bonyolultsággal.

Vegye figyelembe a forgatókönyvet: a házon belüli értesítési rendszert le kell cserélni polc nélküli megoldás. A tartományleképező az összes parancsot az új értesítési szolgáltatáshoz irányítja, anélkül, hogy bármilyen tartományspecifikus összefüggést érintene.

Vizsgáljon meg egy másik forgatókönyvet: új értesítést kell hozzáadni. A regisztráció a térképkészítőn belül lesz konfigurálva: amikor a {domain esemény} kiváltja az {értesítést}.

Az értesítések domain-generikus képességek – sok domain kihasználja az e-maileket és az értesítéseket
Értesítési beállítások a Twitteren – tartományspecifikus eseményről tartomány-generikus műveletekre (e-mailek) történő leképezés

Miért hívják a Mapper kontextusokat?

A ennek a mintának a megnevezése jelentős. Az egy tartományon belül végrehajtott műveletek egy másik tartományban végrehajtott műveletekhez vannak hozzárendelve (egy általános kontextus sok tartományban általános, így részben egy másik tartományban is van).

Lehet hasonlóság más mintákkal, például a üzenetfordító , azonban a fordítás magában foglal bizonyos egyenértékűséget; a lefordított érték az eredeti érték eltérő ábrázolása. Mapper esetén ez nem így van.

A mapper inkább figyelő, és figyeli, mi történik a tartományon belül. Döntést hoz arról, hogyan reagáljon a tartomány eseményeire egy másik tartomány műveletével.

Gateway Domain Mapper Contexts

Ha úgy dönt, hogy lecseréli az egyedi beépített verziót általános kontextus egy SaaS-megoldással, a Domain Mapper Context átjáró Domain Mapper Context-vé válik.

A Az átjáró egy olyan rendszer szélén ül, amely az információk be- és kiáramlását kezeli

Az átjáró tartományleképező kontextusa lényegében ugyanazt a funkciót látja el, azonban most a a rendszer szélén, és rendszerhatárokon át kommunikál. Ez a rendszerbe be- és kiáramló információk útvonala.

A megvalósítás ugyanúgy nézhet ki, de a pontosabb terminológia megléte hasznos lehet az architektúra tisztább kommunikációjának lehetővé tételében.

Domain Mapper Engineering kompromisszumok

A Domain Mapper Contexts mintákkal társítottak nem jelentéktelenek. A további leképezési réteg azt jelenti, hogy most három együttműködő vesz részt. További dolgok, amelyek kudarcot vallhatnak.

Vannak társváltozások is. Új események bevezetésekor vagy a meglévő események változásakor mind az eseményeket birtokló tartományspecifikus kontextusoknak, mind a leképező kontextusnak meg kell változniuk.

Széles körben használt megoldások vannak a költségek minimalizálására.

Önkiszolgáló tartományleképező kontextusok

A vadonban gyakran előforduló egyik minta az önkiszolgálás által korlátozott kontextus. Az ezt a szerepet játszó korlátozott kontextus lehetővé teszi a fogyasztók számára, hogy kihasználják a kontextus képességeit anélkül, hogy a kontextust birtokló csapat blokkolná őket.

Az első változat egy fordítási időmechanizmus a forrásvezérlésen keresztül, a második pedig futásidejű mechanizmus a API hívások.

Az értesítési forgatókönyvben az önkiszolgáló környezet adhat DSL-t. Azok a csapatok, amelyek tartományspecifikus kontextusokkal rendelkeznek, létrehoznak egy lekérési kérelmet, amely változásokat tartalmaz egy konfigurációs fájlban (még jobb – az összeállító és tesztelt kódban), amely a DSL-t használva konfigurálja a feliratkozásra szánt tartományi esemény és az értesítés közötti leképezést.

A dinamikus verzióval a megfelelő konfigurációt egy API-híváson vagy felhasználói felületen keresztül hajtják végre. Ha lehetséges a dinamikus konfigurálás, és nincsenek fordítási időbeli függőségek a tartománytól, a kontextus elmozdul a teljesen általánosvá válás felé. Ez egy általános evolúciós minta ().

Közzétett nyelv

Egy másik DDD minta, amelyet figyelembe kell venni az ilyen típusú forgatókönyvekben, a közzétett nyelv. Minden olyan eseménynek, amely értesítést vált ki, a közzétett nyelv részét kell képeznie.

A közzétett nyelv szerződés vagy megállapodás a korlátozott kontextus által létrehozott üzenetek formátumáról. Annak biztosítása, hogy az értesítést igénylő események a közzétett nyelv részét képezzék, nagyobb gondot kell fordítani a visszamenőleges kompatibilitás biztosítására és a fogyasztók értesítésére a jövőbeni változásokról.

Mindig használjam a Domain Mapper Contexts-et?

Határozottan nem. A bejegyzésben bemutatott minták mindegyike érvényes és sikeresen alkalmazható különféle rendszerekben. A Domain Mapper Contexts egy másik, egyértelmű kompromisszumokkal rendelkező minta, amelyet alternatív modellezési lehetőségek feltárására használhat.

A szuperkontextusok keresése

Könnyű a domainek naiv vagy felszínes szintű modellezése. . Olyan szó hallatán, mint az „értesítések”, könnyen beleeshet az összetartó névhibába, feltételezve, hogy mivel egy szó egyetlen fogalomnak hangzik, a rendszerünkben egyetlen korlátozott kontextusnak kell képviselnie.

Amikor a DDD-t mélyebb szintű elemzésre használjuk, és a tartományspecifikus és a domain-generikus fogalmak elkülönítésére törekszünk, gyakran azt tapasztaljuk, hogy a domain modellezésére többféle módszer létezik, ideértve több korlátozott összefüggést is – a tartomány specifikus meghatározása az általános – egyetlen szuperkontextusban.

A domain-specifikus és a domain-generic szétválasztása nem arról szól, hogy gyönyörű absztrakt modelleket hozzon létre, amelyek követik az ősi DDD szabályokat, hanem arról, hogy szétválasztjuk azokat a fogalmakat, amelyek különböző okokból változnak együtt, hogy mérnököt tudjunk kialakítani -offok, amelyek lehetővé teszik a rendszerek könnyebb fejlődését.

Próbálja meg elkerülni az egyetlen tartomány besorolását: feltételezzük, hogy egy magas szintű képességnek, az Értesítéseknek, egyetlen tartományi besorolással kell rendelkeznie (pl. általános).

Orde-ban A mélyebb tartományi betekintés érdekében javasoljuk, hogy a DDD készségeket és a DDD tevékenységeket vegye be a csapat munkamódszerébe. Kísérletezzen az EventStorming és a (The Bounded Context Design Canvas) segítségével, mint kiindulópont a jobban behatárolt kontextusok modellezésének megtanulásához.

Képzés és tanácsadás

Ha segítségre van szüksége a domainje, a rendszer megtervezése vagy a csapatok képzése, forduljon hozzám további információkért. Nagy tapasztalattal rendelkező DDD-szakemberek hálózatával dolgozom, akik szenvedélyesen tervezik az üzleti célokhoz és területhez igazodó hatékony szociotechnikai rendszerek kialakítását.