Mapper Contexts Supercontexts: Decoupling Domain-specific and Domain-Generic Bounded Contexts

(1. srpna 2019)

Vytváříte nový systém a dva členové vašeho týmu navrhnou alternativní architektury pro zasílání oznámení. Který je správný?

První vývojář navrhuje push model: ohraničené kontexty by měly instruovat kontext oznámení, aby odeslal oznámení. Kontext oznámení (oznámení) by měl jednoduše poslouchat příkazy z jiných kontextů a na pokyn posílat upozornění.

Druhý vývojář nemá rád push model a navrhuje choreografické řešení: když ohraničené kontexty vyvolávají události, oznámení by měla poslouchat a určit, kdy se má odeslat oznámení.

Jak byste navrhli řešení? Ještě důležitější je, jak byste toto rozhodnutí v týmu vyřešili? Jak navrhnete nejúčinnější architekturu, která podporuje krátkodobé cíle a dlouhodobý vývoj?

Mít dovednosti DDD v týmu je hlavní výhodou. Schopnost analyzovat vaši doménu, abyste porozuměli základním, podpůrným a obecným schopnostem, vám umožní provést kompromisy v oblasti zvukového inženýrství.

Pojďme si tento scénář prohlédnout dále s perspektivou DDD.

Analýza schopností

Argumentem pro možnost 1 (tlačené příkazy) je, že obecné (oznámení) by neměly záviset na konkrétním. Pokud je něco obecné v mnoha doménách, logicky je špatné, pokud je to spojeno s něčím v jedné doméně.

Při pohledu za abstraktní uvažování, na co nás tato heuristika varuje? Jaké jsou technické důsledky, kterých si musíme být vědomi?

Existují dva scénáře, kterým se chceme vyhnout:

  1. Vyvarování se úniku logiky specifické pro doménu do obecných kontextů, což má za následek -change
  2. Neschopnost znovu použít nebo nahradit generické kontexty běžným řešením kvůli příliš těsné vazbě na ohraničené kontexty specifické pro doménu

Spojení domény a obecné odpovědnosti

S možností 1 nedochází k žádné společné změně mezi API specifickými pro doménu a generickými pro doménu. Pokud je potřeba nové oznámení, změní se pouze kontexty specifické pro doménu. To však není případ možnosti 2.

U možnosti 2 (choreografické), pokud je zavedena nová událost, která vyžaduje oznámení, bude muset rozhraní API pro konkrétní doménu publikovat novou událost a službu oznámení. se bude muset přihlásit k odběru události a odeslat oznámení. To se necítí dobře – znalost domény se skrývá v obecném kontextu.

Izolace obecných schopností

Pokud je služba oznámení skutečně obecná a znovu použita v mnoha týmech nebo dokonce v organizace, bude muset vědět o stovkách událostí domény. A s tolika týmy v závislosti na kontextu oznámení se jistě stane překážkou, která sníží jeho potenciál pro opětovné použití v celé organizaci.

Další zpětnou vazbou v oblasti designu je, že nemůžeme nahradit obecný kontext za hotové řešení. Pokud je skutečně obecný napříč mnoha doménami, ale nemůžeme jej nahradit běžným řešením, které má více funkcí a jeho provoz je levnější, návrh poskytuje zpětnou vazbu, že něco není v pořádku.

Takže příkazy od konkrétního k obecnému je nejlepší postup?

Všechny důkazy naznačují, že možnost 1 je správná: kontexty specifické pro doménu by měly posílat příkazy do kontextů obecné pro doménu, aby je oddělily od logiky domény. Naše analýza však byla povrchní. Musíme doménu dále analyzovat, abychom získali jistotu, že děláme dobré technické volby.

Hlubší analýza domény

Podíváme-li se blíže na možnost 1 (konkrétní pokyny obecné), každá doména -konkrétní kontext, který je třeba zasílat oznámení, převzal další odpovědnost. Potřebuje vědět, kdy posílat oznámení a jaký typ oznámení posílat.

