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

Członkowie zespołu SimpleBanku chcą zaoferować inteligentne inwestycje finansowe każdemu, bez względu na to, ile ma pieniędzy. Uważają, że kupowanie akcji, sprzedaż funduszy lub handel walutami powinny być tak proste, jak otwarcie konta oszczędnościowego.

To ważna misja, ale niełatwa. Produkty finansowe mają wiele wymiarów złożoności – SimpleBank będzie musiał zrozumieć zasady rynkowe i skomplikowane przepisy, a także zintegrować się z istniejącymi systemami branżowymi, jednocześnie spełniając rygorystyczne wymagania dotyczące jakości.

W poprzednim rozdziale określiliśmy niektóre funkcjonalności oferowane przez SimpleBank klientom: otwieranie rachunków, zarządzanie płatnościami, składanie zleceń i modelowanie ryzyka. Rozwińmy te możliwości i zobaczmy, jak mogą one pasować do szerszego zakresu narzędzia inwestycyjnego. Na rysunku 2.1 ilustrowano różne elementy tego zakresu.

Rysunek 2.1. Ogólny (i w żadnym razie niewyczerpujący) model funkcjonalności, który mógłby zbudować SimpleBank

Jak widać na rysunku, narzędzie inwestycyjne będzie musiało robić więcej, niż tylko oferować funkcjonalności związane z klientem, takie jak możliwość otwierania rachunków i zarządzania portfelem finansowym. Będzie musiało również zarządzać zasobami, czyli tym, w jaki sposób bank utrzymuje aktywa w imieniu klientów i przenosi w ich lub poza ich posiadanie oraz tworzeniem produktów finansowych odpowiednich do potrzeb klientów.

Jak widać, nie jest to takie proste! Możemy zacząć dostrzegać niektóre zdolności biznesowe, które mogą zostać wdrożone przez SimpleBank: zarządzanie portfelem, integracja danych rynkowych, zarządzanie zleceniami, tworzenie funduszy i analiza portfela. Każdy ze wskazanych obszarów biznesowych może się składać z dowolnej liczby usług współpracujących ze sobą lub z usługami w innych obszarach.

Tego typu ogólny model zakresu jest przydatnym pierwszym krokiem przy tworzeniu koncepcji dowolnego systemu, natomiast kluczowe znaczenie ma przy budowaniu mikroserwisów. Bez zrozumienia tego zakresu można podejmować błędne decyzje dotyczące granic usług. Nie chcemy budować usług anemicznych – istniejących tylko w celu wykonywania prostych operacji tworzenia, odczytu, aktualizacji i usuwania (CRUD). Często stają się one źródłem silnego sprzężenia w aplikacji. Jednocześnie chcemy uniknąć umieszczania nadmiernej odpowiedzialności w ramach jednej usługi. Mniej spójne usługi powodują, że zmiany w oprogramowaniu są wolniejsze i bardziej ryzykowne – dokładnie to, czego próbujemy uniknąć.

Wreszcie, bez tego spojrzenia możemy paść ofiarą na wyrost zaprojektowanego narzędzia – wyboru mikroserwisów tam, gdzie nie jest to uzasadnione przez rzeczywistą złożoność produktu lub zastosowania.