V primerjavi s klasično postavitvijo je bistvena prednost heksagonalne arhitekture ta, da infrastrukturo ločimo od domenskega jedra.
V prejšnjem blogu smo izpostavili arhitekturo sistema, ki je temeljni gradnik vsake aplikacije ali platforme, saj bo – v kolikor je ustrezno zastavljena – vzdržala pritiske sprememb in nam olajšala nadgradnje in vzdrževanje tudi tedaj, ko jih sprva nismo predvideli.
Kako pa nam pri načrtovanju lahko pomaga heksagonalna arhitektura?
Heksagonalno arhitekturo si lahko predstavljamo kot šesterokotni lik, pri katerem vsaka izmed njegov stranic predstavlja vhod/izhod v platformo oz. napredni sistem (seveda je lahko število stranic lika v praksi tudi veliko večje kot šest). Zato je pri razumevanju te arhitekture bistveno predvsem, da se ne omejujejo! Ustvarimo torej toliko nivojev oz. plasti aplikacij, kot jih potrebujemo.
Prav tako mora imeti vsaka izmed plasti tudi svoj adapter, ki ji omogoča komunikacijo tako z nadrejenim kot tudi podrejenim elementom. S tovrstno strukturo definiramo pretok – vsaka plast lahko komunicira samo s svojo nadrejeno in podrejeno plastjo, ne more pa preskakovati med njimi, kar se pri naknadni zamenjavi modulov ali ostalih večjih vzdrževalnih posegih izkaže za bistveno.
Kako deluje v praksi?
Za ponazoritev poglejmo njeno delovanje pri klasičnem http zahtevku. Slednji bo vstopil preko spletnega vtičnika in prešel skozi prvo plast aplikacije, ki v praksi predstavlja ogrodje. Tu se zahtevek obdela in posreduje v obliki sporočila preko adapterja v naslednjo plast, ki jo imenujemo aplikacijski nivo, kjer se sporočijo vrednosti in entitete iz infrastrukturnega nivoja, nato pa preidejo v domenski nivo aplikacije.
Zahtevek tako potuje preko več plasti aplikacije in se postopoma obdeluje vse do končnega cilja oz. domenskega jedra aplikacije.
V večini primerov pa pot http zahtevka ne poteka samo v domensko jedro, temveč tudi v nasprotno smer. Sledi inverzna pot skozi več plasti v našo končno destinacijo, ki lahko predstavlja zapis v podatkovno bazo ali pa preprosto posredovanje podatkov preko API-ja v nek tretji sistem. Tudi pri tovrstnih prehodih med plastmi veljajo vsa ista pravila pretvorbe podatkov in ukazov.
Kot sem že omenil, je bistvo heksagonalne arhitekture, da infrastrukturo ločimo od njenega domenskega jedra. Če bi bili v zgoraj navedenem primeru primorani zamenjati podatkovno bazo, bi nam tovrstno načrtovanje prihranilo številne preglavice, saj bi v tem primeru zamenjali le modul na plasti, ki skrbi za podatkovno bazo, brez nepotrebnih posegov v ostale plasti.