Szerkesztés

Share via


A taktikai DDD használata mikroszolgáltatások tervezéséhez

Azure Migrate

A tartományalapú tervezés (DDD) stratégiai fázisában leképezi az üzleti tartományt, és meghatározza a tartománymodellek kötött 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. A mikroszolgáltatás-architektúrában különösen érdekelnek az entitások és az összesítési 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 a drónkézbesítési alkalmazásban alkalmazzuk őket a Szállításra korlátozott környezetre.

A taktikai minták áttekintése

Ez a szakasz röviden összefoglalja a taktikai DDD-mintákat, í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 és Vaughn Vernon Implementing Domain-Driven Design című fejezetében ismertetjük.

A taktikai minták diagramja a tartományalapú tervezésben

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, amellyel megkeresheti vagy lekérheti az entitást. 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, korlátozott 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útumainak értékei határozzák meg. Az értékobjektumok szintén nem módosíthatók. É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ányi logiká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ésben szereplő egyéb entitások a gyökér gyermekei, és a gyökérmutatókat követve hivatkoznak rá.

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éhez. 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 múlik, nem az adatrétegen, hogy kikényszerítse a tartományhoz szükséges invariánsokat. Az aggregátumok ennek a modellnek a célja.

Megjegyzés

Az összesítés egyetlen entitásból állhat, gyermek entitások nélkül. Ami összesítetté teszi, az 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 biztosítanak, például felhasználói hitelesítést vagy SMS-üzenetek küldését. A tartományi szolgáltatásokat gyakran használják a több entitást érintő viselkedés modellezésére.

Megjegyzé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 üzenetküldé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ónok kézbesítése: A minták alkalmazása

Kezdjük azokkal a forgatókönyvekkel, amelyeket a szállítási kötött környezetnek 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 csomaghoz.
  • A drón felveszi és kézbesíti a csomagot a forráshelyről a célhelyre.
  • Amikor egy ügyfél ütemez egy kézbesítést, a rendszer egy ETA-t biztosít az útvonaladatok, az időjárási körülmények és az előzményadatok alapján.
  • Amikor a drón repülés közben van, 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
  • Fiók
  • 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 Hely, az ETA, a PackageWeight és a PackageSize.

Ennek szemléltetéséhez íme egy UML-diagram a Kézbesítés ö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.

UML-diagram a kézbesítési összesítésről

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őt , aki figyeli az egyes lépések állapotát, hogy észlelje, hogy valamelyik lépés meghiúsult vagy időtúllépés történt-e. Ez a Scheduler-ügynök felügyeleti mintájának egy változata.

A módosított tartománymodell ábrája

Következő lépések

A következő lépés az egyes mikroszolgáltatások határainak meghatározása.