Datové domény

Datová síť, v jádru, je založena v decentralizované a distribuci odpovědnosti do domén. Pokud skutečně rozumíte této čá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 upřednostnit vlastnictví dat orientovaných na doménu, musíte nejprve vytvořit rozklad architektury dat. Zakladatel datové sítě Zhamak Dehghani podporuje přístup DDD (Domain-Driven Design) k vývoji softwaru jako užitečnou metodu, která vám pomůže identifikovat vaše 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á. Existuje také často nedostatek porozumění DDD. Odborníci najdou své koncepční pojmy, které je příliš obtížné pochopit, nebo se snaží 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ě ovlivňuje moderní přístupy k vývoji softwaru a aplikací pro věci, jako jsou mikroslužby.

DDD rozlišuje mezi ohraničenými kontexty, doménami a subdoménami. Domény jsou problémové mezery, které 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ě pro AI/ML.

Ne všechny subdomény jsou stejné. Můžete například klasifikovat domény tak, aby byly 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 nespecifické a obvykle snadno řešit s produkty mimo police. Podpora subdomén nenabízí konkurenční výhodu, ale jsou nezbytné k tomu, aby organizace fungovala, a obvykle nejsou 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 zarovnání zaměření 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 zarovnání, neexistuje žádná pevná vazba pravidla, která by obě obě vzájemně svázaly. 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ž týmům povolíte, aby fungovaly na konci jejich dat, podívejte se na rozsah a porozumíte problémům, které se pokoušíte vyř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í možnosti: schopnosti nebo kapacity, které má firma nebo výměny 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é práce na stejné obchodní schopnosti sdílí 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

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, jak to uděláte.

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. V rámci těchto hranic v prostoru řešení spolupracuje více aplikací a komponent, aby bylo doručovat konkrétní obchodní hodnotu.

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ího kontextu.

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 odborných znalostí a proto ví, jaká data mají sloužit jiným doménám. Vnitřní architektura správy zákazníků je oddělená, takže všechny komponenty aplikací v těchto hranicích můžou přímo komunikovat pomocí rozhraní specifických pro aplikace a datových modelů.

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 společnost Tailwind Traders může mít více lokalizovaných realizace (nebo implementace) "zpracování zavazadel a ztracených položek". Předpokládejme, že jeden řádek podnikání působí pouze v Asii. V tomto kontextu je "manipulace se zavazadly a ztracené položky" schopností, která je splněna pro letadla související s Asii. Na evropský trh může cílit jiná obchodní činnost a v této souvislosti se používá další možnost "manipulace se zavazadly a ztracené položky". Tento scénář více instancí může vést k několika lokalizovaným implementací, které využívají různé technologické služby a oddělené týmy k provozování těchto služeb.

Vztah obchodních schopností a instancí schopností (realizace) je 1:N. 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, kteří jsou 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.

Pro sdílené funkce, jako jsou komplexní balíčky dodavatelů, řešení SaaS a starší systémy, musí být konzistentní v přístupu k vlastnictví dat vaší 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ávy 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 monolitických funkcí nabízejících více obchodních možností

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, který usnadňuje správu nákladů i prostředky 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, opětovného nasazení a domény v souladu 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.

Zdrojové systémové domény

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ředem nakonfigurované struktury kontejnerů, umožňují vašim zdrojovým doménovým týmům snadněji publikovat data. Je to cesta nejnižší odolnosti s minimálním přeruš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.

Znovunabíděné domény

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í pro datové produkty i případy 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:

• Pokud dáváte přednost souvisejícím nákladům na duplikaci před opětovným používáním, můžete použít samostatný způsob použití vzoru. Opětovná použitelnost se obětuje za vyšší flexibilitu a flexibilitu.
• Model dodavatele zákazníka lze použít, pokud je jedna doména silná a ochotná převzít vlastnictví dat a potřeb podřízených spotřebitelů. 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í s potřebami 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.
• Konformní vzor lze použít ke splnění všech vašich domén všem požadavkům. 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šechpřípadechch 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íť decentralizované vlastnictví dat tím, že je 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 zákazníků
• Zlepšení kvality dat, včetně dodržování smluv SLA a opatření kvality stanovených spotřebiteli dat
• Zapouzdření metadat nebo použití vyhrazených názvů sloupců pro 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 informací o metadatech umožňující 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ň členitosti oddělení

Teď víte, jak rozpoznávat a usnadnit datové domény, můžete se naučit navrhnout 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. Tím, že se data stávají řízená daty, je o tom, aby byla data dostupná pro intenzivní opakované použití. Pokud hranice příliš uvolníte, vynutíte nežádoucí párování mezi mnoha aplikacemi a ztratíte opětovnou použitelnost dat. Snažte se oddělit pokaždé, když data překročí hranice obchodních možností. 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 aplikace údržby dat, 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 závažností dat, což je tendenci neustále sdílet velké datové produkty mezi doménami.
• Regionální hranice můžou způsobit implementaci dalších cílových zón dat.
• Oddělení domén může vynutit vlastnictví, zabezpečení nebo právní hranice. 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 je náročné cvičení. Místo toho vám při onboardingu do nové architektury datových sítí navrhují, abyste své domény identifikovali ekologicky. Místo definování cílového stavu shora dolů pracujete dolů, prozkoumávání, experimentování a přechod aktuálního stavu do cílového stavu. I když tento navrhovaný přístup může být rychlejší, přináší značné riziko. Když se věci začnou přerušovat, můžete být uprostřed složité operace přesunutí nebo remodelace. Práce z obou směrů, shora dolů a dolů nahoru a následná schůzka uprostřed v průběhu času je složitější přístup.

Další krok

• Co je datový produkt?