Mikroserwisy w akcji. Отсутствует
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.
Конец ознакомительного фрагмента.
Текст предоставлен ООО «ЛитРес».
Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с
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.