A taktikai DDD használata mikroszolgáltatások tervezéséhez
A tartományalapú tervezés (DDD) ellenzi azt az elképzelést, hogy egyetlen egységes modell legyen a teljes rendszer számára. Ehelyett arra ösztönzi a rendszert, hogy határos környezetekre osztja a rendszert, mindegyik saját modellel. A DDD stratégiai fázisában leképezi az üzleti tartományt, és meghatározza a tartománymodellek határolt környezeteit.
Taktikai DDD az, amikor a tartományi modelleket nagyobb pontossággal definiálja. A taktikai mintázatok egyetlen körülhatárolt környezetre vannak alkalmazva. Egy mikroszolgáltatás-architektúrában, ahol minden egyes határolt környezet mikroszolgáltatás-jelölt, az entitás és az összesítő minták figyelemre méltóak. Ezeknek a mintáknak a alkalmazása segít azonosítani az alkalmazásban lévő szolgáltatások természetes határait. További információ: Mikroszolgáltatások határainak azonosítása. Általános alapelv, hogy egy mikroszolgáltatás nem lehet kisebb, mint egy összesítés, és nem lehet nagyobb, mint egy határolt kontextus.
Ez a cikk áttekinti a taktikai mintákat, majd alkalmazza őket a Drone Delivery alkalmazás szállítási keretei között.
A taktikai minták áttekintése
Ez a szakasz röviden összefoglalja a taktikai DDD-mintákat. Ha ismeri a DDD-t, előfordulhat, hogy kihagyja. Ezek a minták részletesebben szerepelnek Eric Evans könyvének 5. és 6. fejezetében, valamint Vaughn Vernon Domain-Driven Design implementálásában .
Entitások. Az entitások időben állandó, egyedi azonossággal bíró objektumok. Egy banki alkalmazásban például az ügyfelek és a számlák is entitások.
Egy entitás egyedi azonosítóval rendelkezik a rendszerben, amely az entitás keresésére vagy lekérésére használható. Ez nem jelenti azt, hogy az azonosító mindig közvetlenül a felhasználók számára lesz közzétéve. Lehet guid vagy elsődleges kulcs egy adatbázisban.
Az identitások több határolt környezetre is kiterjedhetnek, és az alkalmazás élettartamán túl is megmaradhatnak. Például a bankszámlaszámok vagy a kormányzati kiadású azonosítók nincsenek egy adott alkalmazáshoz kötve.
Az entitás attribútumai idővel változhatnak. Előfordulhat például, hogy egy személy neve vagy címe megváltozik, de változatlan marad.
Értékobjektumok. Egy értékobjektumnak nincs identitása. Csak az attribútumai értékei határozzák meg. Az értékobjektumok nem módosíthatók. Egy értékobjektum frissítéséhez létrejön egy új példány a régi helyett. Az értékobjektumok tartalmazhatnak tartománylogikát beágyazó metódusokat, de ezek a metódusok nem okozhatnak mellékhatásokat, és nem módosíthatják az objektum állapotát. Az értékobjektumok gyakori példái közé tartoznak a színek, a dátumok és az időpontok, valamint a pénznemértékek.
Összesítések. Egy összesítés konzisztencia-határt definiál egy vagy több entitás körül. Az összesítésben pontosan egy entitás a gyökér. A keresés a gyökér entitás azonosítójával történik. Az összesítés többi entitása a gyökér gyermekei, és a gyökérmutatók követésével hivatkoznak gombra.
Az összesítés rendeltetése a tranzakciós állandók modellezése. A valós világ objektumait bonyolult kapcsolati háló fűzi össze. Az ügyfelek rendeléseket hoznak létre, a rendelések termékeket tartalmaznak, a termékeknek szállítói vannak és így tovább. Ha az alkalmazás több összefüggő objektumot módosít, hogyan biztosítja a konzisztenciát? Hogyan követhetjük nyomon és juttathatjuk érvényre az állandókat?
A hagyományos alkalmazások gyakran használtak adatbázis-tranzakciókat a konzisztencia kikényszerítésére. Az elosztott alkalmazásokban azonban ez gyakran nem kivitelezhető. Egyetlen üzleti tranzakció több adattárra is kiterjedhet, vagy hosszú ideig futhat, vagy harmadik féltől származó szolgáltatásokat is érinthet. Végső soron az alkalmazáson, nem az adatrétegen múlik, hogy kikényszerítse a tartományhoz szükséges invariánsokat. Az aggregátumok így modellezhetnek.
Feljegyzés
Az összesítések egyetlen entitásból állhatnak, gyermek entitások nélkül. Az aggregátum a tranzakciós határ.
Tartományi és alkalmazásszolgáltatások. A DDD szóhasználatával szolgáltatás az az objektum, amely valamilyen logikát valósít meg anélkül, hogy valamilyen állapota lenne. Az Evans különbséget tesz a tartománylogikát magában foglaló tartományi szolgáltatások és az olyan alkalmazásszolgáltatások között, amelyek technikai funkciókat, például felhasználói hitelesítést vagy SMS-üzenetek küldését biztosítják. A tartományi szolgáltatásokat gyakran használják a több entitást érintő viselkedés modellezésére.
Feljegyzés
A szolgáltatás kifejezés túlterhelt a szoftverfejlesztésben. Az itt használt definíció nem kapcsolódik közvetlenül a mikroszolgáltatásokhoz.
Tartományi események. A tartományi események a rendszer más részeit is értesíthetik, ha valami történik. Ahogy a név is sugallja, a tartományeseményeknek valami értelmeset kell képviselnie a tartományban. Például a "rekord be lett szúrva egy táblába" nem tartományi esemény. A "Kézbesítés törölve lett" domén esemény. A tartományi események különösen fontosak a mikroszolgáltatás-architektúrában. Mivel a mikroszolgáltatások elosztottak, és nem osztanak meg adattárakat, a tartományi események lehetővé teszik a szolgáltatások közötti koordinációt. Az aszinkron üzenetkezeléssel kapcsolatos további információkért lásd: Szolgáltatásközi kommunikáció.
Néhány más DDD-mintát nem fedünk le itt, beleértve a gyárakat, az adattárakat és a modulokat. Ezek a minták hasznosak lehetnek a mikroszolgáltatások implementálásakor, de kevésbé relevánsak a mikroszolgáltatások közötti határok tervezésekor.
Drónos kézbesítés: A minták alkalmazása
Kezdjük azokkal a forgatókönyvekkel, amelyeket a szállítási keret kontextusának kezelnie kell.
- Az ügyfél kérheti a drónt, hogy a drónkézbesítési szolgáltatásban regisztrált vállalkozástól vegye át az árut.
- A feladó létrehoz egy címkét (vonalkódot vagy RFID-t) a csomagra való felállításhoz.
- A drónok felveszik és kézbesítik a csomagot a forráshelyről a célhelyre.
- Amikor egy ügyfél ütemez egy kézbesítést, a rendszer az útvonaladatok, az időjárási körülmények és az előzményadatok alapján biztosít egy ETA-t.
- Amikor a drón repül, a felhasználó nyomon követheti az aktuális helyet és a legújabb ETA-t.
- Amíg egy drón át nem veszi a csomagot, az ügyfél lemondhatja a kézbesítést.
- Az ügyfél értesítést kap a kézbesítés befejezéséről.
- A feladó aláírás vagy ujjnyomat formájában kérheti a kézbesítés megerősítését az ügyféltől.
- A felhasználók megtekinthetik a befejezett kézbesítések előzményeit.
Ezekből a forgatókönyvekből a fejlesztői csapat a következő entitásokat azonosította.
- Kézbesítés
- Csomag
- Drón
- Számla
- Visszaigazolás
- Értesítés
- Címke
Az első négy, a Kézbesítés, a Csomag, a Drón és a Fiók mind olyan összesítések, amelyek a tranzakciós konzisztencia határait jelölik. A Visszaigazolások és az Értesítések Kézbesítések gyermekentitásai, a címkék pedig Csomagok gyermekentitásai.
A tervben szereplő értékobjektumok közé tartozik a Location, az ETA, a PackageWeight és a PackageSize.
Az alábbiakban egy UML-diagramot mutatunk be a kézbesítési összesítésről. Figyelje meg, hogy más aggregátumokra, például a fiókra, a csomagra és a drónra mutató hivatkozásokat tartalmaz.
Két tartományi esemény van:
Amíg egy drón úton van, a Drón entitás a drón helyét és állapotát (repül, leszállt) leíró Drónállapot eseményeket küld.
A Kézbesítés entitás Kézbesítéskövetés eseményeket küld egy kézbesítés állapotának változásakor. A DeliveryTracking események közé tartozik a DeliveryCreated, a DeliveryRescheduled, a DeliveryHeadedToDropoff és a DeliveryCompleted.
Megfigyelheti, hogy ezek az események a tartományi modellben értelmezhető dolgokat írnak le. A tartományról közölnek valamit, és nem kötődnek egy adott programnyelvi szerkezethez.
A fejlesztői csapat felismert még egy funkcióterületet, amely nem illeszkedik az eddig leírt entitások egyikéhez sem. A rendszer valamely részének koordinálnia kell a kézbesítés ütemezésének vagy módosításának összes lépését. Ezért a fejlesztői csapat két tartományi szolgáltatást adott hozzá a tervhez: egy ütemezőt , amely koordinálja a lépéseket, és egy felügyelő , amely figyeli az egyes lépések állapotát, hogy észlelje, hogy a lépések sikertelenek vagy időtúllépések. Ez a megközelítés a Scheduler-ügynök felügyelői mintájának változata.
Következő lépések
A következő lépés az egyes mikroszolgáltatások határainak meghatározása.