Szperałem w sie­ci szu­ka­jąc infor­ma­cji o archi­tek­tu­rze i micro­se­rvi­sach, a wpa­dłem na to:

… 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)

To ​„pra­wo” wyja­śnia dla­cze­go powsta­ją złe inter­fej­sy a nawet zła archi­tek­tu­ra: z regu­ły dla­te­go, że to – archi­tek­tu­ra – jest lep­szym lub gor­szym kom­pro­mi­sem pomię­dzy zespo­ła­mi pro­gra­mi­stów, ich obcią­że­nia, krót­kich ter­mi­nów itp. Obserwuję to dość czę­sto w orga­ni­za­cji pra­cy developerów.

Jednak, żeby powsta­ła taka ​„dobra archi­tek­tu­ra”, ktoś ​„ponad zespo­łem deve­lo­pe­rów” powi­nien zapro­jek­to­wać archi­tek­tu­rę: kom­po­nen­ty z ich odpo­wie­dzial­no­ścia­mi i inter­fej­sy mię­dzy nimi.

Typowym pro­ble­mem jaki napo­ty­kam, nie tyl­ko w dużych pro­jek­tach dla ​„budże­tów­ki”, jest archi­tek­tu­ra będą­ca efek­tem prze­py­cha­nek, poli­ty­ki, wal­ki o ​„men­dej­sy”, czy­li o to któ­ry dostaw­ca (albo wewnętrz­ny zespół) dosta­nie więk­szy budżet. To naj­gor­sze i nie­ste­ty nie raz spo­ty­ka­ne meto­dy budo­wy architektury.

Jak to robić dobrze? Idąc za Fowlerem, pod­sta­wą budo­wy (usta­la­nia) gra­ni­cy odpo­wie­dzial­no­ści kom­po­nen­tu jest ​„gra­ni­ca kon­tek­stu”. Można to przed­sta­wić tak:

Powyżej poka­za­no wynik ana­li­zy, mamy tu model poję­cio­wy. Widać, że pew­ne poję­cia (doce­lo­wo kla­sy, ich ope­ra­cje i atry­bu­ty) są dość gęsto powią­za­ne, inne luź­no. Granice pomię­dzy kom­po­nen­ta­mi powin­no budo­wać się tak, by sil­nie powią­za­ne ele­men­ty były w jed­nym kom­po­nen­cie (nigdy nie roz­dzie­laj rodzi­ny) a inter­fej­sy mię­dzy nimi były jak naj­prost­sze. Stosowanie DTO ozna­cza, że kom­po­nent powi­nien jed­no­ra­zo­wo zażą­dać całe­go agre­ga­tu danych (doku­men­tu) i same­mu sko­rzy­stać, nawet tyl­ko z czę­ści danych któ­re dostał, zamiast deta­licz­nie pro­sić o poszcze­gól­ne pola. Innymi sło­wy nie­za­leż­nie od tego czy w danym momen­cie potrze­bu­je­my tyl­ko war­to­ści kon­kret­nej fak­tu­ry, danych nabyw­cy czy fak­tycz­nie całej jej zawar­to­ści, zawsze żąda­my całej fak­tu­ry. Dzięki temu inter­fejs (API) jest prost­sze, licz­ba wywo­łań API jest zawsze mała. Powyższy przy­pa­dek zaowo­cu­je poniż­szym podzia­łem na komponenty:

Metoda ta i podej­ście (jako dobra prak­ty­ka), i u Fowlera (cyto­wa­ny DTO) i u Evansa (autor wzor­ca Domain Driven Design) nazy­wa­na jest ​„boun­ded con­text” (gra­ni­ca kon­tek­stu, rodzi­na zawsze razem i tyl­ko jed­na rodzi­na w jed­nym miesz­ka­niu). Dzięki temu uzy­sku­je­my bar­dzo dobry, przy oka­zji zgod­ny z zasa­dą „[[Open Close Pryncypia]]”, model archi­tek­tu­ry, któ­ry pozwa­la zle­cić kom­po­nen­ty do wyko­na­nia, defi­niu­jąc wyłącz­nie opra­co­wa­ne już inter­fej­sy, kolej­ność ich (kom­po­nen­tów) wyko­na­nia nie ma zna­cze­nia dla całości.

Przy oka­zji ujaw­nia się ​„zło” jakie wyrzą­dza budo­wa­nie zło­żo­ne­go opro­gra­mo­wa­nia na bazie inte­gra­cji poprzez współ­dzie­le­nie danych:

Komponenty są sil­nie od sie­bie uza­leż­nio­ne (współ­dzie­lo­na baza danych w mode­lu rela­cyj­nym), nie da się two­rzyć (kodo­wać) tych kom­po­nen­tów nie­za­leż­nie od sie­bie, bo trze­ba uzgad­niać a potem uznać, wspól­ny model danych. Ingerencja w jaki­kol­wiek kom­po­nent z regu­ły ozna­cza inge­ren­cję w całą aplikację.

Dzieląc sys­tem na nie­za­leż­ne kom­po­nen­ty (każ­dy kom­po­nent sam zarzą­dza swo­imi dany­mi) , usta­la­my inte­gra­cję z uży­ciem inter­fej­sów a nie współ­dzie­ląc dane, z cze­go cał­ko­wi­cie rezygnujemy:

To jest powód dla któ­re­go, w dobrych fir­mach deve­lo­per­skich klu­czo­wą rolę peł­ni archi­tekt. Na pozio­mie logi­ki biz­ne­so­wej, w zasa­dzie jest nim – takim archi­tek­tem – ana­li­tyk biz­ne­so­wy-pro­jek­tant, któ­ry po zakoń­cze­niu eta­pu ana­li­zy i pro­jek­to­wa­nia, peł­ni rolę „[[pro­duct owne­ra]]”, pro­wa­dzą­ce­go nad­zór autor­ski i zarzą­dza­nie zmia­ną wymagań.

Tak więc archi­tek­tu­ra powin­na być efek­tem głę­bo­kiej ana­li­zy i pro­jek­to­wa­nia z testa­mi, dopie­ro potem powin­na się stać – być może każ­dy kom­po­nent osob­no – mate­ria­łem do zle­ce­nia dla deve­lo­pe­rów. Najgorszy wariant to podział na kom­po­nen­ty z pomo­cą nego­cja­cji, poli­ty­ki i wal­ki o budżet.