Sdílet prostřednictvím

Použití analýzy domény k modelování mikroslužeb

Jednou z největších výzev mikroslužeb je definovat hranice jednotlivých služeb. Obecně platí, že služba by měla dělat jen jednu věc, ale uvedení tohoto pravidla do praxe vyžaduje pečlivé myšlení. Neexistuje žádný mechanický proces, který vytváří správný návrh. Musíte si důkladně představit svoji obchodní doménu, požadavky, charakteristiky architektury (označované také jako nefunkční požadavky) a cíle. V opačném případě můžete skončit s náhodným návrhem, který vykazuje některé nežádoucí vlastnosti, jako jsou skryté závislosti mezi službami, úzkou spojkou nebo špatně navržená rozhraní. Tento článek ukazuje přístup řízený doménou k návrhu mikroslužeb. Vyhodnocení hranic služeb je trvalým úsilím při vývoji úloh. Výsledkem vyhodnocení jsou někdy předdefinované definice stávajících hranic, které vyžadují další vývoj aplikací, aby se změny přizpůsobily.

Tento článek používá službu doručování pomocí dronů jako průběžný příklad. Další informace o scénáři a odpovídající referenční implementaci naleznete v tématu Návrh architektury mikroslužeb.

Úvod

Mikroslužby by měly být navrženy na obchodní funkce, ne na horizontální vrstvy, jako je přístup k datům nebo zasílání zpráv. Kromě toho by měly mít volné spojení a vysokou funkční soudržnost. Mikroslužby jsou volně svázané , pokud můžete změnit jednu službu, aniž byste museli současně aktualizovat jiné služby. Mikroslužba je soudržná , pokud má jeden, dobře definovaný účel, například správu uživatelských účtů nebo sledování historie doručení. Služba by měla integrovat poznatky domény a abstrahovat je od klientů. Klient by měl být například schopný naplánovat dron, aniž by věděl podrobnosti o algoritmu plánování nebo o tom, jak se spravuje flotila dronů. Vlastnosti architektury musí být definovány pro každou mikroslužbu tak, aby odpovídaly obavám v doméně, a ne pro celý systém. Například mikroslužba určená pro zákazníky může potřebovat výkon, dostupnost, odolnost proti chybám, zabezpečení, testovatelnost a flexibilitu. Back-endová mikroslužba může potřebovat pouze odolnost proti chybám a zabezpečení. Pokud mají mikroslužby vzájemně synchronní komunikaci, závislost mezi nimi často vytváří potřebu sdílet stejné charakteristiky architektury.

Návrh řízený doménou (DDD) poskytuje architekturu, která vám významně pomůže na cestě k zajištění sady vhodně navržených mikroslužeb. DDD má dvě různé fáze, strategickou a taktickou. Ve strategickém 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 navrhnout mikroslužby, které jsou volně svázané i soudržné.

Diagram znázorňující proces DDD

V tomto článku a dalším si projdeme následující kroky a použijeme je v aplikaci pro doručování pomocí dronů:

  1. Začněte analýzou 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. Dále 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 mikroslužby ve vaší aplikaci.

V tomto článku se podíváme na první tři kroky, které se primárně týkají DDD. V dalším článku identifikujeme mikroslužby. Je ale důležité si uvědomit, že DDD je iterativní probíhající proces. Hranice služeb nejsou pevně stanovené v kameni. S vývojem aplikace se můžete rozhodnout rozdělit službu na několik menších služeb.

Poznámka:

Tento článek nevysvětluje úplnou a komplexní analýzu domény. V příkladu jsme záměrně zachovali stručný přehled, abychom ilustrovali hlavní body. Další související informace o přístupu DDD najdete v knize Erica Evanse Domain-Driven Design, ve které byl tento přístup představen poprvé. Dobrým referenčním zdrojem je i publikace Implementing Domain-Driven Design od Vaughna Vernona.

Scénář: Doručování pomocí dronů

Fabrikam, Inc. zavádí službu pro doručování pomocí dronů. Společnost spravuje firemní vozový park dronů. Firmy se registrují v této službě a uživatelé si můžou vyžádat, aby dron vyzvedl zboží k doručení. Když si zákazník naplánuje vyzvednutí, back-endový systém přiřadí dron a informuje uživatele o předpokládaném času doručení. V průběhu doručování může zákazník sledovat polohu dronu s průběžně aktualizovaným odhadovaným časem doručení.

Tento scénář zahrnuje poměrně složitou doménu. Mezi klíčové obchodní aspekty patří plánování dronů, sledování balíčků, správa uživatelských účtů a ukládání a analýza historických dat. Cílem společnosti Fabrikam je také rychle se dostat na trh a rychle iterovat a přidávat nové funkce a možnosti. Aplikace musí fungovat v cloudovém měřítku a splňovat vysoký cíl na úrovni služeb. Společnost Fabrikam také očekává, že různé části systému budou mít různé požadavky na ukládání dat a dotazování. Tyto aspekty vedou Fabrikam k přijetí architektury mikroslužeb pro aplikaci pro doručování pomocí dronů.

Analýza domény

Přístup DDD pomáhá navrhovat mikroslužby tak, aby každá služba byla přirozeně vhodná pro funkční obchodní požadavek. Může vám pomoci vyhnout se pasti, že hranice organizace nebo volby technologií budou diktovat váš návrh.

