Identifikace hranic doménového modelu pro každou mikroslužbu

Tip

Tento obsah je výňatek z eBooku, architektury mikroslužeb .NET pro kontejnerizované aplikace .NET, které jsou k dispozici na .NET Docs nebo jako zdarma ke stažení PDF, které lze číst offline.

Stáhnout PDF

Cílem při identifikaci hranic a velikosti modelu pro každou mikroslužbu není dostat se k nejpodrobnějšímu možnému oddělení, i když pokud je to možné, měli byste se přicházet k malým mikroslužbám. Místo toho by vaším cílem mělo být dostat se k nejvýstižnějšímu oddělení, které vás provede znalostmi vaší domény. Důraz není na velikost, ale na obchodní možnosti. Kromě toho, pokud je pro určitou oblast aplikace nutná jasná soudržnost na základě vysokého počtu závislostí, znamená to také potřebu jedné mikroslužby. Soudržnost je způsob, jak identifikovat, jak oddělit nebo seskupit mikroslužby. Nakonec, i když získáte více znalostí o doméně, měli byste přizpůsobit velikost mikroslužby iterativním způsobem. Nalezení správné velikosti není jedním snímkem.

Sam Newman, rozpoznaný propagátor mikroslužeb a autor knihy Vytváření mikroslužeb, zdůrazňuje, že byste měli navrhnout mikroslužby na základě vzoru vázaného kontextu (BC) (součást návrhu řízeného doménou), jak jsme představili dříve. Někdy se bc může skládat z několika fyzických služeb, ale ne naopak.

Doménový model s konkrétními entitami domény se vztahuje v rámci konkrétní bc nebo mikroslužby. Bc odděluje použitelnost doménového modelu a poskytuje členům vývojového týmu jasné a sdílené porozumění tomu, co musí být soudržné a co je možné vyvíjet nezávisle. To jsou stejné cíle pro mikroslužby.

Dalším nástrojem, který informuje vaši volbu návrhu, je Conwayův zákon, který uvádí, že aplikace bude odrážet sociální hranice organizace, která ji vytvořila. Ale někdy je opak pravdivý – organizace společnosti je tvořena softwarem. Možná budete muset obrátit conwayův zákon a vytvořit hranice tak, jak chcete, aby byla společnost uspořádaná, a přiklonit se k poradenství v obchodních procesech.

K identifikaci ohraničených kontextů můžete použít model DDD označovaný jako model mapování kontextu. Pomocí mapování kontextu identifikujete různé kontexty v aplikaci a jejich hranice. Pro každý malý subsystém je běžné mít jiný kontext a hranici, například. Kontextová mapa představuje způsob, jak definovat a explicitně určit hranice mezi doménami. Bc je autonomní a obsahuje podrobnosti o jedné doméně – podrobnosti, jako jsou entity domény– a definuje kontrakty integrace s jinými řadiči domény. Podobá se definici mikroslužby: je autonomní, implementuje určité schopnosti domény a musí poskytovat rozhraní. To je důvod, proč mapování kontextu a vzor ohraničeného kontextu jsou vhodné přístupy k identifikaci hranic doménového modelu mikroslužeb.

Při návrhu velké aplikace uvidíte, jak je možné její doménový model fragmentovat – odborník na doménu z domény katalogu bude pojmenovat entity odlišně v katalogu a v doménách inventáře než odborník na expediční doménu, například. Nebo entita domény uživatele se může lišit v rozsahu a počtu atributů při práci s odborníkem na CRM, který chce ukládat všechny podrobnosti o zákazníkovi, než u odborníka na objednávku domény, který potřebuje jenom částečná data o zákazníkovi. Je velmi těžké zrušit nejednoznačnost všech termínů domény ve všech doménách souvisejících s velkou aplikací. Ale nejdůležitější je, že byste se neměli snažit sjednotit termíny. Místo toho přijměte rozdíly a bohatost poskytovanou každou doménou. Pokud se pokusíte mít jednotnou databázi pro celou aplikaci, pokusy o jednotný slovník budou nepříjemné a nebudou stačit žádnému z několika odborníků na doménu. Proto vám řadiče BCS (implementované jako mikroslužby) pomůžou objasnit, kde můžete použít určité podmínky domény a kde budete muset rozdělit systém a vytvořit další řadiče domény s různými doménami.

