Návrh mikroslužeb pomocí taktického DDD

Azure Migrate

Během strategické fáze návrhu řízeného doménou (DDD) mapujete obchodní doménu a definujete ohraničené kontexty pro vaše doménové modely. V taktické fázi DDD se doménové modely definují s větší přesností. Taktické vzory se používají v rámci jednoho ohraničeného kontextu. V architektuře mikroslužeb nás zajímají zejména vzory entit a agregace. Použití těchto vzorů nám pomůže identifikovat přirozené hranice služeb v naší aplikaci (viz další článek v této sérii). Obecně platí, že mikroslužba by neměla být menší než agregát a neměla by být větší než ohraničený kontext. Nejprve si projdeme taktické vzory. Pak je použijeme na kontext Shipping ohraničený v aplikaci Pro doručování pomocí dronů.

Přehled taktických vzorů

Tato část obsahuje stručný přehled taktických vzorů DDD, takže pokud už jste obeznámeni s DDD, můžete tuto část pravděpodobně přeskočit. Vzory jsou podrobněji popsány v kapitolách 5 až 6 knihy Erica Evanse a v implementaci Domain-Driven návrhu Vaughna Vernona.

Diagram taktických vzorů v návrhu řízeném doménou

Entity. Entita je objekt s jedinečnou identitou, která je v průběhu času trvalá. Například v bankovní aplikaci budou entitami zákazníci a účty.

  • Entita má v systému jedinečný identifikátor, který lze použít k vyhledání nebo načtení entity. To neznamená, že je identifikátor vždy vystavený přímo uživatelům. Může to být identifikátor GUID nebo primární klíč v databázi.
  • Identita může zahrnovat více ohraničených kontextů a může přetrvávat i po dobu životnosti aplikace. Například čísla bankovních účtů nebo id vystavená státní správou nejsou svázána s životností konkrétní aplikace.
  • Atributy entity se můžou v průběhu času měnit. Může se například změnit jméno nebo adresa osoby, ale stále se jedná o stejnou osobu.
  • Entita může obsahovat odkazy na jiné entity.

Objekty hodnot. Objekt hodnoty nemá žádnou identitu. Definuje se pouze hodnotami jeho atributů. Objekty hodnot jsou také neměnné. Chcete-li aktualizovat objekt hodnoty, vždy vytvoříte novou instanci, která nahradí starou instanci. Objekty value mohou obsahovat metody, které zapouzdřují logiku domény, ale tyto metody by neměly mít žádné vedlejší účinky na stav objektu. Mezi typické příklady objektů hodnot patří barvy, data a časy a hodnoty měny.

Agregace. Agregát definuje hranici konzistence okolo jedné nebo více entit. Právě jedna entita v agregaci je kořen. Vyhledávání se provádí pomocí identifikátoru kořenové entity. Všechny ostatní entity v agregaci jsou podřízené kořenovému adresáři a odkazují se na tyto ukazatele z kořenového adresáře.

Účelem agregátu je modelování transakčních invariantů. Věci v reálném světě mají komplexní sítě vztahů. Zákazníci vytvářejí objednávky, objednávky obsahují produkty, produkty mají dodavatele atd. Pokud aplikace změní několik souvisejících objektů, jak zaručuje konzistenci? Jak sledujeme invarianty a jak je vynucujeme?

Tradiční aplikace často používají databázové transakce k vynucení konzistence. V distribuované aplikaci to ale často není možné. Jedna obchodní transakce může zahrnovat více úložišť dat, může být dlouhotrvající nebo může zahrnovat služby třetích stran. V konečném důsledku je na aplikaci, nikoli na datové vrstvě, aby vynutila invarianty vyžadované pro doménu. To je to, co mají agregace modelovat.

Poznámka

Agregace se může skládat z jedné entity bez podřízených entit. To, co z něj dělá agregaci, je transakční hranice.

Doménové a aplikační služby. Služba je v terminologii DDD objekt, který implementuje určitou logiku, aniž by uchovával nějaký stav. Evans rozlišuje mezi doménovými službami, které zapouzdřují logiku domény, a aplikačními službami, které poskytují technické funkce, jako je ověřování uživatelů nebo odesílání zpráv SMS. Doménové služby se často používají k modelování chování, které zahrnuje více entit.

