Читать книгу Mikroserwisy w akcji - Группа авторов - Страница 39
Część 2
Projekt
4. Projektowanie nowych funkcjonalności
ОглавлениеNiniejszy rozdział dotyczy:
■ określania zakresu mikroserwisów w oparciu na zdolnościach biznesowych i przypadkach użycia;
■ przypadków, w których należy określać zakres mikroserwisów, aby reprezentowały zdolności techniczne;
■ dokonywania wyborów projektowych, gdy granice usług są niejasne;
■ skutecznego określania zakresu, gdy mikroserwisy są w posiadaniu wielu zespołów.
Projektowanie nowej funkcjonalności w aplikacji mikroserwisowej wymaga starannego i dobrze uzasadnionego określenia zakresu mikroserwisów. Musimy zdecydować, czy zbudować nowe, czy rozszerzyć istniejące usługi, gdzie znajdują się granice między tymi usługami, oraz w jaki sposób te usługi powinny współpracować.
Dobrze zaprojektowane usługi mają trzy kluczowe cechy: są odpowiedzialne za jedną zdolność, niezależnie wdrażane i wymienne. Jeśli nasze mikroserwisy mają niewłaściwe granice lub są zbyt małe, mogą stać się ściśle powiązane, co utrudnia ich samodzielne wdrażanie lub zastępowanie. Ścisłe powiązanie zwiększa wzajemny wpływ, a tym samym ryzyko zmiany. Jeśli nasze usługi są zbyt duże – biorąc na siebie zbyt dużą odpowiedzialność – stają się mniej spójne, co zwiększa tarcia w trakcie rozwoju.
Nawet jeśli za pierwszym razem uzyskamy odpowiednią dokładność, musimy pamiętać, że wymagania i potrzeby najbardziej złożonych aplikacji będą ewoluować w miarę upływu czasu, a podejścia, które sprawdzały się na wczesnym etapie życia tej aplikacji, nie zawsze mogą być odpowiednie. Żaden projekt nie jest idealny zawsze.
W dłużej działających aplikacjach (i większych firmach) napotkamy dodatkowe wyzwania. Nasze usługi mogą polegać na sieci zależności zarządzanych przez wiele zespołów – inżynier w danym zespole może musieć zaprojektować spójną funkcjonalność, korzystając z usług, które niekoniecznie będą pod naszą kontrolą. Musimy wiedzieć, kiedy zrezygnować i migrować od usług, które nie spełniają już wymagań systemu w szerszym zakresie.
W tym rozdziale przejdziemy przez proces projektowania nowej funkcjonalności za pomocą mikroserwisów. Wykorzystamy przykład do zbadania technik i praktyk, które można wykorzystać do kierowania projektowaniem łatwych do utrzymania mikroserwisów zarówno w nowych, jak i już działających aplikacjach mikroserwisowych.
4.1. Nowa funkcjonalność w SimpleBanku
Pamiętacie SimpleBank? Zespół wykonuje dobrą robotę – klienci kochają ich produkt! Ale SimpleBank odkrył, że większość ich klientów nie chce wybierać inwestycji – oni woleliby raczej, aby to SimpleBank wykonał za nich tę ciężką pracę. Przyjrzyjmy się problemowi i wymyślmy, jak go rozwiązać za pomocą aplikacji mikroserwisowej. W kolejnych kilku podrozdziałach opracujemy projekt w następujących czterech etapach:
1 Zrozumienie problemu biznesowego, przypadków użycia i potencjalnego rozwiązania.
2 Identyfikacja różnych podmiotów i zdolności biznesowych, które powinny obsługiwać nasze usługi.
3 Określenie zakresu usług, które będą odpowiedzialne za te zdolności.
4 Sprawdzenie poprawności projektu pod kątem obecnych i potencjalnych przyszłych wymagań.
Będziemy się opierać na niewielkim zbiorze usług, o których mówiliśmy w rozdziałach 2 i 3: zleceniach, bramie giełdy, transakcjach na rachunku, opłatach, danych rynkowych i aktywach.
Najpierw spróbujmy zrozumieć problem biznesowy, który będziemy rozwiązywać. W prawdziwym świecie można przeprowadzić odkrywanie i analizę problemów biznesowych za pomocą kilku technik, takich jak badania rynku, wywiady z klientami lub mapowanie wpływu. Poza zrozumieniem problemu musimy zdecydować, czy nasza firma powinna go rozwiązać. Na szczęście nie jest to książka o zarządzaniu produktem – możemy pominąć tę część.
UWAGA Nie próbowaliśmy ekstrapolować ogólnego podejścia do zrozumienia problemów biznesowych – to temat na zupełnie inną książkę.
Reasumując, klienci SimpleBanku chcą zainwestować pieniądze – albo jednorazowo z góry, albo regularnie – i obserwować wzrost swojej zamożności albo w określonym czasie, albo w celu osiągnięcia określonego celu, takiego jak wpłata zaliczki na dom. Obecnie klienci SimpleBanku muszą wybrać sposób inwestowania swoich pieniędzy – nawet jeśli nie mają pojęcia o inwestowaniu. Niedoinformowany inwestor może wybrać składnik aktywów na podstawie wysokich przewidywanych stóp zwrotów, nie zdając sobie sprawy, że wyższe stopy zwrotów oznaczają zwykle znacznie wyższe ryzyko.
Aby rozwiązać ten problem, SimpleBank może podejmować decyzje inwestycyjne w imieniu klienta, umożliwiając mu wybór wstępnie opracowanej strategii inwestycyjnej. Strategia inwestycyjna składa się z proporcji różnych rodzajów aktywów: obligacji, akcji, funduszy itd., zaprojektowanych dla określonego poziomu ryzyka i czasu trwania inwestycji. Gdy klient wpłaci pieniądze na swój rachunek, SimpleBank automatycznie zainwestuje je zgodnie z wybraną strategią. Te założenia zostały podsumowane na rysunku 4.1.
Rysunek 4.1. Potencjalne przypadki użycia w celu wsparcia określania i wyboru strategii inwestycyjnych
Na podstawie rysunku 4.1 możemy zacząć identyfikować przypadki użycia, które muszą być spełniane, aby rozwiązać nasz problem:
■ SimpleBank musi być w stanie tworzyć i aktualizować dostępne strategie;
■ klient musi być w stanie utworzyć rachunek i wybrać odpowiednią strategię inwestycyjną;
■ klient musi mieć możliwość inwestowania pieniędzy za pomocą strategii, a inwestowanie w strategię będzie generować odpowiednie zlecenia.
W następnych kilku podrozdziałach omówimy te przypadki użycia. Podczas identyfikowania przypadków użycia w innej dziedzinie możemy preferować bardziej uporządkowane i wyczerpujące podejścia, takie jak scenariusze behavior-driven development (BDD). Ważne jest, aby zacząć precyzyjne ustalanie rozumienia problemu, którego potem będzie można użyć do walidacji akceptowalnego rozwiązania.
4.2. Określanie zakresu według zdolności biznesowych
Po zidentyfikowaniu wymagań biznesowych następnym krokiem jest określenie technicznego rozwiązania – które funkcjonalności trzeba zbudować i jak je wspierać za pomocą istniejących i nowych mikroserwisów. Wybór odpowiedniego zakresu i celu każdego mikroserwisu jest niezbędny do zbudowania udanej i możliwej do utrzymania aplikacji mikroserwisowej.
Ten proces nazywa się określaniem zakresu usług. Jest również znany jako dekompozycja lub partycjonowanie. Podział aplikacji na usługi jest wyzwaniem – tak samo sztuką, co nauką. W kolejnych podrozdziałach omówimy trzy strategie dotyczące określania zakresu usług:
■ według zdolności biznesowych lub ograniczonych kontekstów – usługi powinny odpowiadać względnie gruboziarnistym, ale spójnym obszarom funkcjonalności biznesowych;
■ według przypadków użycia – usługi powinny być czasownikami, które odzwierciedlają działania mające miejsce w systemie;
■ według zmienności – usługi powinny obejmować obszary, w których w przyszłości mogą wystąpić zmiany.
Nie musimy koniecznie stosować tych podejść w izolacji; w wielu aplikacjach mikroserwisowych będziemy łączyć strategie określania zakresu, aby zaprojektować usługi odpowiednie do różnych scenariuszy i wymagań.
4.2.1. Zdolności i modelowanie domeny
Zdolności biznesowe to coś, co firma robi, aby generować wartości i realizować cele biznesowe. Mikroserwisy, które są ograniczone do zdolności biznesowych, bezpośrednio odzwierciedlają cele biznesowe. W komercyjnym tworzeniu oprogramowania cele te są zwykle główną siłą napędową zmian w systemie; w związku z tym naturalne jest zorganizowanie systemu tak, aby obejmował te obszary zmian. Widzieliśmy już kilka zdolności biznesowych wdrożonych w usługach: zarządzanie zleceniami, księgi transakcji, pobieranie opłat i składanie zleceń na giełdzie (rys. 4.2).
Rysunek 4.2. Funkcjonalności oferowane przez istniejące mikroserwisy i ich związek ze zdolnościami biznesowymi oferowanymi przez SimpleBank
Zdolności biznesowe są ściśle powiązane z podejściem domain-driven design (DDD), które zostało spopularyzowane w książce Erica Evansa i skupia się na budowaniu systemów odzwierciedlających wspólny, zmieniający się widok lub model rzeczywistej domeny11. Jednym z najbardziej użytecznych pojęć, jakie wprowadził Evans, było pojęcie ograniczonych kontekstów (bounded context). Każde rozwiązanie wewnątrz domeny może się składać z wielu ograniczonych kontekstów; modele wewnątrz każdego kontekstu są bardzo spójne i mają ten sam widok rzeczywistego świata. Każdy kontekst ma silną i wyraźną granicę między nim a innymi kontekstami.
Ograniczone konteksty to spójne jednostki o jasnym zakresie i wyraźnej zewnętrznej granicy. To sprawia, że są naturalnym punktem startowym do określania zakresu usług. Każdy kontekst wyznacza granice między różnymi obszarami rozwiązania. Często ma to bliski związek z granicami organizacyjnymi; na przykład firma zajmująca się handlem elektronicznym będzie miała różne potrzeby – i różne zespoły – do obsługi sprzedaży wysyłkowej w porównaniu do obsługi płatności klientów.
Na początku kontekst jest zazwyczaj mapowany bezpośrednio do usługi i obszaru zdolności biznesowych. W miarę jak całość się rozwija i staje się bardziej złożona, kontekst możemy podzielić na mniejsze zbiory zdolności, z których wiele będzie mogło być wdrożonych jako niezależne, współpracujące usługi. Z perspektywy klienta kontekst może jednak nadal wyglądać jak pojedyncza, logiczna usługa.
11
Chociaż wiele wzorców implementacji – repozytoria, agregaty i fabryki – jest dość specyficzna dla programowania obiektowego, wiele technik analizy Evansa, takich jak język wszechobecny, jest użytecznych w każdym paradygmacie programowania.