Víte, že máte správné hranice a velikosti jednotlivých BC a doménového modelu, pokud máte několik silných vztahů mezi doménovými modely a při provádění typických operací aplikace obvykle nepotřebujete sloučit informace z více doménových modelů.

Možná nejlepší odpověď na otázku, jak velký doménový model pro každou mikroslužbu by měl být následující: měla by mít autonomní BC, co nejizolanější, která vám umožní pracovat, aniž byste museli neustále přepínat do jiných kontextů (modely jiných mikroslužeb). Na obrázku 4–10 vidíte, jak má každá z více mikroslužeb (více řadičů BC) svůj vlastní model a jak se dají definovat jejich entity v závislosti na konkrétních požadavcích pro každou z identifikovaných domén ve vaší aplikaci.

Obrázek 4–10 Identifikace entit a hranic modelu mikroslužeb

Obrázek 4–10 znázorňuje ukázkový scénář související se systémem online správy konferencí. Stejná entita se v závislosti na vázaném kontextu zobrazí jako Uživatelé, Kupující, Payers a Customers. Identifikovali jste několik řadičů domény, které by se daly implementovat jako mikroslužby na základě domén, které vám definovali odborníci na domény. Jak vidíte, existují entity, které se nacházejí pouze v jednom modelu mikroslužby, jako je Platby v mikroslužbě platby. Ty se budou snadno implementovat.

Můžete ale mít také entity, které mají jiný tvar, ale sdílejí stejnou identitu napříč několika doménovými modely z několika mikroslužeb. Například entita User je identifikována v mikroslužbě Správy konferencí. Stejný uživatel se stejnou identitou je ten, který se jmenuje Kupující v mikroslužbě Objednávání, nebo ten s názvem Payer v mikroslužbě Platby, a dokonce i ten, který se jmenuje Zákazník v mikroslužbě Služby zákazníkům. Je to proto, že v závislosti na všudypřítomnosti jazyka , který každý odborník na doménu používá, může mít uživatel jinou perspektivu i s různými atributy. Entita uživatele v modelu mikroslužeb s názvem Conferences Management může mít většinu svých atributů osobních dat. Stejný uživatel ve tvaru Payer v platbě mikroslužby nebo ve tvaru zákazníka v zákaznické službě mikroslužby nemusí potřebovat stejný seznam atributů.

Podobný přístup je znázorněn na obrázku 4–11.

Obrázek 4–11 Rozložení tradičních datových modelů do několika doménových modelů

Při rozkladu tradičního datového modelu mezi ohraničenými kontexty můžete mít různé entity, které sdílejí stejnou identitu (kupující je také uživatel) s různými atributy v každém vázaném kontextu. Uvidíte, jak se uživatel nachází v modelu mikroslužby Conferences Management jako entita Uživatel a je také ve formě entity Kupující v mikroslužbě Cenová mikroslužba s alternativními atributy nebo podrobnostmi o uživateli, když je skutečně kupující. Každá mikroslužba nebo BC nemusí potřebovat všechna data související s entitou uživatele, jen její část v závislosti na problému, který se má vyřešit, nebo kontextu. Například v modelu cenové mikroslužby nepotřebujete adresu ani jméno uživatele, jenom ID (jako identitu) a Stav, které budou mít vliv na slevy při cenách licencí na kupujícího.

Entita Seat má stejný název, ale různé atributy v každém doménovém modelu. Společnost Seat ale sdílí identitu na základě stejného ID, jako se stane u uživatele a kupujícího.

V podstatě existuje sdílený koncept uživatele ve více službách (doménách), které sdílejí identitu daného uživatele. V každém doménovém modelu ale můžou existovat další nebo jiné podrobnosti o entitě uživatele. Proto musí existovat způsob, jak mapovat entitu uživatele z jedné domény (mikroslužby) na jinou.

Existuje několik výhod, které nesdílí stejnou entitu uživatele se stejným počtem atributů napříč doménami. Jednou z výhod je snížení duplicit, aby modely mikroslužeb neměly žádná data, která nepotřebují. Další výhodou je primární mikroslužba, která vlastní určitý typ dat na entitu, aby aktualizace a dotazy na tento typ dat byly řízeny pouze danou mikroslužbou.

PředchozíDalší