Identyfikowanie granic modelu domeny dla każdej mikrousługi
Napiwek
Ta zawartość jest fragmentem książki eBook, architektury mikrousług platformy .NET dla konteneryzowanych aplikacji platformy .NET dostępnych na platformie .NET Docs lub jako bezpłatnego pliku PDF, który można odczytać w trybie offline.
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 prowadzonej przez wiedzę o domenie. Nacisk nie jest na rozmiar, ale zamiast 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 składać się z kilku usług fizycznych, 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. Ale czasami odwrotnie jest prawdą - organizacja firmy jest tworzona przez oprogramowanie. Może być konieczne odwrócenie prawa Conwaya i zbudowanie granic w sposób, w jaki firma ma być zorganizowana, pochylając się na doradztwo 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 — szczegóły, takie jak jednostki domeny — i definiuje kontrakty integracji z innymi kontrolerami domeny. 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 zobaczysz, jak można rozdrobnić jej model domeny — ekspert domeny z domeny katalogu będzie nazywać jednostki inaczej w domenach wykazu i spisu niż ekspert domeny wysyłki, na przykład. 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 mieć ujednoliconą bazę danych dla całej aplikacji, próby ujednoliconego słownictwa będą niezręczne i nie będą miały prawa do żadnego z wielu ekspertów z dziedziny. W związku z tym kontrolery BCs (zaimplementowane jako mikrousługi) pomogą Ci wyjaśnić, gdzie można używać określonych terminów domeny i gdzie należy podzielić system i utworzyć dodatkowe kontrolery domeny z różnymi domenami.
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: powinien mieć autonomiczną usługę BC, tak odizolowaną, jak to możliwe, która umożliwia pracę bez konieczności ciągłego przełączania się do innych kontekstów (modele 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. Zidentyfikowano kilka kontrolerów domeny, które można zaimplementować jako mikrousługi, na podstawie domen zdefiniowanych przez ekspertów domeny. Jak widać, istnieją jednostki, które znajdują się 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 jednym o nazwie Nabywcy w mikrousłudze Zamawianie lub o nazwie Payer w mikrousłudze Płatności, a nawet o nazwie Klient w mikrousłudze obsługi 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 w kształcie płatnika w płatności mikrousług lub w kształcie Klienta w usłudze obsługi klienta mikrousługi może nie potrzebować tej samej listy atrybutów.
Podobne podejście przedstawiono na rysunku 4-11.
Rysunek 4–11. Dekompozycja tradycyjnych modeli danych w wielu modelach domeny
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 Cen nie potrzebujesz adresu ani nazwy użytkownika, tylko identyfikatora (jako tożsamości) i stanu, co będzie miało wpływ na rabaty w przypadku ustalania cen miejsc na nabywcę.
Jednostka Seat ma taką samą nazwę, ale różne atrybuty w każdym modelu domeny. Jednak tożsamość udziałów Seat jest oparta na tym samym identyfikatorze, co dzieje się z użytkownikiem i nabywcą.
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, aby nie udostępniać tej samej jednostki użytkownika z taką samą liczbą atrybutów w 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.