Poznámka

Termín service je přetížen při vývoji softwaru. Definice zde nesouvisí přímo s mikroslužbami.

Události domény. Události domény lze používat k oznamování jiným částem systému, když se něco stane. Jak naznačuje už název, události domény by měly být akce, které mají význam v rámci domény. Například akce „záznam byl vložen do tabulky“ není událostí domény. "Doručení bylo zrušeno" je událost domény. Události domény jsou relevantní zejména v architektuře mikroslužeb. Mikroslužby jsou distribuované a nesdílejí úložiště dat, a proto události domény poskytují způsob, jak mikroslužby vzájemně koordinovat. V článku Komunikace mezi službami se podrobněji věnuje asynchronnímu zasílání zpráv.

Existuje několik dalších vzorů DDD, které tu nejsou uvedené, včetně továren, úložišť a modulů. Tyto vzory můžou být užitečné při implementaci mikroslužby, ale při návrhu hranic mezi mikroslužbami jsou méně relevantní.

Doručování pomocí dronů: Použití vzorů

Začneme scénáři, které musí zpracovat kontext Expedice.

  • Zákazník může požádat dron o vyzvednutí zboží z firmy, která je zaregistrovaná u služby doručování dronů.
  • Odesílatel vygeneruje značku (čárový kód nebo RFID), která se vloží na balíček.
  • Dron vyzvedne a doručí balíček ze zdrojového umístění do cílového umístění.
  • Když zákazník naplánuje dodávku, systém poskytne ETA na základě informací o trasách, povětrnostních podmínkách a historických datech.
  • Když je dron v letu, může uživatel sledovat aktuální polohu a nejnovější ETA.
  • Dokud balíček nevyzvednou drony, může zákazník dodávku zrušit.
  • Zákazník bude upozorněn na dokončení doručení.
  • Odesílatel může od zákazníka požádat o potvrzení doručení ve formě podpisu nebo otisku prstu.
  • Uživatelé můžou vyhledat historii dokončeného doručení.

Z těchto scénářů vývojový tým identifikoval následující entity.

  • Delivery (Doručení)
  • Package (Balíček)
  • Drone (Dron)
  • Account (Účet)
  • Confirmation (Potvrzení)
  • Notification (Oznámení)
  • Tag (Značka)

První čtyři, Delivery, Package, Drone a Account, jsou agregace , které představují hranice konzistence transakcí. Confirmation a Notification jsou podřízenými entitami entity Delivery a Tag je podřízenou entitou entity Package.

Objekty hodnot v tomto návrhu zahrnují Location, ETA, PackageWeight a PackageSize.

Pro ilustraci je tady diagram UML s agregací doručení. Všimněte si, že obsahuje odkazy na jiné agregace, včetně účtu, balíčku a dronu.

Diagram UML agregace doručení

K dispozici jsou dvě události domény:

  • Během letu dronu entita Drone odesílá události DroneStatus, které popisují polohu a stav dronu (letí, přistál).

  • Entita Delivery odesílá události DeliveryTracking vždy, když se fáze doručení změní. Mezi fáze doručení patří DeliveryCreated, DeliveryRescheduled, DeliveryHeadedToDropoff a DeliveryCompleted.

Všimněte si, že tyto události popisují věci, které mají význam v rámci doménového modelu. Popisují něco, co se týká domény, a nejsou vázány na konkrétní konstruktor programovacího jazyka.

Vývojový tým identifikoval další oblast funkčnosti, která se nehodí do žádné z dosud popsaných entit. Nějaká část systému musí koordinovat všechny kroky, které jsou nutné k naplánování nebo aktualizaci doručení. Vývojový tým proto do návrhu přidal dvě doménové služby : plánovač , který jednotlivé kroky koordinuje, a správce , který monitoruje stav jednotlivých kroků, aby zjistil, jestli některé kroky selhaly nebo vypršel jejich časový limit. Toto je varianta modelu Scheduler Agent Supervisor.

Diagram revidovaného doménového modelu

Další kroky

Dalším krokem je definování hranic jednotlivých mikroslužeb.