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

Azure Migrate

Návrh řízený doménou (DDD) se staví proti myšlence, že pro celý systém má jeden jednotný model; místo toho podporuje rozdělení systému na ohraničené kontexty, z nichž každá má svůj vlastní model. Během strategické fáze DDD namapujete 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, kde každý ohraničený kontext je kandidátem mikroslužby, nás zajímá zejména entita a agregační vzory. 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 v aplikaci pro doručování pomocí dronů v kontextu vázaném na expedici.

Přehled taktických vzorů

Tato část obsahuje stručný přehled taktických vzorů DDD, takže pokud už znáte DDD, můžete tuto část pravděpodobně přeskočit. Vzory jsou podrobněji popsány v kapitolách 5 – 6 knihy Erica Evanse a v implementaci návrhu řízeného doménou od 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 identifikátor je vždy přístupný přímo uživatelům. Může se jednat o identifikátor GUID nebo primární klíč v databázi.
  • Identita může zahrnovat více ohraničených kontextů a může trvat déle než životnost aplikace. Například čísla bankovních účtů nebo ID vydaných státní správou nejsou svázaná 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 je stejná osoba.
  • 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 hodnot mohou mít 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řenem. 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žívaly 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 nebo může být dlouhotrvající nebo může zahrnovat služby třetích stran. Nakonec je to až do aplikace, nikoli datové vrstvy, aby vynutila invarianty vyžadované pro doménu. To jsou agregace určené k modelování.

Poznámka:

Agregace se může skládat z jedné entity bez podřízených entit. 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ínová služba je přetížena při vývoji softwaru. Definice zde přímo nesouvisí 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. Článek Komunikace interslužeb podrobněji popisuje asynchronní zasílání zpráv.

Tady není uvedeno několik dalších vzorů DDD, 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žbou jsou méně relevantní.

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

Začneme scénáři, které musí zpracovat kontext ohraničený expedicí.

  • Zákazník může požádat zákazníka o vyzvednutí zboží z firmy zaregistrované ve službě doručování pomocí dronů.
  • Odesílatel vygeneruje značku (čárový kód nebo RFID) pro balení.
  • 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 poskytuje ETA na základě informací o trasách, povětrnostních podmínek a historických dat.
  • Když je dron v letu, může uživatel sledovat aktuální polohu a nejnovější ETA.
  • Dokud dron nenasbídne balíček, zákazník může zrušit doručení.
  • Po dokončení doručení se zákazníkovi zobrazí oznámení.
  • Odesílatel může požádat o potvrzení doručení od zákazníka ve formě podpisu nebo otisku prstu.
  • Uživatelé můžou vyhledat historii dokončeného doručení.

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

  • Doručení
  • Balíček
  • Dron
  • Obchodní vztah
  • Potvrzení
  • Notification
  • Značka

První čtyři agregace, doručování, balení, dronů a účtů představují hranice transakční konzistence. Confirmation a Notification jsou podřízenými entitami entity Delivery a Tag je podřízenou entitou entity Package.

Mezi objekty hodnot v tomto návrhu patří Umístění, ETA, PackageWeight a PackageSize.

Tady je diagram UML agregace Doručení. Všimněte si, že obsahuje odkazy na jiné agregace, včetně účtů, balíčků a dronů.

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ý koordinuje kroky, a správce , který monitoruje stav každého kroku, aby zjistil, jestli některé kroky selhaly nebo vypršel časový limit. Jedná se o variantu vzoru Scheduler Agent Supervisor.

Diagram revidovaného doménového modelu

Další kroky

Dalším krokem je definování hranic pro každou mikroslužbu.