Datové domény

Datový mesh je v zásadě založen na decentralizaci a distribuci odpovědnosti na domény. Pokud skutečně rozumíte části firmy, máte nejlepší pozici ke správě přidružených dat a zajištění jejich přesnosti. Toto je princip vlastnictví dat orientovaných na doménu.

Pokud chcete zvýšit úroveň vlastnictví dat orientovaných na doménu, musíte nejprve rozložit architekturu dat. Zakladatel datové sítě Zhamak Dehghani podporuje přístup Domain-Driven Návrh (DDD) k vývoji softwaru jako užitečnou metodu, která vám pomůže identifikovat datové domény.

Problém s používáním DDD pro správu dat spočívá v tom, že původní případ použití DDD modeloval složité systémy v kontextu vývoje softwaru. Původně se nevytvořil k modelování podnikových dat a pro odborníky na správu dat může být jeho metoda abstraktní a technická. Často chybí chápání konceptu DDD. Odborníci najdou své koncepční pojmy příliš obtížné pochopit nebo se pokusit projektovat příklady ze softwarové architektury nebo objektově orientovaného programování na jejich datové krajině. Tento článek obsahuje praktické pokyny a jasné slovní zásoby, abyste pochopili a používali DDD.

Návrh řízený doménou

Eric Evans, Domain-Driven Design je metoda pro podporu vývoje softwaru, která pomáhá popsat složité systémy pro větší organizace. DDD je populární, protože mnoho z jeho postupů vysoké úrovně má vliv na moderní přístupy k vývoji softwaru a aplikací, jako jsou mikroslužby.

DDD rozlišuje mezi ohraničenými kontexty, doménami a subdoménami. Domény jsou oblasti problémů, které je chcete řešit. Jsou to oblasti, kde se scházejí znalosti, chování, zákony a aktivity. V doménách vidíte sémantické párování, závislosti chování mezi komponentami nebo službami. Dalším aspektem domén je komunikace. Členové týmu musí používat jazyk, který sdílí celý tým, aby mohli všichni efektivně pracovat. Tento sdílený jazyk se nazývá všudypřítomný jazyk nebo jazyk domény.

Domény jsou rozdělené na subdomény, aby se lépe spravovala složitost. Běžným příkladem je rozdělení domény na subdomény, které odpovídají jednomu konkrétnímu obchodnímu problému, jak je znázorněno v zprovoznění datové sítě proAI/ML .

Ne všechny subdomény jsou stejné. Domény můžete například klasifikovat jako základní, obecné nebo podpůrné. Nejdůležitější jsou základní subdomény. Jsou to tajná omáčka, složky, které dělají organizaci jedinečnou. Obecné subdomény jsou neurčité a obvykle se snadno řeší pomocí standardních produktů. Podpora subdomén nenabízí konkurenční výhodu, ale jsou nezbytné k tomu, aby organizace běžela a nebyla složitá.

Ohraničené kontexty jsou logické (kontextové) hranice. Zaměřují se na prostor řešení: návrh systémů a aplikací. Je to oblast, ve které dává smysl soustředění na prostor řešení. V rámci DDD to může zahrnovat kód, návrhy databází atd. Mezi doménami a ohraničenými kontexty může existovat soulad, ale neexistuje žádné pevné pravidlo, které by je vzájemně svázalo. Ohraničené kontexty jsou technické povahy a mohou zahrnovat více domén a subdomén.

Doporučení pro modelování domén

Pokud přijmete datovou síť jako koncept demokratizace dat a implementujete princip vlastnictví dat orientovaných na doménu, aby se zvýšila flexibilita, jak to funguje v praxi? Jak může vypadat přechod z modelování podnikových dat na modelování návrhu řízeného doménou? Jaké lekce můžete vzít z DDD pro správu dat?

Vytvoření funkční obchodní dekompozice vašich problémových prostorů

Než umožníte týmům pracovat se svými daty od začátku do konce, podívejte se na rozsah a porozumějte prostorům problémů, které se snažíte řešit. Než se pustíte do podrobností technické implementace, je důležité nejprve toto cvičení provést. Když nastavíte logické hranice mezi těmito problémovými prostory, odpovědnosti se zpřesní a dají se lépe spravovat.

