Identyfikowanie granic modelu domeny dla każdej mikrousługi

Wskazówka

Ta treść jest fragmentem eBooka "Architektura mikrousług .NET dla konteneryzowanych aplikacji .NET", dostępnego na .NET Docs lub jako bezpłatny plik PDF do pobrania i czytania w trybie offline.

Pobierz plik PDF

Celem identyfikacji granic i rozmiaru modelu dla każdej mikrousługi nie jest uzyskanie najbardziej szczegółowego rozdzielenia, chociaż w miarę możliwości należy dążyć do małych mikrousług. Zamiast tego twoim celem powinno być uzyskanie najbardziej znaczącej separacji opartej na wiedzy domenowej. Nacisk nie jest na rozmiar, lecz na możliwości biznesowe. Ponadto, jeśli istnieje wyraźna spójność wymagana dla określonego obszaru aplikacji na podstawie dużej liczby zależności, oznacza to również potrzebę pojedynczej mikrousługi. Spójność to sposób identyfikowania sposobu dzielenia się mikrousług lub grupowania ich. Ostatecznie, zdobywając większą wiedzę na temat domeny, należy odpowiednio dostosować rozmiar mikrousługi. Znalezienie odpowiedniego rozmiaru nie jest procesem jednorazowym.

Sam Newman, uznany promotor mikrousług i autor książki Building Microservices, podkreśla, że należy zaprojektować mikrousługi na podstawie wzorca ograniczonego kontekstu (BC) (część projektu opartego na domenie), jak pokazano wcześniej. Czasami BC może być złożony z kilku fizycznych usług, ale nie odwrotnie.

Model domeny z określonymi jednostkami domeny ma zastosowanie w ramach konkretnego bc lub mikrousługi. BC rozdziela zastosowanie modelu domeny i zapewnia członkom zespołu deweloperów jasne i wspólne zrozumienie tego, co musi być zgodne i co można opracowywać niezależnie. Są to te same cele dla mikrousług.

Innym narzędziem, które informuje o wyborze projektu, jest prawo Conwaya, które stwierdza, że aplikacja będzie odzwierciedlać granice społeczne organizacji, która ją wyprodukowała. Czasami jest odwrotnie, -the organizacja firmy jest tworzona przez oprogramowanie. Może być konieczne odwrócenie prawa Conwaya i zbudowanie granic tak, jak chcesz, aby firma była zorganizowana, skupiając się na doradztwie w zakresie procesów biznesowych.

Aby zidentyfikować powiązane konteksty, można użyć wzorca DDD o nazwie Wzorzec mapowania kontekstu. Za pomocą mapowania kontekstu można zidentyfikować różne konteksty w aplikacji i ich granicach. Często istnieje inny kontekst i granica dla każdego małego podsystemu, na przykład. Mapa kontekstu to sposób definiowania i określania jawnych granic między domenami. Bc jest autonomiczny i zawiera szczegóły pojedynczej domeny -details, takie jak jednostki domeny, i definiuje kontrakty integracji z innymi BC. Jest to podobne do definicji mikrousługi: jest ona autonomiczna, implementuje pewne możliwości domeny i musi zapewniać interfejsy. Dlatego mapowanie kontekstu i wzorzec ograniczonego kontekstu są dobrymi metodami identyfikowania granic modelu domeny mikrousług.

Podczas projektowania dużej aplikacji zauważysz, jak jej model domeny może zostać rozdrobiony — na przykład ekspert domeny katalogu nazwie jednostki inaczej w domenach katalogu i spisu niż ekspert domeny wysyłki. Lub jednostka domeny użytkownika może być inna w rozmiarze i liczbie atrybutów podczas pracy z ekspertem CRM, który chce przechowywać wszystkie szczegóły dotyczące klienta niż dla eksperta ds. zamawiania domeny, który potrzebuje tylko częściowych danych o kliencie. Bardzo trudno jest uściślać wszystkie terminy domeny we wszystkich domenach związanych z dużą aplikacją. Ale najważniejszą rzeczą jest to, że nie należy próbować ujednolicić terminów. Zamiast tego zaakceptuj różnice i bogactwo udostępniane przez każdą domenę. Jeśli spróbujesz wdrożyć ujednoliconą bazę danych dla całej aplikacji, próby ujednolicenia słownictwa będą niezręczne i nie będą odpowiadać żadnemu z wielu ekspertów dziedzinowych. W związku z tym BCs (zaimplementowane jako mikrousługi) pomogą Ci wyjaśnić, gdzie można używać określonych terminów domenowych i gdzie należy podzielić system i utworzyć dodatkowe BCs z różnych domen.

Będziesz wiedzieć, że masz odpowiednie granice i rozmiary każdego modelu BC i domeny, jeśli masz kilka silnych relacji między modelami domeny, a zwykle nie trzeba scalać informacji z wielu modeli domeny podczas wykonywania typowych operacji aplikacji.

