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) [zotpressInText item=”{5085975:84CYAT4F},{5085975:TBT7B5D2}”], w taki sposób by stanowił projekt techniczny aplikacji webowej dla developera.