Domeny danych
Siatka danych jest zasadniczo oparta na decentralizacji i dystrybucji odpowiedzialności za domeny. Jeśli naprawdę rozumiesz część firmy, najlepiej jest zarządzać skojarzonymi danymi i zapewnić jej dokładność. Jest to zasada własności danych zorientowanych na domenę.
Aby podwyższyć poziom własności danych zorientowanych na domenę, należy najpierw rozłożyć architekturę danych. Założyciel usługi Data Mesh, Zhamak Dehghani, promuje podejście Domain-Driven Design (DDD) do tworzenia oprogramowania jako przydatnej metody, aby ułatwić identyfikację domen danych.
Trudności z używaniem DDD do zarządzania danymi polega na tym, że oryginalny przypadek użycia DDD modelował złożone systemy w kontekście tworzenia oprogramowania. Nie została ona pierwotnie utworzona w celu modelowania danych przedsiębiorstwa, a dla praktyków zarządzania danymi jej metoda może być abstrakcyjna i techniczna. Często brakuje zrozumienia DDD. Praktycy uważają, że pojęcia koncepcyjne są zbyt trudne do zrozumienia lub próbują przekładać przykłady z architektury oprogramowania lub programowania obiektowego na swój krajobraz danych. Ten artykuł zawiera pragmatyczne wskazówki i jasne słownictwo, dzięki czemu można zrozumieć i używać DDD.
Projekt oparty na domenie
Wprowadzony przez Eric Evans, Domain-Driven Design jest metodą wspierania tworzenia oprogramowania, która pomaga opisać złożone systemy dla większych organizacji. Usługa DDD jest popularna, ponieważ wiele praktyk wysokiego poziomu wpływa na nowoczesne podejścia do tworzenia oprogramowania i aplikacji, takie jak mikrousługi.
DDD rozróżnia powiązane konteksty, domeny i poddomeny. Domeny to przestrzenie problemów, które chcesz rozwiązać. Są to obszary, w których spotykają się wiedza, zachowanie, prawa i działania. Zobaczysz sprzężenie semantyczne w domenach, zależności behawioralne między składnikami lub usługami. Innym aspektem domen jest komunikacja. Członkowie zespołu muszą używać języka, który cały zespół udostępnia, aby wszyscy mogli wydajnie pracować. Ten język współużytkowany jest nazywany wszechobecnym językiem lub językiem domeny .
Domeny są rozłożone na poddomeny, aby lepiej zarządzać złożonością. Typowym przykładem jest rozdzielenie domeny na poddomeny, które odpowiadają jednemu konkretnemu problemowi biznesowemu, jak pokazano w Operacjonalizacja siatki danych dla sztucznej inteligencji/uczenia maszynowego.
Nie wszystkie poddomeny są takie same. Można na przykład klasyfikować domeny jako podstawowe, ogólne lub pomocnicze. Najważniejsze są główne poddomeny. Są one tajnym sosem, składnikami, które sprawiają, że organizacja jest wyjątkowa. Poddomeny ogólne są nieokreślone i zazwyczaj łatwe do rozwiązania z produktami gotowymi. Obsługa domen podrzędnych nie oferuje przewagi konkurencyjnej, ale jest niezbędna do utrzymania działania organizacji i nie jest złożona.
Ograniczone konteksty to granice logiczne (kontekstowe). Skupiają się na przestrzeni rozwiązań: projektowaniu systemów i aplikacji. Jest to obszar, w którym sens ma skupienie się na obszarze rozwiązań. W ramach DDD może to obejmować kod, projekty baz danych itd. Między domenami a ograniczonymi kontekstami może istnieć wyrównanie, ale nie ma twardej zasady wiążącej te dwa ze sobą. Konteksty ograniczone są technicznie i mogą obejmować wiele domen i poddomen.
Zalecenia dotyczące modelowania domen
Jeśli przyjmujesz siatkę danych jako koncepcję demokratyzacji danych i wdrażasz zasadę własności danych zorientowanych na domenę, aby zwiększyć elastyczność, jak to działa w praktyce? Jak może wyglądać przejście od modelowania danych przedsiębiorstwa do modelowania projektowego opartego na domenie? Jakie wnioski można wziąć z DDD na potrzeby zarządzania danymi?
Zrób funkcjonalną dekompozycję biznesową przestrzeni problemowych
Przed zezwoleniem zespołom na kompleksowe zarządzanie danymi, należy zapoznać się z zakresem i zrozumieć obszary problemowe, które próbujesz rozwiązać. Ważne jest, aby najpierw wykonać to ćwiczenie przed przejściem do szczegółów implementacji technicznej. Po ustawieniu granic logicznych między tymi przestrzeniami problemów obowiązki stają się jaśniejsze i mogą być lepiej zarządzane.
Przyjrzyj się architekturze biznesowej podczas grupowania przestrzeni problemu. W ramach architektury biznesowej istnieją możliwości biznesowe: możliwości lub pojemności, które firma posiada lub wymienia w celu osiągnięcia określonego celu lub wyniku. Ta abstrakcja pakuje dane, procesy, organizację i technologię do określonego kontekstu, zgodnie ze strategicznymi celami biznesowymi i celami organizacji. Mapa możliwości biznesowych pokazuje, które obszary funkcjonalne wydają się być niezbędne do realizacji twojej misji i wizji.
W poniższym modelu można wyświetlić dekompozycję możliwości fikcyjnej firmy Tailwind Traders.
Firma Tailwind Traders musi opanować wszystkie obszary funkcjonalne wymienione w mapie możliwości biznesowych, aby odnieść sukces. Firma Tailwind Traders musi być w stanie sprzedawać bilety w ramach systemów zarządzania biletami online lub offline, na przykład lub mieć pilotów dostępnych do latania samolotami w ramach programu zarządzania pilotażowego. Firma może zlecić niektóre działania, zachowując jednocześnie inne jako rdzeń swojej działalności.
To, co obserwujesz w praktyce, jest to, że większość Twoich osób jest zorganizowana wokół możliwości biznesowych. Osoby pracujące nad tymi samymi możliwościami biznesowymi mają takie samo słownictwo. Dotyczy to również aplikacji i procesów, które są zwykle dobrze dopasowane i ściśle połączone w oparciu o spójność działań, które wspierają.
Mapowanie możliwości biznesowych jest doskonałym punktem wyjścia, ale twoja historia nie kończy się tutaj.
Mapuj możliwości biznesowe na aplikacje i dane
Aby lepiej zarządzać architekturą przedsiębiorstwa, dostosuj możliwości biznesowe, powiązane konteksty i aplikacje. Ważne jest, aby postępować zgodnie z pewnymi podstawowymi zasadami.
Możliwości biznesowe muszą pozostać na poziomie biznesowym i pozostać abstrakcyjne. Reprezentują to, co robi Twoja organizacja, i celują w przestrzenie problemów. Podczas implementowania zdolności biznesowej tworzona jest instancja zdolności dla określonego kontekstu. Wiele aplikacji i składników współdziała ze sobą w takich granicach w przestrzeni rozwiązania, aby zapewnić konkretną wartość biznesową.
Aplikacje i składniki dostosowane do określonej możliwości biznesowej pozostają oddzielone od aplikacji, które są zgodne z innymi możliwościami biznesowymi, ponieważ dotyczą one różnych problemów biznesowych. Ograniczone konteksty są wywodzone z możliwości biznesowych i mapowane wyłącznie na te możliwości. Reprezentują granicę implementacji możliwości biznesowych i zachowują się jak domena.
Jeśli możliwości biznesowe się zmienią, ograniczone konteksty się zmienią. Najlepiej jest oczekiwać pełnego dopasowania między domenami i odpowiadającymi ograniczonymi kontekstami, ale jak dowiesz się w kolejnych sekcjach, rzeczywistość czasami różni się od ideału.
Jeśli przypisujemy mapowanie możliwości firmie Tailwind Traders, granice ograniczonego kontekstu i wdrożenia domen mogą przypominać poniższy diagram.
Na tym diagramie zarządzanie klientami opiera się na wiedzy specjalistycznej i w związku z tym wie, jakie dane mają być używane w innych domenach. Wewnętrzna architektura zarządzania klientami jest oddzielona, więc wszystkie składniki aplikacji w tych granicach mogą komunikować się bezpośrednio przy użyciu interfejsów specyficznych dla aplikacji i modeli danych.
Produkty danych oraz jasne standardy interoperacyjności są używane do sformalizowania dystrybucji danych w innych obszarach. W tym podejściu wszystkie produkty danych są również zgodne z domeną i dziedziczą wszechobecny język, który jest skonstruowanym, sformalizowanym językiem uzgodnionym przez uczestników projektu i projektantów z tej samej domeny, aby obsłużyć potrzeby tej domeny.
Dodatkowe domeny wynikające z realizacji różnych możliwości
Pracując z mapami zdolności biznesowych, należy pamiętać, że niektóre zdolności biznesowe mogą być tworzone wielokrotnie.
Na przykład firma Tailwind Traders może mieć wiele zlokalizowanych realizacji (lub implementacji) "obsługi bagażu i utraconych przedmiotów". Załóżmy, że jedna linia działalności działa tylko w Azji. W tym kontekście "obsługa bagażu i zgubione przedmioty" to możliwość, która jest spełniona w przypadku samolotów związanych z Azją. Inna linia biznesowa może być skierowana na rynek europejski, a w tym kontekście używana jest inna zdolność do "obsługi bagażu i zagubionych przedmiotów". Ten scenariusz z wieloma wystąpieniami może prowadzić do licznych lokalnych implementacji z wykorzystaniem różnych usług technologicznych oraz oddzielnych zespołów do zarządzania tymi usługami.
Relacja zdolności biznesowych i wystąpień tych zdolności (realizacji) jest relacją jeden do wielu. Z tego powodu zostajesz z dodatkowymi (pod-) domenami.
Znajdowanie udostępnionych możliwości i obserwowanie udostępnionych danych
Sposób obsługi udostępnionych możliwości biznesowych jest ważny. Zwykle wdrażasz funkcje udostępnione centralnie, jako modele usług i udostępniasz je różnym liniom biznesowym. Przykładem takiej możliwości może być "Zarządzanie klientami". W naszym przykładzie firmy Tailwind Traders zarówno azjatyckie, jak i europejskie linie biznesowe używają tej samej administracji dla swoich klientów.
Ale jak można projektować własność danych domeny na współużytkowanej funkcji? Wielu przedstawicieli biznesowych prawdopodobnie bierze odpowiedzialność za klientów w ramach tej samej udostępnionej administracji.
Istnieje domena aplikacji i domena danych. Twoja domena i ograniczony kontekst nie są idealnie zgodne z perspektywy produktu danych. Z drugiej strony można twierdzić, że nadal istnieje jeden problem z danymi z punktu widzenia możliwości biznesowych.
W przypadku funkcji udostępnionych, takich jak złożone pakiety dostawców, rozwiązania SaaS i starsze systemy, należy zachować spójność w podejściu własności danych domeny. Własność danych można rozdzielić za pomocą produktów danych, co może wymagać ulepszeń aplikacji. W naszym przykładzie "Zarządzanie klientami" firmy Tailwind Traders różne potoki z domeny aplikacji mogą generować wiele produktów danych: jeden produkt danych dla wszystkich klientów związanych z Azją i jeden dla wszystkich klientów związanych z Europą. W takiej sytuacji wiele domen danych pochodzi z tej samej domeny aplikacji.
Możesz również poprosić domeny aplikacji o utworzenie pojedynczego produktu danych, który hermetyzuje metadane w celu odróżnienia własności danych w sobie. Możesz na przykład zarezerwować nazwę kolumny na potrzeby właścicielstwa, przypisując każdy wiersz do jednej konkretnej domeny danych.
Identyfikowanie monolitów oferujących wiele możliwości biznesowych
Zwróć również uwagę na aplikacje, które zaspokajają wiele możliwości biznesowych, które są często spotykane w dużych i tradycyjnych przedsiębiorstwach. W naszym przykładowym scenariuszu firma Tailwind Traders korzysta ze złożonego pakietu oprogramowania, aby ułatwić zarządzanie kosztami oraz "aktywa i finansowanie". Te udostępnione aplikacje są monolityczne, które zapewniają jak najwięcej funkcji, co czyni je dużymi i złożonymi. W takiej sytuacji domena aplikacji powinna być większa. To samo dotyczy własności współużytkowanej, w której kilka domen danych znajduje się w domenie aplikacji.
Wzorce projektowe dla domen zgodnych ze źródłem, ponownego przekazania i zgodnych z konsumentem
Podczas mapowania domen można wybrać wzorzec na podstawie tworzenia, konsumpcji lub ponownego dostarczania danych. W przypadku architektury można projektować szablony, które obsługują domeny na podstawie określonych cech domeny.
Domeny dostosowane do systemu źródłowego
Domeny dostosowane do systemu źródłowego są zgodne z systemami źródłowymi, z których pochodzą dane. Te systemy są zazwyczaj transakcyjne lub operacyjne.
Twoim celem jest przechwytywanie danych bezpośrednio z tych złotych systemów źródłowych. Produkty danych zoptymalizowane do odczytu z Twoich domen na potrzeby intensywnej konsumpcji danych. Ułatwianie tych domen przy użyciu ustandaryzowanych usług do przekształcania i udostępniania danych.
Te usługi, które obejmują wstępnie skonfigurowane struktury kontenerów, umożliwiają zespołom domeny zorientowanym na źródło łatwiejsze publikowanie danych. Jest to ścieżka najmniejszej odporności z minimalnymi zakłóceniami i kosztami.
Domeny dostosowane do konsumentów
Domeny dostosowane do konsumentów są przeciwieństwem domen powiązanych ze źródłem. Są one dostosowane do konkretnych przypadków użycia użytkowników końcowych, które wymagają danych z innych domen. Domeny dostosowane do klienta wykorzystują i przekształcają dane w celu dopasowania ich do przypadków użycia organizacji.
Rozważ oferowanie udostępnionych usług danych na potrzeby przekształcania i zużycia danych, aby zaspokoić te potrzeby związane z korzystaniem z nich. Można na przykład oferować niezależne od domeny możliwości infrastruktury danych, na przykład do obsługi potoków danych, infrastruktury magazynu, usług przesyłania strumieniowego, przetwarzania analitycznego itd.
Ponowne dostarczanie domen
Ponowne zastosowanie danych jest innym i trudniejszym scenariuszem. Jeśli na przykład odbiorcy podrzędni są zainteresowani kombinacją danych z różnych domen, możesz utworzyć produkty danych, które agregują dane lub łączą dane wysokiego poziomu wymagane przez wiele domen. Pozwala to uniknąć powtarzalnej pracy.
Nie twórz silnych zależności między produktami danych i analitycznymi przypadkami użycia. Staraj się zamiast tego dążyć do elastyczności i luźnego sprzężenia. Poniższy model pokazuje, jak można osiągnąć elastyczność. Domena przejmuje własność zarówno produktów danych, jak i analitycznych przypadków użycia oraz zaprojektowała oddzielne procesy tworzenia i używania danych.
Definiowanie nakładających się wzorców domeny
Modelowanie domen często jest skomplikowane, gdy dane lub logika biznesowa są współużytkowane między domenami. W organizacjach na dużą skalę domeny często korzystają z danych z innych domen. Przydatne może być posiadanie domen ogólnych, które zapewniają logikę integracji w sposób umożliwiający standaryzację innych domen podrzędnych i korzystanie z niej. Zachowaj udostępniony model między poddomenami małymi i zawsze dopasowanymi do wszechobecnego języka.
W przypadku nakładających się wymagań dotyczących danych można użyć różnych wzorców z projektowania opartego na domenie. Poniżej przedstawiono krótkie podsumowanie wzorców, z których można wybrać:
- Wzorzec rozdzielnych ścieżek można użyć, jeśli wolisz powiązany koszt duplikacji nad ponownym użyciem. Możliwość ponownego zastosowania jest poświęcana na większą elastyczność i zwinność.
- Wzorzec klienta-dostawcy może być używany, jeśli jedna domena jest silna i chce przejąć odpowiedzialność za dane i potrzeby odbiorców końcowych. Wady obejmują konfliktujące priorytety i nakłanianie zespołów podrzędnych do negocjowania wymagań dotyczących dostaw i priorytetów harmonogramu pracy.
- Wzorzec partnerstwa może być używany, gdy logika integracji jest koordynowana w sposób nieplanowany w nowo utworzonej domenie. Wszystkie zespoły współpracują między sobą i uwzględniają nawzajem swoje potrzeby. Ponieważ nikt nie może swobodnie zmieniać udostępnionej logiki, wymagane jest znaczne zaangażowanie wszystkich zaangażowanych osób.
- Wzorzec konformistyczny może być użyty do dostosowania wszystkich twoich domen do wszystkich wymagań. Użyj tego wzorca, gdy integracja jest złożona, żaden inny podmiot nie może mieć kontroli lub używasz pakietów dostawców.
We wszystkich przypadkach domeny powinny być zgodne ze standardami współdziałania. Domena partnerstwa, która tworzy nowe dane dla innych domen, musi uwidaczniać swoje produkty danych, takie jak każda inna domena, w tym przejęcie własności.
Obowiązki związane z domeną
Siatka danych decentralizuje własność danych, dystrybuując je między zespołami domeny. W przypadku wielu organizacji oznacza to przejście od scentralizowanego modelu wokół ładu do modelu federacyjnego. Zespoły domen są przypisywane do zadań, takich jak:
- Przejęcie na własność potoków danych, takich jak pozyskiwanie, czyszczenie i przekształcanie danych, w celu obsługi jak największej liczby potrzeb klientów danych
- Ulepszanie jakości danych, w tym przestrzeganie umów SLA i środków jakości ustanowionych przez użytkowników danych
- Hermetyzowanie metadanych lub używanie nazw kolumn zarezerwowanych do precyzyjnego filtrowania na poziomie wierszy i kolumn.
- Przestrzeganie standardów zarządzania metadanymi, w tym:
- Przestrzeganie standardów współdziałania danych, w tym protokołów, formatów danych i typów danych
- Zapewnianie pochodzenia danych przez połączenie systemów źródłowych i usług integracji ze skanerami lub przez ręczne dostarczanie pochodzenia
- Przestrzeganie zadań udostępniania danych, w tym przeglądów dostępu do IAM i tworzenia kontraktu danych
Poziom szczegółowości rozłączania
Teraz, gdy wiesz, jak rozpoznawać i ułatwiać domeny danych, możesz nauczyć się projektować odpowiedni poziom szczegółowości i reguł dotyczących oddzielenia domeny. Dwa ważne wymiary są w grze, gdy rozkładasz architekturę.
Stopień szczegółowości dla domen funkcjonalnych i określenie ograniczonych kontekstów stanowi jeden z wymiarów. Domeny są zgodne z określonym sposobem pracy, zapewniając, że dane stają się dostępne dla wszystkich domen przy użyciu usług udostępnionych, przejmowania własności, przestrzegania standardów metadanych itd.
Ustaw szczegółowe granice, jeśli jest to możliwe w przypadku dystrybucji danych. Bycie opartym na danych polega na udostępnianiu danych do intensywnego ponownego użycia. Jeśli granice będą zbyt luźne, wymusisz niepożądane sprzężenia między wieloma aplikacjami i utracisz możliwość ponownego korzystania z danych. Staraj się o rozdzielanie za każdym razem, gdy dane przekraczają granice możliwości biznesowych. W obrębie domeny dozwolone jest ścisłe sprzężenie w jej wewnętrznej architekturze. Jednak w przypadku przekraczania granic możliwości biznesowych domeny muszą pozostać oddzielone i dystrybuować produkty danych zoptymalizowane pod kątem odczytu do udostępniania innym domenom.
Stopień szczegółowości dla domen technicznych i wykorzystania infrastruktury jest innym ważnym wymiarem. Strefy lądowania danych umożliwiają elastyczność w obsłudze aplikacji danych , które tworzą produkty danych. Jak utworzyć tego rodzaju strefę docelową z udostępnioną infrastrukturą i usługami poniżej? Domeny funkcjonalne są logicznie grupowane razem i są dobrymi kandydatami do udostępniania infrastruktury platformy. Poniżej przedstawiono kilka czynników, które należy wziąć pod uwagę podczas tworzenia tych stref docelowych:
- Spójność i wydajność podczas pracy z danymi i ich udostępniania to silny czynnik dopasowania domen funkcjonalnych do strefy docelowej danych. Dotyczy to grawitacji danych, tendencji do ciągłego udostępniania dużych produktów danych między domenami.
- Granice regionalne mogą spowodować zaimplementowanie dodatkowych stref docelowych danych.
- Własność, zabezpieczenia lub granice prawne mogą wymuszać segregację domen. Na przykład niektóre dane nie mogą być widoczne dla innych domen.
- Elastyczność i tempo zmian są ważnymi motorami. Niektóre domeny mogą mieć wysoką szybkość innowacji, podczas gdy inne domeny zdecydowanie cenią stabilność.
- Granice funkcjonalne mogą rozdzielać zespoły. Przykładem mogą być granice zorientowane na źródło i zorientowane na konsumentów. Połowa zespołów domenowych może cenić pewne usługi bardziej niż inne.
- Jeśli chcesz potencjalnie sprzedać lub wydzielić swoje zdolności, powinieneś unikać ścisłej integracji z usługami udostępnionymi z innych domen.
- Rozmiar zespołu, umiejętności i dojrzałość mogą być ważnymi czynnikami. Wysoko wykwalifikowane i dojrzałe zespoły często wolą obsługiwać własne usługi i infrastrukturę, podczas gdy mniej dojrzałe zespoły raczej nie docenią dodatkowego nakładu związanego z utrzymaniem platformy.
Przed aprowizowaniem wielu stref docelowych danych przyjrzyj się dekompozycji domeny i określ, jakie domeny funkcjonalne są kandydatami do udostępniania podstawowej infrastruktury.
Streszczenie
Modelowanie możliwości biznesowych pomaga lepiej rozpoznawać i organizować domeny w architekturze siatki danych. Zapewnia całościowy wgląd w sposób, w jaki dane i aplikacje zapewniają wartość twojej firmie, jednocześnie ułatwiając ustalanie priorytetów i skupienie się na strategii danych i potrzebach biznesowych. Możesz również używać modelowania możliwości biznesowych w celu uzyskania więcej niż tylko danych. Jeśli na przykład skalowalność jest problemem, możesz użyć tego modelu do zidentyfikowania najważniejszych podstawowych możliwości i opracowania strategii dla nich.
Niektórzy praktycy zgłaszają obawy, że tworzenie architektury stanu docelowego przez mapowanie wszystkiego z góry jest intensywnym ćwiczeniem. Sugerują oni, aby identyfikować domeny w sposób organiczny podczas wprowadzania ich do nowej architektury siatki danych. Zamiast definiować stan docelowy z góry w dół, pracujesz do dołu, eksplorujesz, eksperymentujesz i przenosisz bieżący stan do stanu docelowego. Chociaż proponowane podejście może być szybsze, niesie ze sobą znaczne ryzyko. Możesz łatwo być w środku złożonego przenoszenia lub operacji przebudowy, gdy rzeczy zaczynają się psuć. Praca z obu kierunków, od góry do dołu i od dołu do góry, a następnie stopniowe spotkanie w środku, jest bardziej zniuansowanym podejściem.