Wprowadzenie

W 2015 roku pisa­łem o kom­po­nen­to­wej archi­tek­tu­rze w kon­tek­ście dużych apli­ka­cji 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 kon­tek­stu i mikro­ser­wi­sy )

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­­ri­n­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­­ri­n­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 opi­szę jak na eta­pie ana­li­zy i pro­jek­to­wa­nia opra­co­wać model PIM (Platform Independent Model) , w taki spo­sób by sta­no­wił pro­jekt tech­nicz­ny apli­ka­cji webo­wej dla developera.

Aplikacja webowa czyli co?

Pod tą nazwą kry­je się archi­tek­tu­ra fizycz­nie opar­ta na ser­we­rze z wła­ści­wą apli­ka­cją i pro­stym (cien­kim) klien­tem uru­cha­mia­nym w prze­glą­dar­ce internetowej. 

Od stro­ny logi­ki dzia­ła­nia jest to po pro­stu wie­lo­do­stęp­na apli­ka­cja na ser­we­rze. To jak fizycz­nie roz­lo­ku­je­my kom­po­nen­ty tej apli­ka­cji, jest już zada­niem z obsza­ru optymalizacji. 

W naj­prost­szy spo­sób moż­na to przed­sta­wić jak poniżej:

Ta archi­tek­tu­ra poka­zu­je dwu­czę­ścio­we śro­do­wi­sko apli­ka­cji webo­wych: śro­do­wi­sko apli­ka­cji cen­tral­nej (ser­wer apli­ka­cyj­ny), oraz śro­do­wi­sko odpo­wie­dzial­ne za inte­rak­cję z użyt­kow­ni­kiem czy­li prze­glą­dar­ka inter­ne­to­wa. Jednak prze­glą­dar­ka inter­ne­to­wa to tak­że zło­żo­ne środowisko:

Projektując apli­ka­cje inter­ne­to­we war­to, na eta­pie pro­jek­to­wa­nia mecha­ni­zmu dzia­ła­nia logi­ki, ide­ali­zo­wać pro­jekt do mode­li PIM. 

Ważne jest to, że Strona WWW i Aplikacja, to tak na praw­dę jeden sys­tem . Z per­spek­ty­wy deve­lo­pe­ra może to wyglą­dać np. tak:

Celowo przy­ta­czam tu powyż­szy model, gdyż poka­zu­je on tak­że kom­po­nen­ty ​„tech­nicz­ne”. Z per­spek­ty­wy wzor­ca MVC (Model, View, Controller) na powyż­szym dia­gra­mie View to ​„Prezentation”, Model to prak­tycz­nie tyl­ko ​„Business”, cała resz­ta to Controller. Biorąc pod uwa­gę fakt, że poza kom­po­nen­tem Business, wszyst­kie pozo­sta­łe to wyko­rzy­sty­wa­ny fra­me­work (biblio­te­ki), deve­lo­per ma dwa pod­sta­wo­we zada­nia: zesta­wić śro­do­wi­sko i zabez­pie­czyć reali­za­cję wyma­gań poza­funk­cjo­nal­nych (w szcze­gól­no­ści wydaj­ność i bez­pie­czeń­stwo) oraz wyko­nać imple­men­ta­cję dostar­czo­ne­go mu pro­jek­tu kom­po­nen­tu Business wyra­żo­ne­go jako PIM (Model wg. MVC).

Od tego momen­tu zaj­mę sie wyłącz­nie kom­po­nen­tem PIM (czy­li tak na praw­dę Model Dziedziny Systemu).

Mikroserwisy

Jak już wspo­mi­na­łem na począt­ku, mikro-ser­wi­sy to wzo­rzec archi­tek­to­nicz­ny zakła­da­ją­cy reali­za­cję usług apli­ka­cyj­nych w posta­ci odręb­nej (her­me­ty­zo­wa­nej) imple­men­ta­cji każ­dej z nich. Poniżej czę­sto spo­ty­ka­ne w sie­ci porów­na­nie archi­tek­tu­ry mono­li­tycz­nej z mikro-serwisami:

Bardzo waż­ne jest to, że żad­na z tych wer­sji nie koli­du­je z przed­sta­wio­nym na począt­ku mode­lem apli­ka­cji webo­wej. Innymi sło­wy: apli­ka­cja webo­wa tak­że może być cięż­kim mono­li­tem (i nie raz tak wła­snie jest). Bardzo waż­ne jest to, że apli­ka­cje kla­sy­fi­ko­wa­ne jako SOA (Service Oriented Architecture, archi­tek­tu­ra zorien­to­wa­na na usłu­gi) to tak­że bar­dzo czę­sto mono­li­ty, na co autor wyżej cyto­wa­ne­go arty­ku­łu wra­ca uwa­gę pre­zen­tu­jąc to tak:

Generalnie klu­czo­wą cechą micro-ser­wi­sów, czy­nią­cą z nich tak zwa­ną zwin­ną archi­tek­tu­rę, jest cał­ko­wi­ta nie­za­leż­ność imple­men­ta­cji poszcze­gól­nych usług aplikacyjnych. 

Rozwój wzor­ców archi­tek­to­nicz­nych jest czę­sto przy­rów­ny­wa­ny do dar­wi­now­skiej ewo­lu­cji gdyż, gor­sze wzor­ce są wypie­ra­ne przez lep­sze a mikro-ser­wi­sy wyda­ją się jed­nak znacz­nie lep­szą archi­tek­tu­rą, w cza­sach szyb­kiej zmien­no­ści wyma­gań i oto­cze­nia biz­ne­so­we­go, niż mono­li­ty .

Podsumowanie

O obiek­to­wym pro­jek­to­wa­niu i sto­so­wa­niu przy­pad­ków uży­cia napi­sa­łem tu już wie­le, dla­te­go na zakoń­cze­nie poka­że kolej­ne eta­py ana­li­zy i pro­jek­to­wa­nia obiek­to­we­go z uży­ciem UML bez dokład­ne­go omawiania.

Pokazano sche­ma­tycz­nie mecha­nizm pro­jek­to­wa­nia i funk­cjo­no­wa­nia apli­ka­cji inter­ne­to­wych i jed­ną z moż­li­wych archi­tek­tur jaką są mikro-ser­wi­sy. Uzupełnienie tego pro­jek­tu o (opi­sy­wa­ne nie raz na tym blo­gu): struk­tu­ry for­mu­la­rzy, słow­nik ety­kiet pól, regu­ły ich wali­da­cji, bra­ku­ją­ce dia­gra­my sekwen­cji, ewen­tu­al­ne algo­ryt­my, być może struk­tu­ry wewnętrz­ne (wewnętrz­na archi­tek­tu­ra) mikro-ser­wi­sów, da w efek­cie Projekt Techniczny Oprogramowania. .

Uwaga na zakoń­cze­nie: wyce­na apli­ka­cji meto­dą punk­tów funk­cyj­nych (lub COSMIC) nie jest tu moż­li­wa, gdyż meto­dy te opie­ra­ją sie na mono­li­tycz­nych archi­tek­tu­rach opi­sy­wa­nych przy­pad­ka­mi uży­cia. Do wyce­ny wyma­ga­ny jest pro­jekt archi­tek­tu­ry jak wyżej. W prze­ciw­nym wypad­ku pozo­sta­ją meto­dy T&M wraz z całym ich ryzykiem. 

Wynaturzenia

Niestety deve­lop­ment bez biz­ne­so­we­go zro­zu­mie­nia spe­cy­fi­ki archi­tek­tu­ry mode­lu dzie­dzi­ny sys­te­mu pro­wa­dzi do wyna­tu­rzeń. Uznanie, że mikro­ser­wi­sy to samo­dziel­ne i nie­za­leż­ne imple­men­ta­cje ope­ra­cji, pro­wa­dzi do zwy­kłe­go śmiet­ni­ka. Mikroserwis to coś co opi­sa­no na począt­ku tego pomy­słu: to samo­dziel­ne mikro­apliak­cje, to co zaczę­ło powsta­wać pod nazwą mikro­ser­wis nie­mi­le zaska­kuj samych pro­gra­mi­stów (patrz poniz­szy arty­kuł o NetFlix).

Dlatego chy­ba dla odróż­nie­nia od powyż­sze­go bała­ga­nu powsta­ło poję­cie mikro­apli­ka­cji (MicroApp). Jest defi­nio­wa­ne bar­dziej pre­cy­zyj­nie. Na jed­nym z wie­lu blo­gów na ten temat czytamy: 

W zasa­dzie wszyst­kie opi­sa­ne na moim blo­gu ​„mikro­ser­wi­sy” to wła­śnie mikroapliakcje. 

Źródła