Używanie analizy domeny do modelowania mikrousług

Jednym z największych wyzwań mikrousług jest zdefiniowanie granic poszczególnych usług. Ogólna zasada polega na tym, że usługa powinna wykonywać "jedną rzecz", ale wprowadzenie tej reguły do praktyki wymaga starannego przemyślenia. Nie ma procesu mechanicznego, który będzie produkować "właściwy" projekt. Musisz głęboko zastanowić się nad domeną biznesową, wymaganiami i celami. W przeciwnym razie można skończyć z haphazard design, który wykazuje pewne niepożądane cechy, takie jak ukryte zależności między usługami, ścisłe sprzęganie lub słabo zaprojektowane interfejsy. W tym artykule przedstawiono podejście oparte na domenie do projektowania mikrousług.

W tym artykule użyto usługi dostarczania dronów jako działającego przykładu. Więcej informacji na temat scenariusza i odpowiedniej implementacji referencyjnej można znaleźć tutaj.

Wprowadzenie

Mikrousługi powinny być zaprojektowane wokół możliwości biznesowych, a nie warstw poziomych, takich jak dostęp do danych lub obsługa komunikatów. Ponadto powinny mieć luźne sprzężenia i wysoką spójność funkcjonalną. Mikrousługi są luźno powiązane , jeśli można zmienić jedną usługę bez konieczności jednoczesnego aktualizowania innych usług. Mikrousługę jest spójna , jeśli ma jeden, dobrze zdefiniowany cel, taki jak zarządzanie kontami użytkowników lub śledzenie historii dostarczania. Usługa powinna hermetyzować wiedzę o domenie i abstrakować wiedzę od klientów. Na przykład klient powinien mieć możliwość planowania drona bez znajomości szczegółów algorytmu planowania lub sposobu zarządzania flotą dronów.

Projektowanie oparte na domenach znacznie ułatwia opracowanie zestawu dobrze zaprojektowanych mikrousług. Projektowanie DDD ma dwie odrębne fazy: strategiczną i taktyczną. W fazie strategicznej definiuje się ogólną strukturę systemu. Projektowanie strategiczne zapewnia ukierunkowanie architektury na zdolności biznesowe. W fazie taktycznej używany jest zestaw wzorców projektowych, które pozwalają utworzyć model domeny. Wzorce te obejmują jednostki, agregacje i usługi domenowe. Wzorce taktyczne ułatwiają projektowanie luźno powiązanych, spójnych mikrousług.

W tym artykule i następnym omówimy następujące kroki, stosując je do aplikacji Drone Delivery:

1. Zacznij od przeanalizowania domeny biznesowej, aby poznać wymagania funkcjonalne aplikacji. W efekcie powstanie nieformalny opis domeny, który można przekształcić w bardziej formalny zestaw modeli domeny.

2. Następnie zdefiniuj powiązane konteksty domeny. Każdy ograniczony kontekst zawiera model domeny, który reprezentuje konkretną poddomenę większej aplikacji.

3. Stosowanie taktycznych wzorców DDD w ramach ograniczonego kontekstu w celu zdefiniowania jednostek, agregacji i usług domenowych.

4. Użyj wyników z poprzedniego kroku, aby zidentyfikować mikrousługi w aplikacji.

W tym artykule omówiono pierwsze trzy kroki, które dotyczą głównie DDD. W następnym artykule zidentyfikujemy mikrousługi. Należy jednak pamiętać, że DDD jest iteracyjnym, trwającym procesem. Granice usługi nie są stałe w kamieniu. W miarę rozwoju aplikacji możesz zdecydować się na podzielenie usługi na kilka mniejszych usług.

Scenariusz: dostarczanie dronów

Firma Fabrikam, Inc. uruchamia usługę dostarczania za pomocą dronów. Firma zarządza flotą dronów. Firmy rejestrują się w usłudze, a użytkownicy mogą zamówić drona, który pobierze towary do dostarczenia. Gdy klient planuje pobranie, system wewnętrznej bazy danych przypisuje drona i powiadamia użytkownika o szacowanym czasie dostawy. Gdy trwa dostarczanie, klient może śledzić położenie drona i na bieżąco aktualizowany szacowany czas dostawy.

