Nie raz już pisa­łem tu o archi­tek­tu­rze (Architektura sys­te­mu) tym razem kil­ka słów o tym. Często jestem pyta­ny o kry­te­rium podzia­łu duże­go sys­te­mu na kom­po­nen­ty. Jednym z nich jest prak­ty­ka dąże­nia do mini­ma­li­za­cji zło­żo­no­ści inter­fej­sów mię­dzy kom­po­nen­ta­mi jako kon­se­kwen­cja dzie­dzi­no­we­go kry­te­rium podzia­łu . Złą prak­ty­ką jest nato­miast dąże­nie do usu­wa­nia redundancji.

Stosuje takie – kom­po­nen­to­we dzie­dzi­no­we – podej­ście, w róż­nej for­mie, z powo­dze­niem od lat. Można je spo­tkać w róż­nych for­mach w lite­ra­tu­rze, pierw­szy raz spo­tka­łem się z nim w 1999 roku.

Obecnie mamy już dość dobrze wypra­co­wa­ne wzor­ce pro­jek­to­we ale nadal jest pro­blem ze zro­zu­mie­niem kie­dy i jak”. Ładnie to opi­sał swe­go cza­su [[E.Evans przy oka­zji wzor­ca DDD]], Tu poprze­sta­nę jedy­nie na poję­ciu [[boun­ded con­text]] czy­li gra­ni­ca kon­tek­stu”. Granica ta ma podwój­ne zna­cze­nie: kon­tekst nada­je (zmie­nia) zna­cze­nia w mode­lu poję­cio­wym (bał­wan w kon­tek­ście zimy to co inne­go niż bał­wan w kon­tek­ście człon­ków zespo­łu pro­jek­to­we­go) oraz kon­tekst (bar­dzo czę­sto) wyzna­cza zakres pro­jek­tu (inne aspek­ty wzor­ca DDD tu pomi­nę). Pierwsza uwa­ga: kon­tekst dzie­dzi­no­wy (poję­cio­wy) jest waż­niej­szy (powi­nien być nad­rzęd­ny) wobec zakre­su pro­jek­tu, ten dru­gi jest usta­la­ny, dru­gi wyni­ka z sys­te­mu poję­cio­we­go (bał­wan z oka­zji zimy będzie trwal­szym poję­ciem w pro­jek­cie niż bał­wan z oka­zji człon­ków doraź­ne­go spo­tka­nia zespołu).

Ładnie opi­sał to M.Fowler:

Bounded Context is a cen­tral pat­tern in Domain-Driven Design. It is the focus of DDD’s stra­te­gic design sec­tion which is all abo­ut dealing with lar­ge models and teams. DDD deals with lar­ge models by divi­ding them into dif­fe­rent Bounded Contexts and being expli­cit abo­ut the­ir interrelationships.

MFowler_BoudedContext

(M.Fowler BoundedContext).

Jak widać mamy dwa kon­tek­sty i redun­dan­cje (poję­cia Customer i Produkt po obu stro­nach). Powyższe powin­no być pod­sta­wą do podzia­łu pro­jek­tu na dwa kom­po­nen­ty (dwie apli­ka­cje każ­da ma swo­je kla­sy Customer i Produkt i nie współ­dzie­lą ich w bazie danych) i powin­no odwieść od pomy­słu two­rze­nia jed­nej znor­ma­li­zo­wa­nej bazy danych dla cało­ści. Powód pierw­szy to inne związ­ki poję­cio­we i inne defi­ni­cje pojęć. Produkt w kon­tek­ście sprze­da­ży ma nazwę, cenę, dostęp­ność itp. Produkt w kon­tek­ście uszko­dzeń ma numer seryj­ny, wer­sję, użyt­kow­ni­ka itp. Inne będą regu­ły biz­ne­so­we w każ­dym kom­po­nen­cie. Drugi powód to łatwa dostęp­ność na ryn­ku pro­duk­tów typu CRM i TicketXXX, szu­ka­nie jed­ne­go pakie­tu zin­te­gro­wa­ne­go” będzie bar­dzo trud­ne, bo kon­tek­stów sprze­da­ży a potem obsłu­gi uszko­dzeń czy rekla­ma­cji, jako pary, będzie tysią­ce warian­tów. Kupno osob­no i inte­gra­cja dwóch odpo­wied­nio dobra­nych pro­duk­tów (apli­ka­cji) będzie znacz­nie łatwiej­sze, i raczej obej­dzie bez kasto­mi­za­cji, któ­rej wyma­ga więk­szość (wszyst­kie??) pakie­tów zin­te­gro­wa­nych (one zawsze są jakimś zgni­łym kompromisem).

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). Tu opis (zno­wu M.Fowler):

