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 "jednu věc", ale uvedení tohoto pravidla do praxe vyžaduje pečlivé myšlení. Neexistuje žádný mechanický proces, který vytvoří "správný" návrh. Musíte se důkladně zamyslet nad vaší obchodní doménou, požadavky, charakteristikami architektury (označované také jako nefunkční požadavky) a cíli. 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á jako spuštěný příklad službu doručování pomocí dronů. Další informace o scénáři a odpovídající referenční implementaci najdete tady.
Ú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 zapouzdřovat znalosti 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é 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 článku a dalším si projdeme následující kroky a použijeme je v 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.
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ě nastavené v kamene. S vývojem aplikace se můžete rozhodnout rozdělit službu do několika 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 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 byla přirozeně vhodná pro funkční obchodní požadavek. Pomůže vám vyhnout se pasti na to, aby hranice organizace nebo volby technologií diktoval váš návrh.
Před napsáním jakéhokoli kódu potřebujete pohled na 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 nějaké počáteční analýze domény přišel tým Fabrikam s hrubým skicam, který znázorňuje doménu doručování pomocí dronů.
- Doprava je umístěna uprostřed diagramu, protože je jádrem firmy. K povolení této funkce existuje vše ostatní v diagramu.
- 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í firmy. 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.
- 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 v tomto okamžiku neprovedli žádná rozhodnutí o implementaci nebo technologiích. Některé subsystémy mohou 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:
Když aplikace závisí na externím systému, hrozí riziko, že schéma dat nebo rozhraní API externího systému do vaší aplikace v konečném důsledku způsobí ohrožení návrhu architektury. To platí zejména u starších systémů, které nemusí dodržovat moderní osvědčené postupy, a mohou používat konvolutovaná 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 použití vzoru Strangler Fig nebo proti poškození vrstvy pro tento účel.
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.
Tady přichází do hry 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 budou sdílet jeden doménový model.
Ohraničené kontexty nejsou nutně izolované od sebe. V tomto diagramu plné čáry spojující ohraničené kontexty představují místa, kde pracují dva ohraničené kontexty. Expedice například závisí na uživatelských účtech, aby získaly informace o zákaznících, a na správě dronů pro plánování dronů z vozového parku.
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 volá 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 kontext vázaný na expedici.
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í.