Używanie analizy domen do modelowania mikrousług
Jednym z największych wyzwań związanych z mikrousługami 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 w życie 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, charakterystykami architektury (znanymi również jako wymagania niefunkcjonalne) i celami. W przeciwnym razie można skończyć z przypadkowym projektem, który wykazuje pewne niepożądane cechy, takie jak ukryte zależności między usługami, ciasne sprzęganie lub źle zaprojektowane interfejsy. W tym artykule przedstawiono oparte na domenie podejście do projektowania mikrousług. Ocena granic usług to ciągły wysiłek w zakresie zmieniających się obciążeń. Czasami ocena powoduje ponowne zdefiniowanie definicji istniejących granic wymagających dodatkowego tworzenia aplikacji w celu uwzględnienia zmian.
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ługa 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. Charakterystykę architektury należy zdefiniować dla każdej mikrousługi, aby odpowiadała jej problemom z domeną, zamiast być definiowana dla całego systemu. Na przykład mikrousługi, z którymi boryka się klient, może być konieczne posiadanie wydajności, dostępności, odporności na uszkodzenia, zabezpieczeń, możliwości testowania i elastyczności. Mikrousługa zaplecza może wymagać tylko odporności na uszkodzenia i zabezpieczeń. Jeśli mikrousługi mają synchroniczną komunikację ze sobą, zależność między nimi często generuje potrzebę współużytkowania tych samych cech architektury.
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:
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.
Następnie zdefiniuj ograniczone konteksty domeny. Każdy ograniczony kontekst zawiera model domeny, który reprezentuje konkretną poddomenę większej aplikacji.
Stosowanie taktycznych wzorców DDD w ramach ograniczonego kontekstu w celu zdefiniowania jednostek, agregacji i usług domenowych.
Użyj wyników z poprzedniego kroku, aby zidentyfikować mikrousługi w aplikacji.
W tym artykule omówiono trzy pierwsze 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.
Uwaga
Ten artykuł nie zawiera kompletnej ani wyczerpującej analizy domen. Celowo zachowaliśmy krótki przykład, aby zilustrować główne kwestie. W celu uzyskania dodatkowych informacji na temat projektowania DDD zalecamy zapoznanie się z książką Erica Evansa — Domain-Driven Design — w której wprowadzono ten termin. Przydatne informacje referencyjne można również znaleźć w książce Implementing Domain-Driven Design autorstwa Vaughna Vernona.
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
Zastosowanie podejścia DDD pomoże Ci zaprojektować mikrousługi, aby każda usługa stanowiła 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 jakiegokolwiek kodu potrzebny jest widok z lotu ptaka na tworzony system. 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 wstępnej analizie domeny zespół firmy Fabrikam wymyślił przybliżony szkic przedstawiający domenę Drone Delivery.
- Wysyłka jest umieszczana na ś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, które są ś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 szacowane czasy odbioru i dostawy.
- Transport innych firm umożliwi aplikacji zaplanowanie alternatywnych metod transportu, jeśli pakiet nie może być dostarczany w całości przez drona.
- Udostępnianie dronów to możliwe rozszerzenie podstawowej działalności. Firma może mieć nadmiar pojemności dronów w określonych godzinach i może wynająć drony, które w przeciwnym razie byłyby bezczynne. Ta funkcja nie będzie dostępna w początkowej wersji.
- Nadzór wideo jest kolejnym obszarem, w który firma może się rozwinąć później.
- Konta użytkowników, fakturowanie i centrum połączeń to poddomeny, które obsługują podstawową działalność.
Zauważ, że na tym etapie 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.
Uwaga
Gdy aplikacja zależy od systemu zewnętrznego, istnieje ryzyko, że schemat danych systemu zewnętrznego lub interfejs API będą wyciekać do aplikacji, ostatecznie zagrażając projektowi architektury. Dotyczy to szczególnie starszych systemów, które mogą nie przestrzegać nowoczesnych najlepszych rozwiązań i mogą używać zawiłych schematów danych lub przestarzałych interfejsów API. W takim przypadku ważne jest, aby mieć dobrze zdefiniowaną granicę między tymi systemami zewnętrznymi a aplikacją. W tym celu rozważ użycie wzorca Fig stranglera lub wzorca warstwy przeciwdegradcyjnej.
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 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 pojawia się 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 wchodzą w interakcje dwa ograniczone konteksty. Na przykład wysyłka zależy od kont użytkowników, aby uzyskać informacje o klientach, a także od 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. Takie podejście odnosi się do dwóch wzorców, które Evans wywołuje usługę Open Host Service i Published Language. Chodzi o 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 formie, za pomocą którego inne zespoły mogą pisać 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 skupimy się na powiązanym kontekście wysyłki.
Następne kroki
Po zakończeniu analizy domeny następnym krokiem jest zastosowanie taktycznego DDD, aby zdefiniować modele domeny z większą dokładnością.