Modelování mikroslužeb pomocí analýzy domény
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ý vytvoří "správný" návrh. Musíte důkladně přemýšlet o své obchodní doméně, požadavcích a cílech. 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, těsné spojení nebo špatně navržená rozhraní. Tento článek popisuje 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í funkce, nikoli na vodorovné 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ě 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á 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řit znalosti domény a abstrahovat je od klientů. Klient by například měl být schopen naplánovat dron, aniž by znal podrobnosti o algoritmu plánování nebo o tom, jak se spravuje flotila 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.
Pomocí výsledků z předchozího kroku identifikujte mikroslužby 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 ale důležité si uvědomit, že DDD je iterativní probíhající proces. Hranice služeb nejsou pevné v kameni. 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. Tento příklad jsme záměrně nechali stručný, 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ž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 pomoct vyhnout se pasti v tom, že váš návrh diktují hranice organizace nebo technologické volby.
Před psaním jakéhokoli kódu potřebujete systém, který vytváříte, z ptačí perspektivy. 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áčrtem, který znázorňuje doménu doručování pomocí dronů.
- Doprava je umístěna uprostřed diagramu, protože je pro firmu zásadní. K povolení této funkce existuje všechno ostatní v diagramu.
- Správa dronů je také základem podnikání. 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ích stran umožní aplikaci naplánovat alternativní způsoby přepravy, pokud balíček nemůže být zcela odeslán dronem.
- Sdílení dronů je možné rozšíření základního podnikání. Společnost může mít v určitých hodinách nadměrnou 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é může společnost později expandovat, je video dohled.
- Uživatelské účty, fakturace a call centrum jsou subdomény, které podporují základní obchodní činnost.
Všimněte si, že v tomto okamžiku procesu jsme nedělali žá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
Pokud je aplikace závislá 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 ohrožení návrhu architektury. To platí zejména pro starší systémy, 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í. Pro tento účel zvažte 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 a prediktivní analýzu dronů, budou muset představovat řadu fyzických vlastností dronů, jako je historie ú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 odesílání 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 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 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í.
Související prostředky
Váš názor
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu: https://aka.ms/ContentUserFeedback.
Odeslat a zobrazit názory pro