Być może najlepszą odpowiedzią na pytanie, jak duży powinien być model domeny dla każdej mikrousługi jest taka: model powinien mieć samodzielny kontekst biznesowy, odizolowany jak to możliwe, co umożliwia pracę bez konieczności ciągłego przełączania się do innych kontekstów (modeli innych mikrousług). Na rysunku 4–10 widać, jak wiele mikrousług (wiele kontrolerów domeny) ma własny model i sposób definiowania ich jednostek, w zależności od konkretnych wymagań dla każdej zidentyfikowanej domeny w aplikacji.

Rysunek 4–10. Identyfikowanie granic modelu mikrousług i jednostek

Rysunek 4–10 przedstawia przykładowy scenariusz związany z systemem zarządzania konferencjami online. Ta sama jednostka jest wyświetlana jako "Users", "Buyers", "Payers" i "Customers" w zależności od ograniczonego kontekstu. Zidentyfikowaliście kilka kontekstów ograniczonych, które można zaimplementować jako mikrousługi, na podstawie dziedzin zdefiniowanych przez ekspertów dziedzinowych. Jak widać, istnieją jednostki, które są obecne tylko w jednym modelu mikrousług, takich jak Płatności w mikrousłudze Płatności. Będą one łatwe do zaimplementowania.

Jednak mogą istnieć również jednostki, które mają inny kształt, ale współdzielą tę samą tożsamość w wielu modelach domeny z wielu mikrousług. Na przykład jednostka Użytkownik jest identyfikowana w mikrousłudze Zarządzania konferencjami. Ten sam użytkownik, z tą samą tożsamością, jest nazywany Nabywcą w mikrousłudze Zamawianie, Płatnikiem w mikrousłudze Płatności, a nawet Klientem w mikrousłudze Obsługa Klienta. Jest to spowodowane tym, że w zależności od wszechobecnego języka używanego przez każdego eksperta od domeny użytkownik może mieć inną perspektywę nawet z różnymi atrybutami. Jednostka użytkownika w modelu mikrousług o nazwie Conferences Management może mieć większość atrybutów danych osobowych. Jednak ten sam użytkownik jako Płatnik w mikrousłudze Płatności lub jako Klient w mikrousłudze Obsługi Klienta może nie potrzebować tej samej listy atrybutów.

Podobne podejście przedstawiono na rysunku 4-11.

Rysunek 4–11. Rozdzielanie tradycyjnych modeli danych na wiele modeli domenowych

Podczas dekompozycji tradycyjnego modelu danych między powiązanymi kontekstami można mieć różne jednostki, które współdzielą tę samą tożsamość (kupujący jest również użytkownikiem) z różnymi atrybutami w każdym powiązanym kontekście. Możesz zobaczyć, jak użytkownik jest obecny w modelu mikrousług Zarządzania konferencjami jako jednostka Użytkownik, a także jest obecny w formie jednostki Nabywca w mikrousłudze Cennik z atrybutami alternatywnymi lub szczegółami dotyczącymi użytkownika, gdy jest on rzeczywiście nabywcą. Każda mikrousługa lub bc może nie potrzebować wszystkich danych związanych z jednostką Użytkownik, tylko jej częścią, w zależności od problemu do rozwiązania lub kontekstu. Na przykład w modelu mikrousługi dotyczącej Cen nie potrzebujesz adresu ani nazwy użytkownika, tylko identyfikatora (jako oznaczenia tożsamości) i statusu, które wpłynie na przyznawanie rabatów przy ustalaniu cen miejsc dla kupujących.

Jednostka Seat ma taką samą nazwę, ale różne atrybuty w każdym modelu domeny. Jednak tożsamość Seat jest oparta na tym samym identyfikatorze, podobnie jak w przypadku użytkownika i nabywcy.

Zasadniczo istnieje wspólna koncepcja użytkownika, który istnieje w wielu usługach (domenach), które współdzielą tożsamość tego użytkownika. Jednak w każdym modelu domeny mogą istnieć dodatkowe lub inne szczegóły dotyczące jednostki użytkownika. W związku z tym należy zamapować jednostkę użytkownika z jednej domeny (mikrousługi) na inną.

Istnieje kilka korzyści wynikających z nieudostępniania tej samej jednostki użytkownika z identyczną liczbą atrybutów w różnych domenach. Jedną z zalet jest zmniejszenie duplikacji, dzięki czemu modele mikrousług nie mają żadnych danych, których nie potrzebują. Kolejną korzyścią jest posiadanie podstawowej mikrousługi, która jest właścicielem określonego typu danych na jednostkę, dzięki czemu aktualizacje i zapytania dotyczące tego typu danych są oparte tylko na tej mikrousłudze.

PoprzedniNastępny