Ten scenariusz obejmuje dość skomplikowaną domenę. Niektóre kwestie biznesowe to między innymi planowanie dronów, śledzenie paczek, zarządzanie kontami użytkowników oraz przechowywanie i analizowanie danych historycznych. Ponadto firma Fabrikam chce szybko wejść na rynek i szybko się rozwijać, dodając nowe funkcje i możliwości. Aplikacja musi działać w skali chmury na wysokim docelowym poziomie usług (SLO). Firma Fabrikam oczekuje również, że różne części systemu będą miały bardzo różne wymagania dotyczące magazynowania danych i wykonywania zapytań. Wszystkie te kwestie powodują, że firma Fabrikam wybiera dla aplikacji Drone Delivery architekturę mikrousług.

Analizowanie domeny

Użycie podejścia DDD pomoże Ci zaprojektować mikrousługi, dzięki czemu każda usługa stanowi naturalne dopasowanie do funkcjonalnego wymagania biznesowego. Może to pomóc uniknąć pułapki zezwalania na granice organizacyjne lub wybory technologiczne dyktują projekt.

Przed napisaniem dowolnego kodu potrzebny jest widok systemu, który tworzysz. DDD rozpoczyna się od modelowania domeny biznesowej i tworzenia modelu domeny. Model domeny jest abstrakcyjnym modelem domeny biznesowej. Umożliwia on przetworzenie i uporządkowanie informacji o domenie oraz udostępnia język używany przez deweloperów i specjalistów w zakresie domeny.

Należy zacząć od utworzenia mapy wszystkich funkcji biznesowych oraz ich połączeń. W praktyce w kroku tym biorą udział specjaliści w zakresie domeny, architekci oprogramowania oraz inni uczestnicy projektu. Nie trzeba trzymać się jakiejś formalnej konwencji. Można naszkicować diagram lub narysować plan na tablicy.

Wypełniając diagram, można zacząć identyfikować konkretne poddomeny. Które funkcje są ściśle powiązane? Które funkcje są kluczowe dla firmy, a które zapewniają usługi pomocnicze? Jaki jest graf zależności? W tej wstępnej fazie nie uwzględnia się technologii ani szczegółów implementacji. Należy jednak określić, w którym miejscu aplikacja musi zostać zintegrowana z systemami zewnętrznymi, takimi jak CRM, płatności lub rozliczenia.

Przykład: aplikacja dostarczania dronów

Po początkowej analizie domeny zespół firmy Fabrikam wymyślił szorstki szkic przedstawiający domenę Drone Delivery.

• Wysyłka jest umieszczana w środku diagramu, ponieważ jest ona kluczowa dla firmy. Wszystkie inne elementy na diagramie istnieją, aby włączyć tę funkcję.
• Zarządzanie dronami jest również kluczowe dla firmy. Funkcje ściśle związane z zarządzaniem dronami obejmują naprawę dronów i korzystanie z analizy predykcyjnej do przewidywania, kiedy drony wymagają obsługi i konserwacji.
• Analiza ETA zapewnia oszacowanie czasu odbioru i dostawy.
• Transport innych firm umożliwi aplikacji zaplanowanie alternatywnych metod transportu, jeśli pakiet nie może być dostarczany całkowicie przez drona.
• Udostępnianie dronów to możliwe rozszerzenie podstawowej działalności firmy. Firma może mieć nadmiar pojemności dronów w określonych godzinach i może wynajmować drony, które w przeciwnym razie byłyby bezczynne. Ta funkcja nie będzie dostępna w wersji początkowej.
• Nadzór wideo jest kolejnym obszarem, który firma może rozwinąć się później.
• Konta użytkowników, fakturowanie i centrum połączeń to poddomeny, które obsługują podstawową działalność.