Podívejte se na obchodní architekturu při seskupování problémových prostorů. V rámci obchodní architektury existují obchodní schopnosti: dovednosti nebo kapacity, které podnik má nebo využívá k dosažení konkrétního účelu nebo výsledku. Tato abstrakce zabalí data, procesy, organizace a technologie do konkrétního kontextu v souladu se strategickými obchodními cíli a cíli vaší organizace. Mapa obchodních schopností ukazuje, které funkční oblasti jsou nezbytné k plnění vašeho poslání a vize.

Dekompozice funkcí fiktivní společnosti Tailwind Traders si můžete prohlédnout v následujícím modelu.

Společnost Tailwind Traders potřebuje zvládnout všechny funkční oblasti uvedené v mapě obchodních schopností, aby byla úspěšná. Společnost Tailwind Traders musí být schopná prodávat lístky jako součást systémů pro správu online nebo offline lístků, například nebo mít piloty k dispozici pro letové letadla jako součást pilotního programu. Společnost může některé aktivity outsourcovat a zároveň zachovat ostatní jako základ své činnosti.

V praxi si všimnete, že většina vašich lidí je uspořádaná podle obchodních možností. Lidé pracující na stejných obchodních funkcích sdílejí stejnou slovní zásobu. Totéž platí pro vaše aplikace a procesy, které jsou obvykle dobře sladěné a úzce propojené na základě soudržnosti činností, které podporují.

Mapování obchodních schopností je skvělým výchozím bodem, ale váš příběh zde nekončí.

Mapování obchodních možností na aplikace a data

Pokud chcete lépe spravovat podnikovou architekturu, zarovnejte své podnikové funkce, omezené kontexty a aplikace. Je důležité dodržovat některá základní pravidla při jejich plnění.

Obchodní funkce musí zůstat na úrovni firmy a zůstat abstraktní. Představují, co vaše organizace dělá a cílí na vaše problémové prostory. Při implementaci obchodních schopností se vytvoří realizace (instance schopností) pro konkrétní kontext. Několik aplikací a komponent spolupracuje v rámci těchto hranic v prostoru řešení za účelem zajištění konkrétní obchodní hodnoty.

Aplikace a komponenty v souladu s konkrétní obchodní schopností zůstávají oddělené od aplikací, které jsou v souladu s dalšími obchodními funkcemi, protože řeší různé obchodní obavy. Ohraničené kontexty se odvozují a výhradně mapují na obchodní funkce. Představují hranici implementace obchodních schopností a chovají se jako doména.

Pokud se změní obchodní možnosti, změní se ohraničené kontexty. Pokud možno očekáváte úplné zarovnání mezi doménami a odpovídajícími ohraničenými kontexty, ale jak se dozvíte v pozdějších částech, realita se někdy liší od ideální.

Pokud namapujeme možnosti projektu na tailwind Traders, můžou ohraničené hranice kontextu a implementace domén vypadat podobně jako v následujícím diagramu.

V tomto diagramu je správa zákazníků založená na odborných znalostech a proto ví nejlépe, jaká data poskytovat jiným doménám. Vnitřní architektura služby Customer Management je oddělená, takže všechny komponenty aplikací v těchto hranicích můžou přímo komunikovat pomocí rozhraní a datových modelů specifických pro aplikace.

datové produkty a jasné standardy interoperability se používají k formalizaci distribuce dat do jiných domén. V tomto přístupu jsou všechny datové produkty také v souladu s doménou a dědí všudypřítomný jazyk, což je vytvořený, formalizovaný jazyk dohodnutý zúčastněnými stranami a návrháři ze stejné domény, aby sloužily potřebám této domény.

Další domény z více možností realizace

Při práci s mapami obchodních možností je důležité potvrdit, že některé obchodní funkce je možné vytvořit vícekrát.

Například firma Tailwind Traders může mít více lokalizovaných realizací (nebo implementací) „zpracování zavazadel a ztracených položek“. Předpokládejme, že jedna část jejich podnikání působí pouze v Asii. V tomto kontextu je "manipulace se zavazadly a ztracené položky" schopností, která je poskytována pro letadla směřující do Asie. Na evropský trh může cílit jiná obchodní činnost a v tomto kontextu se používá další schopnost "manipulace se zavazadly a ztracené položky". Tento scénář více instancí může vést k několika lokalizovaným implementací, které používají různé technologické služby a oddělené týmy pro provoz těchto služeb.

