Читать книгу Mikroserwisy w akcji - Группа авторов - Страница 24

Aby zidentyfikować oczekiwane zdolności biznesowe, musimy lepiej zrozumieć domenę, w której budujemy oprogramowanie. Zwykle jest to ciężka praca związana z tworzeniem produktu lub analizą biznesową: badania, prototypowanie oraz rozmowy z klientami, kolegami lub innymi użytkownikami końcowymi.

Zacznijmy od przeanalizowania przykładu składania zlecenia z rysunku 2.3. Jaką wartość chcemy dostarczyć? Patrząc ogólnie – klient chce móc składać zlecenia. Tak więc oczywistą zdolnością biznesową będzie możliwość przechowywania i zarządzania stanem tych zleceń. To jest nasz pierwszy kandydat na mikroserwis.

Kontynuując naszą eksplorację przykładu, możemy zidentyfikować inne funkcjonalności, które będzie musiała zaoferować aplikacja. Aby coś sprzedać, będziemy musieli to posiadać, a więc potrzebujemy sposobu reprezentowania bieżących zasobów klienta wynikających z transakcji, które nastąpiły na jego rachunku. Nasz system musi wysłać zamówienie do brokera – aplikacja musi mieć możliwość interakcji z tym podmiotem zewnętrznym. W rzeczywistości ta jedna funkcjonalność składania zlecenia sprzedaży będzie wymagać od aplikacji SimpleBank obsługi wszystkich następujących funkcjonalności:

■ rejestrowanie statusów i historii zleceń sprzedaży,

■ pobieranie opłat od klienta za złożenie zlecenia,

■ rejestrowanie transakcji na rachunku klienta,

■ składanie zlecenia na giełdzie,

■ wykonywanie wyceny udziałów i zleceń klienta

Nie oznacza to, że każda funkcjonalność będzie związana z jednym mikroserwisem. Musimy określić, które funkcjonalności są spójne – będą one ze sobą połączone. Na przykład transakcje wynikające ze zleceń będą podobne do transakcji wynikających z innych zdarzeń, takich jak dywidendy wypłacane z tytułu akcji. Łącznie grupa funkcjonalności będzie tworzyć zdolność, którą będzie mogła zaoferować jedna usługa.

Zmapujmy te funkcjonalności na zdolności biznesowe, czyli na to, czym zajmuje się firma. Możemy zobaczyć to odwzorowanie na rysunku 2.4. Niektóre funkcjonalności krzyżują się z wieloma domenami, na przykład z opłatami.

Rysunek 2.4. Związki między funkcjonalnościami aplikacji a zdolnościami w ramach działalności SimpleBanku

Można zacząć od mapowania tych zdolności bezpośrednio do mikroserwisów. Każda usługa powinna odzwierciedlać możliwości oferowane przez firmę, co przekłada się na równowagę między rozmiarem a odpowiedzialnością. Powinniśmy także rozważyć, co będzie powodować zmiany w mikroserwisie w przyszłości – bez względu na to, czy rzeczywiście ma on jedną odpowiedzialność. Możemy na przykład przyjąć, że transakcja na giełdzie jest podzbiorem zarządzania zleceniami, a zatem nie powinna być oddzielną usługą. Jednak czynniki wpływające na zmiany w tym obszarze to zachowanie i zakres obsługiwanych rynków, a zarządzanie zleceniami bardziej wiąże się z rodzajami produktów i kontami wykorzystywanymi do handlu. Te dwa obszary nie podlegają zmianom razem. Rozdzielając je, izolujemy obszary zmienności i maksymalizujemy spójność (rys. 2.5).

Rysunek 2.5. Usługi powinny izolować przyczyny zmian, aby promować luźne powiązania i indywidualną odpowiedzialność

Niektórzy praktykujący twórcy mikroserwisów twierdzą, że powinny one bardziej odzwierciedlać pojedyncze funkcjonalności niż pojedyncze zdolności. Niektórzy sugerują nawet, że mikroserwisy są „tylko do dołączania” i że zawsze lepiej jest pisać nowe usługi niż dodawać coś do już istniejących.

Nie zgadzamy się z tym. Zbytnia dekompozycja może prowadzić do usług, które nie mają spójności i ścisłych relacji między blisko powiązanymi elementami. Ponadto, wdrażanie i monitorowanie wielu usług może być poza możliwościami zespołu inżynierskiego we wczesnym etapie ich wdrażania. Przydatną regułą jest poruszanie się pośród większych usług; często łatwiej jest wyodrębnić funkcjonalność później, gdy stanie się bardziej wyspecjalizowana lub wyraźniej będzie należeć do niezależnej usługi.

Pamiętajmy też, że zrozumienie domeny nie jest jednorazowym procesem! Z czasem będziemy kontynuować iteracje nad zrozumieniem domeny; potrzeby użytkowników ulegną zmianie, a nasz produkt nadal będzie ewoluował. Gdy to zrozumienie się zmieni, zmieni się nasz system, aby sprostać tym potrzebom. Na szczęście, jak omówiliśmy w rozdziale 1, radzenie sobie ze zmieniającymi się potrzebami i wymaganiami stanowi siłę podejścia mikroserwisowego.