One reaso­na­ble argu­ment we’ve heard is that you sho­uld­n’t start with a micro­se­rvi­ces archi­tec­tu­re. Instead begin with a mono­lith, keep it modu­lar, and split it into micro­se­rvi­ces once the mono­lith beco­mes a problem.

MFowler_Microservices

(M.Fowler Microservices).

Bardzo ład­nie poka­zał to Marin Fowler na jed­nej ze swo­ich pre­zen­ta­cji Testing stra­te­gies in a Microserices Architecture.

Polecam tak­że:

distri­bu­ted objects was altho­ugh you can encap­su­la­te many things behind object boun­da­ries, you can’t encap­su­la­te the remo­te­/in-pro­cess distinc­tion. An in-pro­cess func­tion call is fast and always suc­ce­eds (in that any excep­tions are due to the appli­ca­tion, not due to the mere fact of making the call). Remote calls, howe­ver, are orders of magni­tu­de slo­wer, and the­re­’s always a chan­ce that the call will fail due to a failu­re in the remo­te pro­cess or the con­nec­tion. (źr. Microservices and the First Law of Distributed Objects).

oraz:

Concluding with the famo­us Conway?s law: orga­ni­za­tions which design sys­tems ? are con­stra­ined to pro­du­ce desi­gns which are copies of the com­mu­ni­ca­tion struc­tu­res of the­se orga­ni­za­tions”. In other words, the com­mu­ni­ca­tion betwe­en two dif­fe­rent softwa­re modu­les is pro­por­tio­nal to the com­mu­ni­ca­tion betwe­en the desi­gners and deve­lo­pers of the­se modu­les. Conway?s law expo­ses the vul­ne­ra­bi­li­ty in mono­li­ths as they grow in size. Micro-servi­ces may not be the best, but bet­ter than mono­li­ths for the con­tem­po­ra­ry web based appli­ca­tions. (Źródło: Micro-Services: A com­pa­ri­son with Monoliths ? My Blog

A co dalej z ERP

Trzy lata temu robi­łem pew­ne pod­su­mo­wa­nie w jed­nym z arty­ku­łów na ten temat w kon­tek­ście sys­te­mów ERP, w zasa­dzie mogę je prze­pi­sać (a cały arty­kuł polecam ;):

Rynek sta­le się roz­wi­ja i doj­rze­wa. Praktycznie każ­da więk­sza fir­ma doświad­czy­ła w jakiejś for­mie wdro­że­nia goto­we­go, dosto­so­wy­wa­ne­go do potrzeb, opro­gra­mo­wa­nia ERP. Warto jed­nak pod­kre­ślić, że idea jed­ne­go ?super sys­te­mu? ERP II, odcho­dzi powo­li do lamu­sa. Moim zda­niem to kwe­stia roku, dwóch. Pierwsze symp­to­my to zale­ce­nia pro­du­cen­tów dużych sys­te­mów: wdra­żać goto­we opro­gra­mo­wa­nie w posta­ci ?goto­wej? tyl­ko tam gdzie pasu­je, obsza­ry spe­cy­ficz­ne dla fir­my opi­sać i zapro­jek­to­wać dla nich dedy­ko­wa­ne roz­wią­za­nie i zin­te­gro­wać. Dobry sys­tem ERP to śro­do­wi­sko pro­gra­mi­stycz­ne (tak zwa­ny fra­me­work, szkie­let). Systemy, nazwę je ?zapóź­nio­ne?, nadal wyma­ga­ją inge­ren­cji w ich kod by cokol­wiek osią­gnąć. Kompromisem jest sytu­acja, w któ­rej sys­tem ERP ma boga­ty inter­fejs (tak zwa­ne API, Application Programming Interface) pozwa­la­ją­cy na inte­gra­cję dedy­ko­wa­nych pod­sys­te­mów lub wła­śnie zewnętrz­nych kom­po­nen­tów czy­li korzy­sta­nia z moż­li­wo­ści jakie daje Cloud Computing. Przyszłość to komponenty?

(źr. Biznes wycho­dzi z objęć sys­te­mu ? mono­li­tycz­ne­go ERP | Jarosław Żeliński IT-Consulting).

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 2 komentarzy

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.