Vztah podnikových schopností a instancí schopností (realizací) je jedna ku mnoha. Z tohoto důvodu skončíte s dalšími (dílčími) doménami.

Vyhledání sdílených možností a sledování sdílených dat

Způsob zpracování sdílených obchodních možností je důležitý. Sdílené funkce obvykle implementujete centrálně jako modely služeb a poskytujete je různým obchodním oblastem. Příkladem tohoto typu funkce může být "Správa zákazníků". V našem příkladu společnosti Tailwind Traders používají asijské i evropské obchodní řady stejnou správu pro své klienty.

Jak ale můžete u sdílené funkce projektovat vlastnictví dat domény? Několik obchodních zástupců pravděpodobně převezme odpovědnost za zákazníky ve stejné sdílené správě.

Existuje doména aplikace a datová doména. Vaše doména a ohraničený kontext nejsou dokonale zarovnané z hlediska datového produktu. Můžete naopak říci, že z hlediska obchodních schopností stále existuje jeden problém s daty.

U sdílených funkcí, jako jsou komplexní balíčky dodavatelů, řešení SaaS a starší systémy, buďte konzistentní ve svém přístupu k vlastnictví dat domény. Vlastnictví dat můžete oddělit prostřednictvím datových produktů, což může vyžadovat vylepšení aplikací. V našem příkladu "Správa zákazníků" společnosti Tailwind Traders můžou různé kanály z domény aplikace generovat více datových produktů: jeden datový produkt pro všechny zákazníky související s Asii a jeden pro všechny zákazníky související s Evropou. V této situaci pochází více datových domén ze stejné domény aplikace.

Můžete také požádat své aplikační domény, aby vytvořily jeden datový produkt, který zapouzdřuje metadata pro rozlišení vlastnictví dat uvnitř sebe. Můžete si například rezervovat název sloupce pro vlastnictví, namapovat každý řádek na jednu konkrétní datovou doménu.

Identifikace monolitů nabízejících více obchodních schopností

Věnujte pozornost také aplikacím, které vyhovují více obchodním možnostem, které se často zobrazují ve velkých a tradičních podnicích. V našem ukázkovém scénáři společnost Tailwind Traders používá komplexní softwarový balíček k usnadnění správy nákladů i prostředků a financování. Tyto sdílené aplikace jsou monolitické, které poskytují co nejvíce funkcí, takže jsou velké a složité. V takové situaci by měla být doména aplikace větší. Totéž platí pro sdílené vlastnictví, ve kterém se v doméně aplikace nachází několik datových domén.

Vzory návrhu pro domény zarovnané podle zdroje, přeposílání a domény sladěné se spotřebiteli

Při mapování domén můžete zvolit vzor založený na vytvoření, spotřebě nebo opětovném nasazení dat. Pro vaši architekturu můžete navrhnout šablony, které podporují vaše domény na základě specifických charakteristik domény.

Systémové domény sladěné se zdrojem

Zdrojové systémové domény jsou v souladu se zdrojovými systémy, kde data pocházejí. Tyto systémy jsou obvykle transakční nebo provozní.

Vaším cílem je zachytávat data přímo z těchto zlatých zdrojových systémů. Datové produkty optimalizované pro čtení z vašich domén poskytujících náročné využití dat Usnadnit tyto domény pomocí standardizovaných služeb pro transformaci a sdílení dat.

Tyto služby, které zahrnují předkonfigurované struktury kontejnerů, umožňují týmům zdrojové domény snadněji publikovat data. Je to cesta nejmenšího odporu s minimálním narušením a náklady.

Domény v souladu se spotřebiteli

Domény v souladu se spotřebitelem jsou opakem zdrojových domén. Odpovídají konkrétním případům použití koncových uživatelů, které vyžadují data z jiných domén. Domény sladěné se zákazníkem využívají a transformují data tak, aby vyhovovala případům použití vaší organizace.

Zvažte možnost nabízet sdílené datové služby pro transformaci a spotřebu dat, aby vyhovovaly těmto požadavkům. Můžete například nabídnout možnosti infrastruktury dat nezávislé na doméně, například pro zpracování datových kanálů, infrastruktury úložiště, streamovacích služeb, analytického zpracování atd.

