Używanie taktycznych DDD do projektowania mikrousług
Projekt oparty na domenie (DDD) sprzeciwia się idei posiadania jednego ujednoliconego modelu dla całego systemu. Zamiast tego zachęca system do dzielenia systemu na ograniczone konteksty, z których każdy ma własny model. Podczas strategicznej fazy DDD należy zamapować domenę biznesową i zdefiniować powiązane konteksty dla modeli domeny.
W fazie taktycznej projektowania DDD dokładniej definiuje się modele domeny. Wzorce taktyczne są stosowane w ramach jednego ograniczonego kontekstu. W architekturze mikrousług, gdzie każdy ograniczony kontekst jest kandydatem mikrousługi, jednostki i wzorce agregacji są uwaga. Zastosowanie tych wzorców pomaga zidentyfikować naturalne granice dla usług w aplikacji. Aby uzyskać więcej informacji, zobacz Identyfikowanie granic mikrousług. Ogólnie rzecz biorąc, mikrousługi nie powinny być mniejsze niż agregacja i nie większe niż ograniczony kontekst.
W tym artykule przedstawiono wzorce taktyczne, a następnie stosuje je do kontekstu ograniczonego wysyłki w aplikacji Drone Delivery.
Omówienie wzorców taktycznych
Ta sekcja zawiera krótkie podsumowanie taktycznych wzorców DDD. Jeśli znasz DDD, możesz go pominąć. Te wzorce opisano bardziej szczegółowo w rozdziałach 5 i 6 książki Eric Evans oraz w implementowaniu Domain-Driven Design przez Vaughn Vernon.
Jednostki. jednostka jest obiektem o unikatowej, trwałej tożsamości. Na przykład w aplikacji bankowej jednostkami są klienci i konta.
Jednostka ma unikatowy identyfikator w systemie, który może służyć do wyszukiwania lub pobierania jednostki. Nie oznacza to, że identyfikator jest zawsze udostępniany bezpośrednio użytkownikom. Może to być identyfikator GUID lub klucz podstawowy w bazie danych.
Tożsamość może obejmować wiele powiązanych kontekstów i może utrzymywać się poza okresem istnienia aplikacji. Na przykład numery kont bankowych lub identyfikatory wystawione przez instytucje rządowe nie są powiązane z określoną aplikacją.
Atrybuty jednostki mogą ulec zmianie w czasie. Na przykład nazwisko lub adres osoby może ulec zmianie, ale pozostają one tą samą osobą.
Obiekty wartości. Obiekt wartości nie ma tożsamości. Jest on definiowany tylko przez wartości jego atrybutów. Obiekty wartości są niezmienne. Aby zaktualizować obiekt wartości, zostanie utworzone nowe wystąpienie w celu zastąpienia starego. Obiekty wartości mogą zawierać metody hermetyzujące logikę domeny, ale te metody nie mogą powodować skutków ubocznych ani modyfikować stanu obiektu. Typowe przykłady obiektów wartości obejmują kolory, daty i godziny oraz wartości waluty.
Agregacje. agregacja definiuje granicę spójności obejmującą co najmniej jedną jednostkę. Dokładnie jedna jednostka w agregacji jest katalogiem głównym. Wyszukiwanie odbywa się przy użyciu identyfikatora jednostki głównej. Wszystkie inne jednostki w agregacji są elementami podrzędnym katalogu głównego i są przywoływana przez następujące wskaźniki z katalogu głównego.
Funkcja agregacji polega na modelowaniu niezmiennych atrybutów transakcyjnych. Elementy w świecie rzeczywistym mają relacje tworzące złożone sieci. Klienci tworzą zamówienia, zamówienia zawierają produkty, produkty mają dostawców itd. Jak zagwarantować spójność, jeśli aplikacja zmodyfikuje kilka powiązanych obiektów? Jak śledzić niezmienne atrybuty i je wymuszać?
Tradycyjne aplikacje często używały transakcji bazy danych w celu wymuszania spójności. Jednak w aplikacji rozproszonej często nie jest to możliwe. Pojedyncza transakcja biznesowa może obejmować wiele magazynów danych lub może być długotrwała lub może obejmować usługi innych firm. Ostatecznie jest to aplikacja, a nie warstwa danych, aby wymusić niezmienności wymagane dla domeny. To właśnie są agregacje przeznaczone do modelowania.
Uwaga
Agregacja może składać się z jednej jednostki bez jednostek podrzędnych. Co sprawia, że jest to agregacja, to granica transakcyjna.
Usługi domenowe i aplikacji. w terminologii DDD usługa jest obiektem, który implementuje pewną logikę bez przechowywania żadnego stanu. Evans rozróżnia usługi domenowe, które hermetyzują logikę domeny i usługi aplikacji, które zapewniają funkcje techniczne, takie jak uwierzytelnianie użytkowników lub wysyłanie wiadomości SMS. Usługi domenowe są często używane do modelowania zachowań obejmujących wiele jednostek.
Uwaga
Termin usługa jest przeciążona w tworzeniu oprogramowania. Definicja używana w tym miejscu nie jest bezpośrednio powiązana z mikrousługami.
Zdarzenia domeny. Zdarzenia domeny mogą powiadamiać inne części systemu w przypadku wystąpienia czegoś. Jak sugeruje nazwa, zdarzenia domeny powinny reprezentować coś istotnego w domenie. Na przykład "rekord został wstawiony do tabeli" nie jest zdarzeniem domeny. "Anulowanie dostawy" to zdarzenie domeny. Zdarzenia domeny są szczególnie ważne w architekturze mikrousług. Ponieważ mikrousługi są rozproszone i nie udostępniają magazynów danych, zdarzenia domeny umożliwiają koordynację między usługami. Aby uzyskać więcej informacji na temat asynchronicznej obsługi komunikatów, zobacz Komunikacja międzyusługowa.
Istnieje kilka innych wzorców DDD, które nie zostały tutaj omówione, w tym fabryk, repozytoriów i modułów. Te wzorce mogą być przydatne podczas implementowania mikrousługi, ale są one mniej istotne podczas projektowania granic między mikrousługami.
Dostarczanie dronów: stosowanie wzorców
Zaczynamy od scenariuszy, które musi obsługiwać ograniczony kontekst Wysyłka.
- Klient może poprosić drona o odebranie towarów z firmy zarejestrowanej w usłudze dostarczania dronów.
- Nadawca generuje tag (kod kreskowy lub RFID), który ma być umieszczany w pakiecie.
- Dron będzie pobierać i dostarczać pakiet z lokalizacji źródłowej do lokalizacji docelowej.
- Gdy klient planuje dostawę, system udostępnia ETA na podstawie informacji o trasach, warunków pogodowych i danych historycznych.
- Gdy dron jest w locie, użytkownik może śledzić bieżącą lokalizację i najnowszą wartość ETA.
- Do momentu odebrania pakietu przez drona klient może anulować dostawę.
- Klient jest powiadamiany o zakończeniu dostawy.
- Nadawca może zażądać potwierdzenia dostarczenia od klienta w postaci podpisu lub odcisku palca.
- Użytkownicy mogą wyszukać historię ukończonego dostarczania.
W tych scenariuszach zespół deweloperów zidentyfikował następujące jednostki.
- Dostawa
- Pakiet
- Dron
- Klient
- Potwierdzenie
- Powiadomienie
- Etykieta
Pierwsze cztery, dostarczanie, pakiet, dron i konto, są agregacjami reprezentującymi granice spójności transakcyjnej. Potwierdzenia i powiadomienia są jednostkami podrzędnymi dostaw, a tagi są jednostkami podrzędnymi paczek.
Obiekty wartości w tym projekcie obejmują Lokalizację, ETA, PackageWeight i PackageSize.
Aby zilustrować, poniżej przedstawiono diagram UML agregacji dostarczania. Zwróć uwagę, że zawiera odwołania do innych agregacji, w tym konta, pakietu i drona.
Są dwa zdarzenia domeny:
Podczas lotu jednostka drona wysyła zdarzenia DroneStatus (Stan drona), które opisują lokalizację i stan drona (przelot, wylądował).
Jednostka dostawy wysyła zdarzenia DeliveryTracking (Śledzenie dostawy) po każdej zmianie etapu dostawy. Zdarzenia DeliveryTracking obejmują DeliveryCreated, DeliveryRescheduled, DeliveryHeadedToDropoff i DeliveryCompleted.
Należy zwrócić uwagę, że zdarzenia te opisują rzeczy, które są istotne w ramach modelu domeny. Opisują one elementy domeny i nie są powiązane z konkretnymi konstrukcjami języka programowania.
Ponadto zespół deweloperów określił obszar funkcjonalności, który nie pasuje do żadnej z opisanych jednostek. Jakaś część systemu musi koordynować wszystkie działania związane z planowaniem lub aktualizacją dostawy. W związku z tym zespół programistyczny dodał do projektu dwie usługi domenowe : harmonogram , który koordynuje kroki, oraz nadzorcę , który monitoruje stan każdego kroku, aby wykryć, czy wszystkie kroki zakończyły się niepowodzeniem, czy upłynął limit czasu. Takie podejście jest odmianą wzorca nadzorcy agenta harmonogramu.
Następne kroki
Następnym krokiem jest zdefiniowanie granic dla każdej mikrousługi.