Zwróć uwagę, że w tym momencie procesu nie podjęliśmy żadnych decyzji dotyczących implementacji ani technologii. Niektóre podsystemy mogą obejmować zewnętrzne systemy oprogramowania lub usługi innych firm. Mimo to aplikacja musi wchodzić w interakcje z tymi systemami i usługami, dlatego ważne jest, aby uwzględnić je w modelu domeny.

Definiowanie ograniczonych kontekstów

Model domeny będzie zawierać reprezentacje rzeczywistych elementów — użytkowników, dronów, paczek itd. Nie oznacza to jednak, że w każdej części systemu te same rzeczy muszą być jednakowo reprezentowane.

Na przykład podsystemy obsługujące naprawę dronów i analizę predykcyjną będą musiały reprezentować wiele cech fizycznych dronów, takich jak ich historia konserwacji, przebieg, wiek, numer modelu, charakterystyka wydajności itd. Natomiast podczas planowania dostawy dane te nie są istotne. W podsystemie planowania muszą znajdować się tylko informacje dotyczące dostępności drona oraz szacowanego czasu odbioru i dostarczenia paczki.

Gdybyśmy spróbowali utworzyć jeden model dla obu tych podsystemów, byłby on niepotrzebnie skomplikowany. Ponadto wraz z upływem czasu rozwijanie tego modelu stałoby się trudniejsze, ponieważ wszelkie zmiany należałoby dostosować do wymagań wielu zespołów pracujących nad oddzielnymi podsystemami. W związku z tym często lepiej jest zaprojektować oddzielne modele reprezentujące ten sam rzeczywisty element (w tym przypadku dron) w dwóch różnych kontekstach. Każdy model zawiera tylko te cechy i atrybuty, które są istotne w określonym kontekście.

W tym miejscu wchodzi w grę koncepcja DDD ograniczonych kontekstów . Ograniczony kontekst odpowiada po prostu granicom, w których jest stosowany konkretny model domeny. Z poprzedniego diagramu wynika, że można pogrupować funkcje zależnie od tego, czy należą one do jednego modelu domeny.

Ograniczone konteksty nie muszą być odizolowane od siebie. Na tym diagramie linie stałe łączące ograniczone konteksty reprezentują miejsca, w których współdziałają dwa ograniczone konteksty. Na przykład usługa Shipping zależy od kont użytkowników, aby uzyskać informacje o klientach oraz na temat zarządzania dronami, aby zaplanować drony z floty.

W książce Domain Driven Design Eric Evans opisuje kilka wzorców utrzymania integralności modelu domeny podczas interakcji z innym powiązanym kontekstem. Jedną z głównych zasad mikrousług jest to, że usługi komunikują się za pośrednictwem dobrze zdefiniowanych interfejsów API. To podejście odpowiada dwóm wzorcom, które Evans wywołuje usługę Open Host Service i Published Language. Ideą usługi Open Host jest to, że podsystem definiuje formalny protokół (API) dla innych podsystemów do komunikowania się z nim. Język opublikowany rozszerza ten pomysł, publikując interfejs API w postaci, która może być używana przez inne zespoły do pisania klientów. W artykule Projektowanie interfejsów API dla mikrousług omawiamy używanie specyfikacji OpenAPI ( wcześniej znanej jako Swagger) do definiowania opisów interfejsów niezależnie od języka dla interfejsów API REST wyrażonych w formacie JSON lub YAML.

W pozostałej części tej podróży skoncentrujemy się na powiązanym kontekście wysyłki.

Następne kroki

Po zakończeniu analizy domeny następnym krokiem jest zastosowanie taktycznej domeny DDD w celu zdefiniowania modeli domeny z większą dokładnością.

Powiązane zasoby

• Projektowanie architektury mikrousług
• Projektowanie architektury mikrousług
• Identyfikowanie granic mikrousługi
• Wybieranie opcji obliczeń platformy Azure dla mikrousług