Domény pro opakované doručení

Opětovná použitelnost dat je jiný a obtížnější scénář. Pokud se například podřízení spotřebitelé zajímají o kombinaci dat z různých domén, můžete vytvořit datové produkty, které agregují data nebo kombinují data vysoké úrovně vyžadovaná mnoha doménami. Díky tomu se můžete vyhnout opakované práci.

Nevytvávejte silné závislosti mezi datovými produkty a případy analytického použití. Snažte se místo toho o flexibilitu a volné párování. Následující model ukazuje, jak dosáhnout flexibility. Doména přebírá vlastnictví datových produktů i případů analytického použití a navrhla samostatné procesy pro vytváření datového produktu a využití dat.

Definování překrývajících se vzorů domény

Modelování domén se často zkomplikuje, když se data nebo obchodní logika sdílejí napříč doménami. Ve velkých organizacích se domény často spoléhají na data z jiných domén. Může být užitečné mít obecné domény, které poskytují logiku integrace způsobem, který ostatním subdoménám umožňuje standardizovat a těžit z ní. Udržujte sdílený model mezi subdoménami malý a vždy v souladu s všudypřítomným jazykem.

Pro překrývající se požadavky na data můžete použít různé vzory od návrhu řízeného doménou. Tady je krátký přehled vzorů, ze které si můžete vybrat:

• Vzor oddělených cest lze použít, pokud dáváte přednost nákladům spojeným s duplikací před opakovanou použitelností. Opětovná použitelnost se obětuje za vyšší flexibilitu a agilitu.
• Vzor zákazník-dodavatel lze použít, pokud je jedna doména silná a ochotná převzít vlastnictví dat a potřeb spotřebitelů dceřiných firem. Nevýhody zahrnují konfliktní obavy a vynucení podřízených týmů k vyjednávání výsledků a plánování priorit.
• Model partnerství se dá použít, když je logika integrace koordinovaná neplánovaným způsobem v nově vytvořené doméně. Všechny týmy spolupracují a respektují potřeby ostatních. Vzhledem k tomu, že nikdo nemůže volně měnit sdílenou logiku, je od všech zúčastněných osob potřeba významný závazek.
• Chcete-li přizpůsobit všechny vaše domény všem požadavkům, můžete použít přizpůsobovací vzor. Tento vzor použijte, když je vaše práce na integraci složitá, žádné jiné strany nemohou mít kontrolu nebo používáte balíčky dodavatelů.

Ve všech případech by vaše domény měly dodržovat vaše standardy interoperability. Doména partnerství, která vytváří nová data pro jiné domény, musí vystavit své datové produkty jako jakoukoli jinou doménu, včetně převzetí vlastnictví.

Odpovědnost za doménu

Datová síť decentralizuje vlastnictví dat tím, že ho distribuuje mezi doménové týmy. U mnoha organizací to znamená posun od centralizovaného modelu kolem zásad správného řízení na federovaný model. Doménové týmy mají přiřazené úkoly, například:

• Převzetí vlastnictví datových kanálů, jako je příjem dat, čištění a transformace dat, aby sloužilo co nejvíce potřebám zákazníků s daty
• Zlepšení kvality dat , včetně dodržování SLA a opatření kvality stanovených uživateli dat
• Zapouzdření metadat nebo použití vyhrazených názvů sloupců pro jemnozrnné filtrování na úrovni řádků a sloupců
• Dodržování standardů správy metadat, mezi které patří:
  • Registrace schématu aplikace a zdrojového systému
  • Metadata pro lepší zjistitelnost
  • Informace o správě verzí
  • Propojení atributů dat a obchodních podmínek
  • Integrita metadat informací umožňujících lepší integraci mezi doménami
• Dodržování standardů interoperability dat, včetně protokolů, formátů dat a datových typů
• Poskytování rodokmenu propojením zdrojových systémů a integračních služeb se skenery nebo ručním poskytováním rodokmenu
• Dodržování úkolů sdílení dat, včetně kontrol přístupu IAM a vytváření kontraktů dat

Úroveň granulárnosti oddělení

Teď, když víte, jak rozpoznávat a usnadnit datové domény, můžete se naučit navrhovat správnou úroveň členitosti domény a pravidel pro oddělení. Při rozkladu architektury se hrají dvě důležité dimenze.

