Wprowadzenie
W 2015 roku pisałem o komponentowej architekturze w kontekście dużych aplikacji biznesowych:
Idąc w stronę komponentów i dużych złożonych systemów warto skorzystać z podejścia polegającego na tworzeniu (kupowaniu) tak zwanych mikroserwisów, czyli wąsko specjalizowanych dziedzinowych aplikacji (wręcz pojedynczych grup przypadków użycia). Paradoksalnie to bardzo ułatwia projektowanie, implementację a przede wszystkim obniża koszty utrzymania całego systemu. Brak złożonych połączeń między komponentami (współdzielona baza danych, złożone interfejsy) pozwala na to, by cykle ich życia były także niezależne (wprowadzane zmiany także). (Granice kontekstu i mikroserwisy )
Dwa lata później w tekście będącym kontynuacją:
Takie podejście pozwala tworzyć szybciej przy minimalnym ryzyku pojawienia się potrzeby re-faktoringu całości a także czyni aplikację łatwą do tworzenia w zespole i późniejszej rozbudowy ?(Gage, 2018)?. Rosnąca popularność tej architektury, tylnymi drzwiami powoli ruguje z rynku monolity ERP, które (niektóre) podlegają re-faktoringowi (ich producenci nie chwalą sie tym bo to powolny i bardzo kosztowny proces). Te systemy, które nadal są oparte na fundamencie jednej bazy danych z integracją bazująca na współdzieleniu danych, powoli przegrywają kosztami. (Mikroserwisy c.d.?)
Dzisiaj opiszę jak na etapie analizy i projektowania opracować model PIM (Platform Independent Model) , w taki sposób by stanowił projekt techniczny aplikacji webowej dla developera.
Aplikacja webowa czyli co?
Pod tą nazwą kryje się architektura fizycznie oparta na serwerze z właściwą aplikacją i prostym (cienkim) klientem uruchamianym w przeglądarce internetowej.
Od strony logiki działania jest to po prostu wielodostępna aplikacja na serwerze. To jak fizycznie rozlokujemy komponenty tej aplikacji, jest już zadaniem z obszaru optymalizacji.
W najprostszy sposób można to przedstawić jak poniżej:
Ta architektura pokazuje dwuczęściowe środowisko aplikacji webowych: środowisko aplikacji centralnej (serwer aplikacyjny), oraz środowisko odpowiedzialne za interakcję z użytkownikiem czyli przeglądarka internetowa. Jednak przeglądarka internetowa to także złożone środowisko:
Projektując aplikacje internetowe warto, na etapie projektowania mechanizmu działania logiki, idealizować projekt do modeli PIM.
Ważne jest to, że Strona WWW i Aplikacja, to tak na prawdę jeden system . Z perspektywy developera może to wyglądać np. tak:
Celowo przytaczam tu powyższy model, gdyż pokazuje on także komponenty „techniczne”. Z perspektywy wzorca MVC (Model, View, Controller) na powyższym diagramie View to „Prezentation”, Model to praktycznie tylko „Business”, cała reszta to Controller. Biorąc pod uwagę fakt, że poza komponentem Business, wszystkie pozostałe to wykorzystywany framework (biblioteki), developer ma dwa podstawowe zadania: zestawić środowisko i zabezpieczyć realizację wymagań pozafunkcjonalnych (w szczególności wydajność i bezpieczeństwo) oraz wykonać implementację dostarczonego mu projektu komponentu Business wyrażonego jako PIM (Model wg. MVC).
Od tego momentu zajmę sie wyłącznie komponentem PIM (czyli tak na prawdę Model Dziedziny Systemu).
Mikroserwisy
Jak już wspominałem na początku, mikro-serwisy to wzorzec architektoniczny zakładający realizację usług aplikacyjnych w postaci odrębnej (hermetyzowanej) implementacji każdej z nich. Poniżej często spotykane w sieci porównanie architektury monolitycznej z mikro-serwisami:
Bardzo ważne jest to, że żadna z tych wersji nie koliduje z przedstawionym na początku modelem aplikacji webowej. Innymi słowy: aplikacja webowa także może być ciężkim monolitem (i nie raz tak własnie jest). Bardzo ważne jest to, że aplikacje klasyfikowane jako SOA (Service Oriented Architecture, architektura zorientowana na usługi) to także bardzo często monolity, na co autor wyżej cytowanego artykułu wraca uwagę prezentując to tak:
Jeden z frameworków Java tak definiuje mikro serwisy:
Generalnie kluczową cechą micro-serwisów, czyniącą z nich tak zwaną zwinną architekturę, jest całkowita niezależność implementacji poszczególnych usług aplikacyjnych.
Rozwój wzorców architektonicznych jest często przyrównywany do darwinowskiej ewolucji gdyż, gorsze wzorce są wypierane przez lepsze a mikro-serwisy wydają się jednak znacznie lepszą architekturą, w czasach szybkiej zmienności wymagań i otoczenia biznesowego, niż monolity .
Podsumowanie
O obiektowym projektowaniu i stosowaniu przypadków użycia napisałem tu już wiele, dlatego na zakończenie pokaże kolejne etapy analizy i projektowania obiektowego z użyciem UML bez dokładnego omawiania.
Pokazano schematycznie mechanizm projektowania i funkcjonowania aplikacji internetowych i jedną z możliwych architektur jaką są mikro-serwisy. Uzupełnienie tego projektu o (opisywane nie raz na tym blogu): struktury formularzy, słownik etykiet pól, reguły ich walidacji, brakujące diagramy sekwencji, ewentualne algorytmy, być może struktury wewnętrzne (wewnętrzna architektura) mikro-serwisów, da w efekcie Projekt Techniczny Oprogramowania. .
Uwaga na zakończenie: wycena aplikacji metodą punktów funkcyjnych (lub COSMIC) nie jest tu możliwa, gdyż metody te opierają sie na monolitycznych architekturach opisywanych przypadkami użycia. Do wyceny wymagany jest projekt architektury jak wyżej. W przeciwnym wypadku pozostają metody T&M wraz z całym ich ryzykiem.
Wynaturzenia
Niestety development bez biznesowego zrozumienia specyfiki architektury modelu dziedziny systemu prowadzi do wynaturzeń. Uznanie, że mikroserwisy to samodzielne i niezależne implementacje operacji, prowadzi do zwykłego śmietnika. Mikroserwis to coś co opisano na początku tego pomysłu: to samodzielne mikroapliakcje, to co zaczęło powstawać pod nazwą mikroserwis niemile zaskakuj samych programistów (patrz ponizszy artykuł o NetFlix).
Dlatego chyba dla odróżnienia od powyższego bałaganu powstało pojęcie mikroaplikacji (MicroApp). Jest definiowane bardziej precyzyjnie. Na jednym z wielu blogów na ten temat czytamy:
W zasadzie wszystkie opisane na moim blogu „mikroserwisy” to właśnie mikroapliakcje.