Domeny danych

Siatka danych, w rdzeń, jest oparta na decentralizacji i dystrybucji odpowiedzialności dla domen. Jeśli naprawdę rozumiesz tę 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 utworzyć dekompozycję architektury 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 również zrozumienia DDD. Praktycy uważają, że pojęcia koncepcyjne są zbyt trudne do zrozumienia lub próbują projektować przykłady z architektury oprogramowania lub programowania obiektowego na ich 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 to metoda wspierania tworzenia oprogramowania, która ułatwia opisywanie złożonych systemów dla większych organizacji. Usługa DDD jest popularna, ponieważ wiele z jej praktyk wysokiego poziomu wpływa na nowoczesne podejścia do tworzenia oprogramowania i aplikacji dla takich rzeczy, 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 udostępniony 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 sekcji 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 zwykle 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 ma sens dopasowanie koncentracji na przestrzeni rozwiązania. W ramach DDD może to obejmować kod, projekty baz danych itd. Między domenami i powiązanymi kontekstami można wyrównać, nie ma twardej reguły powiązania tych dwóch 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?

Tworzenie funkcjonalnego dekompozycji biznesowej przestrzeni problemu

Przed zezwoleniem zespołom na zakończenie działania danych należy przyjrzeć się zakresowi i zrozumieć przestrzenie problemu, 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 będziesz obserwować w praktyce, jest to, że większość Twoich osób jest zorganizowana wokół możliwości biznesowych. Osoby pracy 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 zasadami, tak jak to robisz.

Możliwości biznesowe muszą pozostać na poziomie biznesowym i pozostać abstrakcyjne. Reprezentują one to, co robi Twoja organizacja i które są skierowane do przestrzeni problemu. Podczas implementowania możliwości biznesowych tworzona jest realizacja (wystąpienie możliwości) dla określonego kontekstu. Wiele aplikacji i składników współdziała ze sobą w ramach takich granic 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. Powiązane konteksty pochodzą z funkcji biznesowych i są mapowane wyłącznie na możliwości biznesowe. 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 oczekiwać pełnego wyrównania między domenami i odpowiadającymi powiązanymi kontekstami, ale jak dowiesz się w kolejnych sekcjach, rzeczywistość czasami różni się od idealnego.

Jeśli projektujemy mapowanie możliwości na firmę Tailwind Traders, ograniczone granice kontekstu i implementacje domen mogą wyglądać podobnie do poniższego diagramu.

Na tym diagramie zarządzanie klientami opiera się na wiedzy specjalistycznej i w związku z tym wie, jakie dane mają służyć innym domenom. 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 i modeli danych specyficznych dla aplikacji.

Produkty danych i jasne standardy współdziałania są używane do sformalizowania dystrybucji danych w innych domenach. 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 z wielu realizacji możliwości

Podczas pracy z funkcjami biznesowymi należy pamiętać, że niektóre możliwoś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 jest używana inna możliwość "obsługi bagażu i utraconych przedmiotów". Ten scenariusz wielu wystąpień może prowadzić do wielu zlokalizowanych implementacji przy użyciu różnych usług technologicznych i rozłącznych zespołów do obsługi tych usług.

Relacja możliwości biznesowych i wystąpień możliwości (realizacji) to jeden do wielu. W związku z tym w końcu są dodatkowe (pod-) domeny.

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. "Zarządzanie klientami" może być przykładem takiej możliwości. 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, którzy w ramach tej samej udostępnionej administracji.

Istnieje domena aplikacji i domena danych. Domena i ograniczony kontekst nie są idealnie wyrównane z punktu widzenia 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 dla własności, mapowanie każdego wiersza na jedną konkretną domenę 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 używa złożonego pakietu oprogramowania w celu ułatwienia zarówno zarządzania kosztami, jak i "aktywów i finansowania". 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 wyrównanych do źródła, ponownego dostarczenia i domen dostosowanych do konsumentów

Podczas mapowania domen można wybrać wzorzec na podstawie tworzenia, zużycia lub ponownego wybierania 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 pod kątem odczytu z Twoich domen na potrzeby intensywnego użycia 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 wyrównanych do źródła. 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 wdrażanie 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 dla produktów danych, jak i analitycznych przypadków użycia, i 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ć:

• Można użyć oddzielnego wzorca sposobów , jeśli wolisz skojarzony koszt duplikowania w związku z ponownym użyciem. Możliwość ponownego zastosowania jest poświęcana na większą elastyczność i elastyczność.
• Wzorzec dostawcy klienta może być używany, jeśli jedna domena jest silna i chce przejąć własność danych i potrzeb odbiorców podrzędnych. Wady obejmują sprzeczne obawy i zmuszanie zespołów podrzędnych do negocjowania elementów dostarczanych i priorytetów harmonogramu.
• 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ą ze sobą i traktują ich potrzeby. Ponieważ nikt nie może swobodnie zmieniać udostępnionej logiki, wymagane jest znaczne zaangażowanie wszystkich zaangażowanych osób.
• Wzorzec zgodności może służyć do zgodności wszystkich domen ze wszystkimi wymaganiami. Użyj tego wzorca, gdy praca integracji jest złożona, żadna inna podmioty 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 klienta danych
• Poprawa jakości danych, w tym przestrzeganie umów SLA i środków jakości ustanowionych przez konsumentów danych
• Hermetyzowanie metadanych lub używanie nazw kolumn zarezerwowanych na potrzeby filtrowania na poziomie wiersza i kolumny
• Przestrzeganie standardów zarządzania metadanymi, w tym:
  • Rejestracja schematu aplikacji i systemu źródłowego
  • Metadane w celu zwiększenia możliwości odnajdywania
  • Informacje o wersji
  • Łączenie atrybutów danych i terminów biznesowych
  • Integralność informacji o metadanych w celu umożliwienia lepszej integracji między domenami
• 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 decoupling

Teraz 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 ustawiania ograniczonych kontekstów jest jednym wymiarem. 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ę decoupling za każdym razem, gdy dane przekraczają granice możliwości biznesowych. W domenie ścisłe sprzężenie w wewnętrznej architekturze domeny jest dozwolone. 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 docelowe danych umożliwiają elastyczność obsługi 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 domeny może cenić niektóre usługi w innych.
• Jeśli chcesz potencjalnie sprzedać lub oddzielić możliwości, należy 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 wykwalifikowanych i dojrzałych zespołów często wolą obsługiwać własne usługi i infrastrukturę, podczas gdy mniej dojrzałe zespoły są mniej prawdopodobne, aby docenić dodatkowe koszty konserwacji platformy.

Przed aprowizowaniem wielu stref docelowych danych przyjrzyj się dekompozycji domeny i określ, jakie domeny funkcjonalne są kandydatami do udostępniania podstawowej infrastruktury.

Podsumowanie

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. Zamiast tego sugerują one, że domeny są identyfikowane w sposób organiczny podczas dołączania 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 wszystko zaczyna się przerywać. Praca z obu kierunków, od góry do dołu i do dołu, a następnie spotkanie w środku w czasie jest bardziej zniuansowane podejście.

Następny krok

• Co to jest produkt danych?