Analýza aplikace a určení hranic rozložení

  • 10 min

Aby mohli ve společnosti Fabrikam převést svoji aplikaci do architektury mikroslužeb, musí vyhodnotit aktuální aplikaci a určit rozsah a hranici jednotlivých mikroslužeb. Pro toto vyhodnocení budou používat architekturu DDD (Domain-Driven Design ). Podívejme se, jak tento přístup použijí pro svoji aplikaci.

Poznámka:

Tento článek nevysvětluje úplnou a komplexní analýzu domény. Příklad jsme záměrně ponechali stručný, abychom mohli názorně ukázat hlavní body. Další informace o DDD najdete v části Další informace v souhrnu na konci tohoto modulu.

Co je návrh řízený doménou?

DDD je přístup k návrhu systému, který původně představil Erik Evans v knize Domain-Driven Design: Řešení složitosti v srdci softwaru. Tento přístup zahrnuje tři klíčové prvky:

  • Zaměření na základní doménu a logiku domény
  • Strukturování návrhu podle modelu domény
  • Řízení iterativní spolupráce mezi technickými týmy a obchodními partnery za účelem neustálého zlepšování systému

DDD poskytuje architekturu, která vám umožní většinu cesty k sadě dobře navržených mikroslužeb. Má dvě odlišné fáze, strategické a taktické. Ve strategické fázi DDD definujete rozsáhlou strukturu systému. Strategická fáze DDD pomáhá zajistit, aby architektura zůstala zaměřená na obchodní možnosti. Taktická fáze DDD poskytuje sadu vzorů návrhu, které lze použít k vytvoření doménového modelu. Mezi tyto vzory patří entity, agregáty a doménové služby. Tyto taktické vzory vám pomůžou navrhovat mikroslužby, které jsou volně propojené i soudržné.

Diagram of the steps for domain-driven design.

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 nás zajímají vzory entit a agregátů. Použití těchto vzorů nám pomůže identifikovat přirozené hranice pro služby v naší aplikaci. 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.

Tento proces lze rozložit na 4 kroky:

  1. Proveďte analýzu obchodní domény, abyste pochopili funkční požadavky aplikace. Výstupem tohoto kroku je neformální popis domény, který se dá vylepšit na formální sadu doménových modelů.
  2. Definujte ohraničené kontexty domény. Každý ohraničený kontext obsahuje doménový model, který představuje konkrétní subdoménu větší aplikace.
  3. V rámci vázaného kontextu použijte taktické vzory DDD k definování entit, agregátů a doménových služeb.
  4. Pomocí výsledků z předchozího kroku identifikujte v aplikaci mikroslužby.

Podívejme se podrobněji na to, co se v každém z těchto kroků stane.

Analýza obchodní domény

DDD začíná modelováním obchodní domény a vytvořením doménového modelu. Doménový model je abstraktní model obchodní domény. Formuluje a organizuje znalosti domény a poskytuje společný jazyk pro vývojáře a odborníky na domény.

Začněte namapováním všech obchodních funkcí a jejich propojení. Tato analýza je spolupráce, která zahrnuje odborníky na domény, softwarové architekty a další zúčastněné strany. Nemusíte používat žádné zvláštní formality. Nakreslete diagram nebo ho nakreslete na tabuli.

Při vyplňování diagramu můžete začít s identifikací samostatných subdomén. Které funkce spolu úzce souvisejí? Které funkce představují základ podnikání a které poskytují doplňkové služby? Jaký je graf závislostí? Během této úvodní fáze se nezabýváte technologiemi ani podrobnostmi implementace. Měli byste však označit místo, kde aplikace potřebuje integraci s externími systémy, jako jsou CRM, zpracování plateb nebo fakturační systémy.

Diagram of the business domain.

Definování ohraničených kontextů

Doménový model zahrnuje znázornění věcí z reálného světa, jako jsou uživatelé, drony a balíčky. To však neznamená, že každá část systému musí používat stejná znázornění pro stejné věci.

Například subsystém zpracovávající opravy dronů a prediktivní analýzu potřebuje řadu fyzických charakteristik dronů. Jedná se například o historii jejich údržby, nalétané kilometry, stáří, číslo modelu a podrobnosti o výkonu. Při plánování doručování ale na těchto věcech nezáleží. Subsystém plánování potřebuje jenom zjistit, jestli je dron k dispozici, a odhadovaný čas příletu (ETA) pro vyzvednutí a doručení.

Pokud se pokusíme vytvořit jeden model pro oba tyto subsystémy, je složitější, než potřebujeme. Vývoj modelu v průběhu času je také obtížnější, protože jakékoli změny musí splňovat požadavky více týmů pracujících na samostatných subsystémech. Často je vhodnější navrhnout samostatné modely, které představují stejnou entitu z reálného světa (v tomto případě dron) ve dvou různých kontextech. Každý model obsahuje jenom funkce a atributy, které jsou relevantní v rámci jeho konkrétního kontextu.