Je rozumné mít logiku oznámení rozptýlenou ve všech ohraničených kontextech? Spolu se zamotaným kódem by to mohlo znamenat rozsáhlou koordinaci napříč mnoha týmy, pokud se změní přístup oznámení.

Existuje také zvýšené riziko nebo nesrovnalosti a duplikace / plýtvání, pokud každý tým přijme svůj vlastní přístup k oznámení. Sdílené knihovny jsou možné, ale neřeší všechny problémy a přinášejí také kompromisy.

Některé koncepty domén se jasně dělí (červené, šedé, žluté trojúhelníky; modré kruhy), ale některé mají překrývají různé dimenze a lze je kategorizovat několika způsoby (modré trojúhelníky)

Kdykoli je obtížné rozhodnout, zda by odpovědnost měla patřit do toho či onoho kontextu, přiblížit a dále rozložit odpovědnost. Hledejte dílčí odpovědnosti, které lze rozdělit – možná existuje koncept skryté domény.

Když jeden koncept nezapadá čistě do jednoho ohraničeného kontextu, analyzujte jej dále a určete dílčí odpovědnosti. Možná existuje koncept skryté domény, který může přinést model s čistým rozdělením.

Pokud se přiblížíte ke sporné odpovědnosti za odesílání oznámení, mohl by zde být chybějící koncept ? Možná existuje třetí koncept, který propojuje doménu specifickou s doménou obecnou a poskytuje tak elegantnější model.

Kontexty mapovače domény

Jeden vzor, ​​který lze použít k oddělení konkrétních domén a doména obecná je kontext mapovače domény. Když kontext převezme tuto roli, naslouchá konkrétním událostem v doméně a mapuje je na příkazy odeslané do obecného kontextu.

Všimněte si, jak jsou kompromisy tohoto vzoru v porovnání s klady a zápory původních dvou možností. Poskytuje výhody obou – svobodu změnit způsob odesílání oznámení, aniž by došlo ke zmatení každého kontextu specifického pro doménu se složitostí související s oznámeními.

Zvažte scénář: systém interních oznámení má být nahrazen hotové řešení. Mapovač domény by směroval všechny příkazy do nové služby oznámení, aniž by byly ovlivněny jakékoli kontexty specifické pro doménu.

Zvažte jiný scénář: je ​​třeba přidat nové oznámení. V mapovači by byla nakonfigurována registrace: když {událost události} spustí {oznámení}.

Oznámení jsou obecnou funkcí domény – mnoho domén využívá e-mailová a push oznámení
Předvolby oznámení na Twitteru – mapování z události specifické pro doménu na akce generické pro doménu (e-maily)

Proč se nazývají kontexty mapovače?

pojmenování tohoto vzoru je významné. Akce, ke kterým dochází uvnitř jedné domény, jsou mapovány na akce, ke kterým dochází v jiné doméně (obecný kontext je obecný pro mnoho domén, takže je částečně v jiné doméně).

Můžete se podobat s jinými vzory, jako je překladač zpráv , překlad však vyžaduje určitou rovnocennost; přeložená hodnota je jinou reprezentací původní hodnoty. U mapovače tomu tak není.

Mapovač je spíše posluchačem, který sleduje, co se děje v doméně. Rozhoduje o tom, jak reagovat na události v doméně akcí v jiné doméně.

Kontexty mapovače domén brány

Pokud se rozhodnete nahradit své vlastní sestavení obecný kontext s řešením SaaS, váš kontext mapovače domény se stane kontextem mapovače domén brány.

A Brána sedí na okraji systému, který spravuje přítok a odtok informací

Kontext mapovače domény brány plní v podstatě stejnou funkci, nyní však sedí na na okraji vašeho systému a komunikuje přes hranice systému. Je to cesta pro informace proudící dovnitř a ven ze systému.

Implementace může vypadat stejně, ale mít přesnější terminologii je užitečné, protože vám umožní jasněji komunikovat s vaší architekturou.

Doménové kompromisy pro mapování domény

Souvislosti se vzory kontextových mapovačů domény nejsou zanedbatelné. Další vrstva mapování znamená, že jsou nyní zapojeni tři spolupracovníci. Více věcí, které mohou selhat.