Než začnete psát jakýkoli kód, měli byste mít základní znalosti o systému, který vytváříte. 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. Destiluje a organizuje znalosti domény a poskytuje společný jazyk pro vývojáře a odborníky na doménu.

Začněte mapováním všech obchodních funkcí a jejich připojení. Toto úsilí může být 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. Načrtněte diagram nebo kreslete na tabuli.

Při vyplňování diagramu můžete začít identifikovat diskrétní subdomény. Které funkce spolu úzce souvisejí? Které funkce jsou pro firmu klíčové a které funkce poskytují doplňkové služby? Co je graf závislostí? Během této úvodní fáze se nezabýváte technologiemi ani podrobnostmi implementace. To znamená, že byste měli poznamenat místo, kde se aplikace musí integrovat s externími systémy, jako je správa vztahů se zákazníky, zpracování plateb nebo fakturační systémy.

Příklad: Aplikace pro doručování pomocí dronů

Po nějaké počáteční analýze domény přišel tým Fabrikam s hrubým náčrtem, který znázorňuje doménu dronového doručování.

Diagram znázorňující doménu doručování pomocí dronů

  • Doprava je umístěna uprostřed diagramu, protože je jádrem firmy. Kvůli zajištění této funkčnosti existuje v diagramu vše ostatní.
  • Správa dronů je také jádrem firmy. Funkce, které úzce souvisí se správou dronů, zahrnují opravu dronů a použití prediktivní analýzy k predikci, kdy drony potřebují údržbu a údržbu.
  • Analýza ETA poskytuje časové odhady pro vyzvednutí a doručení.
  • Doprava třetí strany umožní aplikaci naplánovat alternativní způsoby dopravy, pokud balíček nemůže být zcela expedován drony.
  • Sdílení dronů je možné rozšíření základního podnikání. Společnost může mít v určité době nadbytečnou kapacitu dronů a může si pronajmout drony, které by jinak byly nečinné. Tato funkce nebude v počáteční verzi.
  • Dohled nad videem je další oblastí, do které se společnost může později rozšířit.
  • Uživatelské účty, fakturace a Call center jsou subdomény, které podporují základní podnikání.

Všimněte si, že v tomto okamžiku jsme neprovedli žádná rozhodnutí o implementaci nebo technologiích. Některé subsystémy můžou zahrnovat externí softwarové systémy nebo služby třetích stran. I tak musí aplikace s těmito systémy a službami pracovat, takže je důležité je zahrnout do doménového modelu.

Poznámka:

Pokud aplikace závisí na externím systému, hrozí riziko, že do aplikace může dojít k úniku datového schématu nebo rozhraní API externího systému. Tento druh úniku může ohrozit návrh architektury. Zejména u starších systémů, které nedodržují moderní osvědčené postupy, a můžou používat konvolutovaná schémata dat nebo zastaralá rozhraní API. V těchto případech je důležité vytvořit dobře definovanou hranici mezi externím systémem a aplikací. Zvažte použití vzoru Strangler Fig nebo Anti-Corruption Layer pro vynucení této hranice.

Definování ohraničených kontextů

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

Například subsystémy, které zpracovávají opravu dronů a prediktivní analýzu, budou muset reprezentovat mnoho fyzických charakteristik dronů, jako je historie údržby, kilometry, stáří, číslo modelu, charakteristiky výkonu atd. 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 pro vyzvednutí a doručení.

Pokud bychom se pokoušeli pro oba tyto subsystémy vytvořit jediný model, byl by zbytečně složitý. Bylo by také těžší, aby se model v průběhu času vyvíjel, protože jakékoli změny by musely splňovat požadavky více týmů pracujících na samostatných subsystémech. Proto je často 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.

Zde přichází do hry koncept DDD ohraničených kontextů . Ohraničený kontext definuje hranici v rámci domény, kde se vztahuje konkrétní doménový model. Odkazem na předchozí diagram můžete seskupit funkce podle toho, jestli různé funkce sdílejí stejný doménový model.

Diagram znázorňující více ohraničených kontextů

Ohraničené kontexty nejsou nutně izolované od sebe. V tomto diagramu plné čáry spojující ohraničené kontexty představují místa, kde se dva ohraničené kontexty navzájem ovlivňují. Expedice například závisí na uživatelských účtech, aby získala informace o zákaznících, a na správě dronů pro plánování flotily dronů.

V knize Domain Driven Design Eric Evans popisuje několik vzorů pro zachování integrity doménového modelu při interakci s jiným ohraničeným kontextem. Jedním z hlavních principů mikroslužeb je to, že služby komunikují prostřednictvím dobře definovaných rozhraní API. Tento přístup odpovídá dvěma vzorům, které Evans nazývá Open Host Service a Published Language. Myšlenka open hostovací služby spočívá v tom, že subsystém definuje formální protokol (API) pro ostatní subsystémy, které s ní budou komunikovat. Publikovaný jazyk tuto myšlenku rozšiřuje publikováním rozhraní API ve formě, kterou můžou ostatní týmy použít k psaní klientů. V článku Návrh rozhraní API pro mikroslužby probereme použití specifikace OpenAPI (dříve označované jako Swagger) k definování popisů rozhraní REST API, které jsou nezávislé na jazyce, vyjádřené ve formátu JSON nebo YAML.

Na zbytek této cesty se zaměříme na přepravní omezený kontext.

Další kroky

Po dokončení analýzy domény je dalším krokem použití taktického DDD k definování doménových modelů s větší přesností.

Taktické DDD

  • Last updated on