A tartományalapú tervezés (DDD) ellenzi, 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, amelyek mindegyike saját modellel rendelkezik. A DDD stratégiai fázisában az üzlet tartományát méri fel, és meghatározza a tartományi modellek körülhatá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 kötött környezet mikroszolgáltatás-jelölt, különösen érdekel az entitások és az összesítő minták. Ezeknek a mintáknak a alkalmazása segít azonosítani az alkalmazás szolgáltatásainak természetes határait (lásd a sorozat következő cikkét ). Általános alapelv, hogy egy mikroszolgáltatásnak az összesítésnél kisebbnek kell lennie, és nem lehet nagyobb a körülhatárolt környezetnél. Először áttekintjük a taktikai mintákat. Ezután alkalmazzuk őket a Drónkézbesítési alkalmazásban a szállítás által határolt környezetre.
A taktikai minták áttekintése
Ez a szakasz rövid összefoglalást nyújt a taktikai DDD-mintákról, így ha már ismeri a DDD-t, valószínűleg kihagyhatja ezt a szakaszt. A mintákat részletesebben Eric Evans könyvének 5– 6. fejezetében, valamint Vaughn Vernon a tartományalapú tervezés implementálásában ismerteti.
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 eltarthatnak. Például a bankszámlaszámok vagy a kormányzati kiadású azonosítók nincsenek egy adott alkalmazás élettartamához 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 még mindig ugyanaz a személy.
- Az entitások tartalmazhatnak más entitásokra mutató hivatkozásokat.
Értékobjektumok. Egy értékobjektumnak nincs identitása. Csak az attribútumai értékei határozzák meg. Az értékobjektumok szintén nem módosíthatók. Egy értékobjektum frissítéséhez mindig létre kell hoznia egy új példányt a régi helyett. Az értékobjektumok lehetnek olyan metódusok, amelyek beágyazják a tartománylogikát, de ezeknek a metódusoknak nem lehetnek mellékhatásai az objektum állapotára. Tipikus értékobjektumok például a színek, a dátumok és időpontok vagy a pénznemek.
Ö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. A definíció itt nem kapcsolódik közvetlenül a mikroszolgáltatásokhoz.
Tartományi események. A tartományi események használatával a rendszer más részei értesíthetők, ha történik valami. Amint az elnevezése sejteti, egy tartományi eseménynek a tartományon belüli dolgot kell jelentenie. Az, hogy „egy táblába egy rekord lett beszúrva” például nem tartományi esemény. A "Kézbesítés megszakadt" tartományesemény. A tartományi események jelentősége a mikroszolgáltatás-architektúrában a legnagyobb. Mivel az elosztott mikroszolgáltatásoknak nincsenek közös adattáraik, a tartományi események kínálnak módot a mikroszolgáltatások közötti koordinációra. A szolgáltatásközi kommunikáció című cikk részletesebben ismerteti az aszinkron üzenetkezelést.
Néhány más DDD-minta nem szerepel itt, beleértve a gyárakat, az adattárakat és a modulokat. Ezek hasznos minták 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. Ez lehet többek közözz DeliveryCreated (Kézbesítés létrehozva), DeliveryRescheduled (Kézbesítés átütemezve), DeliveryHeadedToDropoff (Kézbesítés folyamatban) vagy DeliveryCompleted (Kézbesítés befejezve).
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ő, aki figyeli az egyes lépések állapotát, hogy megállapítsa, hogy a lépések sikertelenek vagy időtúllépések lettek-e. Ez 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.