Použití analýzy domény k modelování mikroslužeb
Jedním z největších problémů mikroslužeb je definování hranic jednotlivých služeb. Obecně platí, že služba by měla dělat "jednu věc" – ale uvedení tohoto pravidla do praxe vyžaduje pečlivé zvážení. Neexistuje žádný mechanický proces, který by vytvořil "správný" návrh. Musíte se důkladně zamyslet nad svou obchodní doménou, požadavky a cíli. V opačném případě můžete skončit s nahodilým návrhem, který vykazuje některé nežádoucí vlastnosti, jako jsou skryté závislosti mezi službami, úzká vazba nebo špatně navržená rozhraní. Tento článek ukazuje přístup k návrhu mikroslužeb řízený doménou.
V tomto článku se jako příklad používá služba doručování pomocí dronů. Další informace o scénáři a odpovídající referenční implementaci si můžete přečíst tady.
Úvod
Mikroslužby by měly být navržené s ohledem na obchodní možnosti, ne na horizontálních vrstvách, 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ě propojené, pokud můžete změnit jednu službu, aniž byste museli současně aktualizovat další služby. Mikroslužba je soudržná , pokud má jediný, dobře definovaný účel, jako je správa uživatelských účtů nebo sledování historie doručení. Služba by měla zapouzdřovat znalosti domény a abstrahovat je od klientů. Klient by například měl mít možnost naplánovat dron, aniž by znal podrobnosti o algoritmu plánování nebo způsobu správy flotily dronů.
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é fázi DDD se definuje rozsáhlá struktura 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é.
V tomto a dalším článku si projdeme následující kroky a použijeme je pro aplikaci pro doručování pomocí dronů:
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ů.
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.
V rámci vázaného kontextu použijte taktické vzory DDD k definování entit, agregátů a doménových služeb.
Výsledky z předchozího kroku použijte k identifikaci mikroslužeb ve vaší aplikaci.
V tomto článku probereme první tři kroky, které se primárně týkají DDD. V dalším článku identifikujeme mikroslužby. Je však důležité si uvědomit, že DDD je iterativní a probíhající proces. Hranice služeb nejsou pevně dané. Jak se aplikace vyvíjí, můžete se 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. Záměrně jsme příklad ponechali stručný, abychom ilustroval 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žby a uživatelé si mohou 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 problémy obchodního charakteru 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. Fabrikam navíc chce rychle vstoupit na trh a potom rychle iterovat a přidávat nové funkce a možnosti. Aplikace se musí provozovat v cloudovém měřítku, s vysokou cílovou úrovní služeb (SLO). Fabrikam také očekává, různé části systému budou mít velmi odlišné požadavky na úložiště dat a dotazování. Všechny tyto aspekty vedly společnost Fabrikam k tomu, aby pro aplikaci pro doručování pomocí dronů zvolila architekturu mikroslužeb.
Analýza domény
Použití přístupu DDD vám pomůže navrhnout mikroslužby tak, aby každá služba přirozeně odpovídala funkčním obchodním požadavkům. Může vám to pomoct vyhnout se pasti, kdy váš návrh diktují hranice organizace nebo technologické volby.
Před psaním jakéhokoli kódu potřebujete z ptačí perspektivy vidět systém, 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. 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í. Pravděpodobně se bude jednat o společnou práci, která bude zahrnovat 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 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 bude aplikace potřebovat integraci s externími systémy, jako jsou CRM, zpracování plateb nebo fakturační systémy.
Příklad: Aplikace pro doručování pomocí dronů
Po počáteční analýze domény přišel tým společnosti Fabrikam s hrubým náčrtkem, který znázorňuje doménu doručování pomocí dronů.
- Expedice je umístěna uprostřed diagramu, protože je jádrem firmy. K povolení této funkce existuje všechno ostatní v diagramu.
- Správa dronů je také jádrem firmy. Funkce, které úzce souvisejí se správou dronů, zahrnují opravu dronů a použití prediktivní analýzy k předpovídání, kdy drony potřebují údržbu a údržbu.
- Analýza ETA poskytuje odhad času pro vyzvednutí a doručení.
- Přeprava třetí stranou umožní aplikaci naplánovat alternativní způsoby přepravy, pokud balíček nelze odeslat zcela pomocí dronů.
- Sdílení pomocí dronů je možné rozšíření základního podnikání. Společnost může mít během určitých hodin nadbytečnou kapacitu dronů a může si pronajmout drony, které by jinak byly nečinné. Tato funkce nebude v počáteční verzi.
- Další oblastí, do které se společnost může později rozšířit, je videomonitorování.
- 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 procesu jsme nedělali žá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 ale aplikace potřebuje 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, existuje riziko, že datové schéma nebo rozhraní API externího systému pronikne do vaší aplikace, čímž nakonec dojde k narušení návrhu architektury. To platí zejména u starších systémů, které nemusí dodržovat moderní osvědčené postupy a můžou používat spletitá schémata dat nebo zastaralá rozhraní API. V takovém případě je důležité mít dobře definovanou hranici mezi těmito externími systémy a aplikací. Zvažte pro tento účel použití vzoru Strangler Fig nebo vzoru Vrstvy proti poškození .
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í opravy dronů a prediktivní analýzu, budou muset představovat řadu fyzických charakteristik dronů, jako je historie jejich údržby, najeté 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.
Tady přichází do hry koncept ohraničených kontextů DDD. 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 budou sdílet jeden doménový model.
Ohraničené kontexty nejsou od sebe nutně izolované. V tomto diagramu plné čáry, které spojují ohraničené kontexty, představují místa, kde spolu komunikují dva ohraničené kontexty. Například expedice závisí na uživatelských účtech, aby získaly informace o zákaznících, a na správě dronů při plánování dronů z vozového parku.
V knize Návrh řízený doménou popisuje Eric Evans 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, že služby komunikují prostřednictvím dobře definovaných rozhraní API. Tento přístup odpovídá dvěma vzorům, které Evans volá Open Host Service a Publikovaný jazyk. Myšlenka Open Host Service spočívá v tom, že subsystém definuje formální protokol (API) pro ostatní subsystémy, které s ním komunikují. Publikovaný jazyk rozšiřuje tuto myšlenku tím, že publikuje rozhraní API ve formě, kterou můžou k psaní klientů používat jiné týmy. 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 bez jazyka, vyjádřeného ve formátu JSON nebo YAML.
Po zbytek této cesty se zaměříme na kontext expedice.
Další kroky
Po dokončení analýzy domény je dalším krokem použití taktického DDD, které definuje doménové modely s větší přesností.