Členitost funkčních domén a nastavení ohraničených kontextů je jedna dimenze. Domény odpovídají konkrétnímu způsobu práce a zajišťují dostupnost dat pro všechny domény používající sdílené služby, převzetí vlastnictví, dodržování standardů metadat atd.

Pokud je to možné, nastavte jemně odstupňované hranice pro distribuci dat. Cílem stát se datově orientovanou organizací je zajistit, aby byla data dostupná pro intenzivní opakované využití. Pokud hranice příliš uvolníte, vynutíte nežádoucí vazby mezi mnoha aplikacemi a ztratíte opětovnou použitelnost dat. Snažte se o oddělení pokaždé, když data překročí hranice obchodních schopností. V rámci domény je povolené těsné párování ve vnitřní architektuře domény. Při překračování hranic obchodních možností ale musí domény zůstat oddělené a distribuovat datové produkty optimalizované pro čtení pro sdílení s jinými doménami.

Členitost technických domén a využití infrastruktury je další důležitá dimenze. Cílové zóny dat umožňují flexibilitu pro obsluhu datových aplikací, které vytvářejí datové produkty. Jak vytvoříte tento druh cílové zóny se sdílenou infrastrukturou a službami pod ní? Funkční domény jsou logicky seskupeny a jsou vhodnými kandidáty pro sdílení infrastruktury platformy. Při vytváření těchto cílových zón je potřeba vzít v úvahu několik faktorů:

• Soudržnost a efektivita při práci s daty a jejich sdílení je silným faktorem sladění funkčních domén s cílovou zónou dat. To souvisí s datovou gravitací, tendencí neustále sdílet velké datové produkty mezi doménami.
• Regionální hranice můžou vést k implementaci dalších cílových zón dat.
• Vlastnictví, zabezpečení nebo právní hranice můžou vynutit oddělení domény. Některá data například nemůžou být viditelná pro žádné jiné domény.
• Flexibilita a tempo změn jsou důležitými faktory. Některé domény můžou mít vysokou rychlost inovací, zatímco jiné domény silně hodnotí stabilitu.
• Funkční hranice můžou týmy oddělit. Příkladem by mohly být hranice orientované na zdroj a spotřebitele. Polovina vašich doménových týmů může považovat určité služby za jiné.
• Pokud chcete potenciálně prodávat nebo oddělit své schopnosti, měli byste se vyhnout úzce integraci se sdílenými službami z jiných domén.
• Velikost týmu, dovednosti a vyspělost můžou být důležité faktory. Vysoce kvalifikované a vyspělé týmy často dávají přednost provozování vlastních služeb a infrastruktury, zatímco méně vyspělé týmy jsou méně pravděpodobné, že budou hodnotit dodatečné náklady na údržbu platformy.

Než zřídíte mnoho cílových zón dat, podívejte se na rozklad vaší domény a určete, jaké funkční domény jsou kandidáty pro sdílení základní infrastruktury.

Shrnutí

Modelování obchodních schopností vám pomůže lépe rozpoznat a uspořádat domény v architektuře datových sítí. Poskytuje ucelený pohled na způsob, jakým data a aplikace doručují hodnotu vaší firmě, a zároveň pomáhá určit prioritu a zaměřit se na strategii dat a obchodní potřeby. Modelování obchodních schopností můžete použít také pro více než jen data. Pokud se například týká škálovatelnosti, můžete pomocí tohoto modelu identifikovat nejdůležitější základní funkce a vyvinout pro ně strategii.

Někteří odborníci vyvolávají obavy, že vytvoření architektury cílového stavu namapováním všeho předem představuje náročné cvičení. Místo toho navrhují, abyste při zavádění do nové datové síťové architektury své domény identifikovali spontánně. Místo definování cílového stavu shora dolů pracujete zdola nahoru, prozkoumáváte, experimentujete a přecházíte ze svého aktuálního stavu k cílovému stavu. I když tento navrhovaný přístup může být rychlejší, přináší značné riziko. Můžete snadno být uprostřed složitého stěhování nebo rekonstrukce, když se věci začnou rozbíjet. Práce z obou směrů, shora dolů a zdola nahoru, a následné setkání uprostřed v průběhu času je sofistikovanější přístup.

Další krok

• Co je datový produkt?