Wprowadzenie

W 2015 roku pisałem o komponentowej architekturze w kontekście dużych aplikacji biznesowych:

Idąc w stro­nę kom­po­nen­tów i dużych zło­żo­nych sys­te­mów  war­to sko­rzy­stać z podej­ścia pole­ga­ją­ce­go na two­rze­niu (kupo­wa­niu) tak zwa­nych mikro­ser­wi­sów, czy­li wąsko spe­cja­li­zo­wa­nych dzie­dzi­no­wych apli­ka­cji (wręcz poje­dyn­czych grup przy­pad­ków uży­cia). Paradoksalnie to bar­dzo uła­twia pro­jek­to­wa­nie, imple­men­ta­cję a przede wszyst­kim obni­ża kosz­ty utrzy­ma­nia całe­go  sys­te­mu. Brak zło­żo­nych połą­czeń mię­dzy kom­po­nen­ta­mi (współ­dzie­lo­na baza danych, zło­żo­ne inter­fej­sy) pozwa­la na to, by cykle ich życia były tak­że nie­za­leż­ne (wpro­wa­dza­ne zmia­ny tak­że). (Granice kontekstu i mikroserwisy )

Dwa lata później w tekście będącym kontynuacją:

Takie podej­ście pozwa­la two­rzyć szyb­ciej przy mini­mal­nym ryzy­ku poja­wie­nia się potrze­by re-fak­to­rin­gu cało­ści a tak­że czy­ni apli­ka­cję łatwą do two­rze­nia w zespo­le i póź­niej­szej roz­bu­do­wy ?(Gage, 2018)?. Rosnąca popu­lar­ność tej archi­tek­tu­ry, tyl­ny­mi drzwia­mi powo­li rugu­je z ryn­ku mono­li­ty ERP, któ­re (nie­któ­re) pod­le­ga­ją re-fak­to­rin­go­wi (ich pro­du­cen­ci  nie chwa­lą sie tym bo to powol­ny i bar­dzo kosz­tow­ny pro­ces). Te sys­te­my, któ­re nadal są opar­te na fun­da­men­cie jed­nej bazy danych  z inte­gra­cją bazu­ją­ca na współ­dzie­le­niu danych,  powo­li prze­gry­wa­ją kosz­ta­mi. (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.

Źródła