Dobra arhitektura sistema pride do izraza pri dodajanju novih funkcionalnosti in pripomore k enostavnosti vzdrževanja ter nižanju razvojnih stroškov.
Septembra sva se s sodelavcem Luko Andrejakom udeležila londonske konference SymfonyLive, ki jo je predstavil tu. Sam pa sem se podrobneje dotaknil predavanja Hexagonal architecture – message-oriented software design, o katerem je razpravljal Matthias Eberlei. Ker se v iPROM-u s podobnimi sistemskimi izzivi srečujem prav vsak dan, sem želel temeljiteje predstaviti svoj pogled na pomembnost dobro zastavljene arhitekture sistema in predvsem pojasniti, zakaj je ravno njeno načrtovanje bistveno za vse nadaljnje razvojne in vzdrževalne procese.
Zakaj govorimo o arhitekturi sistema
Večinoma zato, ker si želimo, da pri dodajanju novih funkcionalnosti naše aplikacije oziroma sistemi ohranijo lastnost enostavnega vzdrževanja in nizkih razvojnih stroškov. Iz tega razloga je na njihovo arhitekturo potrebno misliti že na samem začetku razvoja aplikacije. V nasprotnem primeru bodo njihove posodobitve in vzdrževanje stale veliko več kot začetna pravilna postavitev arhitekture.
Klasična postavitev projekta oziroma osnovna zasnova programske opreme si običajno sledi po tem zaporedju:
- Izbira ogrodja (framework)
- Postavitev ogrodja
- Generiranje CRUD kontrolerjev
- Generiranje entitet
- Zaključek postavitve
KISS (Keep It Simple, Stupid)
Načeloma s takšno, preprosto strukturo ni nič narobe. V kolikor je projekt manjši in se aplikacija ne bo bistveno spreminjala, razvijala ali vzdrževala, bo slednja tudi zadovoljila potrebe, ki temeljijo na predvideni arhitekturi ogrodja. Pri projektih večje razsežnosti, ki se nadgrajujejo v daljšem časovnem roku, pa nas »preprosta« rešitev lahko stane veliko več in nas pripelje do zelo zahtevnega vzdrževanja ter dragega dodajanja novih funkcionalnosti.
Kljub temu je ena izmed najpogostejših napak razvijalcev programske opreme ravno ta, da ob sami postavitvi ogrodja ne razmišljajo o nadaljnjih nadgradnjah sistema ter njegovem dolgoročnem vzdrževanju in dodajanju novih funkcionalnosti. Z drugimi besedami – na začetku postavijo preveč preprosto arhitekturo, v kateri je med moduli prisotna pretirana odvisnost.
Razmišljajte dolgoročno
V večini primerov aplikacije niso preproste, poleg tega pa so pri sodobnih večjih aplikacijah vedno potrebne nadgradnje sistema. Vzrok za to so naknadne priključitve novih sistemov, pridobivanje in shranjevanje podatkov v nek »tretji« sistem ter spreminjajoče dinamike trga in vse bolj zahtevnih uporabnikov.
Primanjkljaj dolgoročnega razmisleka še posebej pride do izraza, ko razvijalci programske opreme sistemu dodajajo funkcionalnosti, ki prvotno niso bile razvite izključno zanj ali pa ko morajo vanj dodatno implementirati možnost povezovanja drugih sistemov, denimo preko API-jev ali drugih izvorov oziroma podatkovnih skladišč ipd.
V kolikor se razvijalci programske opreme ne držijo vseh začrtanih arhitekturnih pravil, ki jih na začetku postavi načrtovalec aplikacije, lahko aplikacija konvergira k zelo zapletenemu, skorajda neobvladljivemu sistemu. Takšna, večinoma nepredvidena eskalacija se seveda pokaže tudi pri znatno višjih stroških za vzdrževanje in implementaciji novih funkcionalnosti.
Kako se arhitekture sistema lotimo pravilno
Delovanje aplikacije si lahko že v načrtovalni fazi zamislimo na bolj abstraktnem nivoju, ki od nas zahteva postopno reševanje problemov oz. Funkcionalnosti. Za to uporabimo več nivojsko strukturo, pri čemer je ključno, da jedro aplikacije iz osnovne infrastrukture izločimo in ga predstavimo na abstrakten način. Medtem, ko ostale probleme lahko rešujemo preko nivojev in večplastnosti aplikacije.
Kljub temu pa želim poudariti, da univerzalne rešitve ni; kar pomeni, da tovrstnega načrtovanja ne moremo aplicirati na čisto vse projekte. Bolj je pomembno, da razvijalec pri zasnovi arhitekture upošteva več aspektov in da se pri tem nasloni na primere dobre prakse. Predvsem pa je nujno, da se dobro zaveda samega obsega in kompleksnosti projekta, saj ravno na podlagi teh podatkov lahko presodi, kakšna arhitektura bo najbolje delovala in izbere primerno programsko opremo, ki bo ustrezno reševala specifične izzive aktualnega projekta.
Zato bom v naslednjem prispevku podrobneje predstavil načelo heksagonalne arhitekture, ki nam dovoljuje bolj kompleksno in odprto načrtovanje; s tem pa zagotavlja ciljno reševanje nadaljnjih razvojnih izzivov, ki ne posegajo v druge module aplikacije.