Existuje také společná změna. Když se zavedou nové události nebo se změní existující události, bude nutné změnit jak kontext specifické pro danou doménu, který události vlastní, tak kontext mapovače.

K minimalizaci těchto nákladů existuje široce používaná řešení.

Samoobslužné kontexty mapovače domény

Jeden vzor, ​​který se ve volné přírodě často vyskytuje, je samoobslužný ohraničený kontext. Omezený kontext, který hraje tuto roli, umožňuje spotřebitelům využívat možnosti kontextu, aniž by byl blokován týmem, který kontext vlastní.

První variantou je mechanismus kompilace času prostřednictvím řízení zdroje a druhou je runtime mechanismus prostřednictvím Volání API.

Ve scénáři upozornění může samoobslužný kontext poskytnout DSL. Týmy, které vlastní kontexty specifické pro doménu, by vytvořily požadavek na vyžádání obsahující změny v konfiguračním souboru (ještě lepší – kód, který se kompiluje a testuje), který pomocí DSL konfiguruje mapování mezi událostí domény k odběru a upozorněním na budou odeslány.

U dynamické verze by se odpovídající konfigurace provedla prostřednictvím volání API nebo uživatelského rozhraní. Když je možná dynamická konfigurace a na doméně neexistují žádné závislosti na kompilaci, kontext se posune směrem k tomu, aby se stal plně obecným. Toto je běžný evoluční vzor ().

Publikovaný jazyk

Dalším vzorem DDD, který je třeba v tomto typu scénáře zvážit, je publikovaný jazyk. Jakákoli událost, která spustí oznámení, by měla být součástí publikovaného jazyka.

Publikovaným jazykem je smlouva nebo dohoda o formátu zpráv vytvářených ohraničeným kontextem. Zajištění toho, aby události vyžadující oznámení byly součástí publikovaného jazyka, znamená, že je třeba věnovat větší pozornost zpětné kompatibilitě a upozorňovat spotřebitele na budoucí změny.

Mám vždy používat kontexty mapovače domény?

Rozhodně ne. Každý ze vzorů uvedených v příspěvku je platný a úspěšně se používá v různých systémech. Kontexty mapovačů domén jsou dalším vzorem s jasnými kompromisy, které můžete použít k prozkoumání alternativních možností modelování.

Hledání superkontextů

Je snadné modelovat domény na naivní nebo povrchní úrovni . Když uslyšíte slovo jako „oznámení“, je snadné se zamyslet nad soudržným klamem názvu, za předpokladu, že protože slovo zní jako jediný koncept, musí být v našem systému představováno jediným ohraničeným kontextem.

Když použijeme DDD k analýze na hlubší úrovni a podíváme se na oddělené koncepty specifické pro doménu a doménu generické, často zjistíme, že existuje několik způsobů modelování domény, včetně více ohraničených kontextů – vymezení domény specifické od obecné – v rámci jediného superkontextu.

Oddělení konkrétních domén od generických domén není o vytváření krásných abstraktních modelů, které se řídí starými pravidly DDD, jde o oddělení konceptů, které se z různých důvodů mění společně, abychom mohli vytvořit obchod -offs, které umožňují snadnější vývoj systémů.

Pokuste se vyhnout klamu klasifikace jedné domény: za předpokladu, že jedna schopnost na vysoké úrovni, oznámení, musí mít klasifikaci jedné domény (např. obecnou).

V orde Chcete-li získat hlubší informace o doménách, doporučuji vnést do způsobu práce vašeho týmu dovednosti DDD a aktivity DDD. Experimentujte s EventStorming a (The Bounded Context Design Canvas) jako výchozím bodem pro učení, jak modelovat lépe ohraničené kontexty.

Školení a poradenství

Pokud hledáte pomoc s průzkumem vaši doménu, návrh systému nebo školení svých týmů, kontaktujte mě pro další informace. Pracuji se sítí vysoce zkušených odborníků na DDD, kteří se velmi zajímají o navrhování efektivních sociotechnických systémů v souladu s obchodními cíli a doménou.