Tento přístup spočívá v tom, že do hry přichází koncept DDD ohraničených kontextů. Ohraničený kontext je prostě hranice v rámci domény, ve které se používá konkrétní doménový model. Při pohledu na předchozí diagram můžeme funkčnost seskupit podle toho, jestli různé funkce sdílejí jeden doménový model.

Diagram of the bounded contexts for the drone application.

Definování entit, agregátů a služeb

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í vzory entit a agregátů. Použití těchto vzorů nám pomůže identifikovat přirozené hranice pro služby v naší aplikaci. 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.

Existuje několik taktických vzorů DDD, které je potřeba vzít v úvahu:

  • Entity: Entita je objekt s jedinečnou identitou, která v průběhu času přetrvává. Například v bankovní aplikaci jsou entitami zákazníci a účty.
  • Objekty hodnot: Objekt hodnoty nemá žádnou identitu. Hodnoty jeho atributů ji definují a jsou neměnné. Mezi typické příklady objektů hodnot patří barvy, data a časy a hodnoty měny.
  • Agregace: Agregace definuje hranici konzistence kolem jedné nebo více entit. Úč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?
  • Doménové a aplikační služby: V terminologii DDD je služba objekt, který implementuje určitou logiku bez uchovávání stavu. 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. Aplikační služby obvykle zahrnují technické funkce, jako je ověřování uživatelů nebo odesílání sms zpráv. Doménové služby se často používají k modelování chování, které zahrnuje více entit.
  • Události domény: Události domény se dají použít k upozornění jiných částí 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. Akce „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.

Diagram of the drone domain model.

Vývojový tým společnosti Fabrikam ve svém systému identifikoval následující entity:

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

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

Mezi objekty hodnot v tomto návrhu patří Location (Poloha), ETA (Odhadovaný čas příletu), PackageWeight (Hmotnost balíčku) a PackageSize (Velikost balíčku).

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 (například letí, přistál).
  • Entita Delivery odesílá události DeliveryTracking vždy, když se fáze doručení změní. Mezi tyto události 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 přidal do návrhu dvě doménové služby. Služba Scheduler koordinuje jednotlivé kroky. Správce monitoruje stav každého kroku, aby zjistil, jestli některé kroky selhaly nebo vypršel časový limit.

Identifikace mikroslužeb

Nyní jsme připraveni k přechodu od doménového modelu k návrhu aplikace. Tady je postup, který můžete použít k odvození mikroslužeb z doménového modelu.

  1. Začněte ohraničeným kontextem. Obecně platí, že funkce v mikroslužbě by neměla zahrnovat více než jeden ohraničený kontext. Podle definice ohraničený kontext označuje hranici konkrétního doménového modelu. Pokud vaše mikroslužba kombinuje různé doménové modely dohromady, je to znaménko, že možná budete muset upřesnit analýzu domény.
  2. Dále se podívejte na agregáty v doménovém modelu. Agregáty jsou často vhodnými kandidáty pro mikroslužby. Dobře navržená agregace ukazuje řadu charakteristik dobře navržené mikroslužby:
    • Agregát se odvozuje z obchodních požadavků, nikoli z technických aspektů, jako je třeba přístup k datům nebo zasílání zpráv.
    • Agregát by měl mít vysokou funkční soudržnost.
    • Agregát je hranicí trvalosti.
    • Agregáty by měly být volně propojené.
  3. Doménové služby jsou také vhodnými kandidáty pro mikroslužby. Doménové služby jsou bezstavové operace napříč více agregáty. Typickým příkladem je pracovní postup, který zahrnuje několik mikroslužeb. Později uvidíme příklad doménové služby v aplikaci pro doručování pomocí dronů.
  4. Nakonec zvažte nefunkční požadavky. Podívejte se na faktory, jako jsou například velikost týmu, datové typy, technologie, požadavky na škálovatelnost, požadavky na dostupnost a požadavky na zabezpečení. Tyto faktory můžou vést k dalšímu rozkladu mikroslužby do dvou (nebo více) menších služeb nebo k tomu, abyste udělali opak a sloučí několik mikroslužeb do jedné.

Důležitá je účelnost. A nezapomínejte na to, že návrh řízený doménou je iterativní proces. V případě pochybností začněte s hruběji rozdělenými mikroslužbami. Mikroslužbu je jednodušší rozdělit do dvou menších služeb než refaktorovat funkce mezi několik stávajících mikroslužeb.

Diagram of the microservices.

Použití návrhu řízeného doménou pro aplikaci dronů

V případě aplikace společnosti Fabrikam se všechny tyto služby nacházejí ve stávající monolitické aplikaci. Po identifikaci, kde může aplikace dekompilovat do mikroslužeb, začnou se službou balíčků.

Služba balíčků má aktuálně zaměřený vývojový tým, vykazuje problémy s výkonem související se škálovatelností a je skvělým kandidátem na zahájení rozkladu aplikace.