Organisatsioonide muutmine tarkvara-jurakaid ei kannata

Mida tähendab domeenist juhinduv disain ja millistel organisatsioonidel seda kõige rohkem vaja on?

Kui agiilne arendus annab raamistiku võimalikult efektiivsele ja pidevale äriväärtuse tootmisele võimalikult väikeste riskidega, siis domeenist juhinduv disain annab võimekuse ehitada sillad ärivajaduste ja arendatavate tarkvarakomponentide vahele. Sõna 'domeen' tähendab antud mõistes mingit kindlat ärilist funktsiooni omavate teadmiste või tegevuste kogumit - mida mina isiklikult inimkeeli nimetaks lihtsalt rolliks või ametiks, mida tarkvara automatiseerib.

Ma leian, et pole organisatsiooni, kellel ei oleks kasu domeenist juhinduvast disainist, et seeläbi planeerida ja arendada ise või tellida korduvkasutatavaid tarkvaralahendusi. Esmajärjekorras soovitaksin sellesse sukelduda igal ettevõttel, kes on tajunud vajadust tükeldatud ja väiksemate sõltuvustega tarkvaralahenduste järele või kellel on täna sellega raskuseid olnud. Ma ei leia, et täna leiduks paremat meetodit hea arhitektuurini jõudmiseks.

Miks peaks sellele teemale tähelepanu pöörama ja mis võib juhtuda kui teemat ignoreerida?

Tarkvara arendaja Melvin Conway defineeris aastal 1967 'seaduse', et iga organisatsioon, millele anda ülesanne disainida omaenda süsteem lõpetab kohas, kus selle süsteemi ülesehitus on üks-ühele sarnane organisatsiooni kommunikatsioonistruktuuriga ja iga erinevus selles tekitab hõõrdumist. Ning olgugi, et see on öeldud viiskümmend aastat tagasi, siis kehtib see seadus tänaseni. See on näiteks põhjus, miks mitmed tarkvarad muutuvad ebamugavaks ja raskesti kasutatavaks - maailm pidevalt muutub ja tehnoloogia enam ei klapi seda kasutava organisatsiooniga. Kui tarkvara arenduses seda paratamatust arvesse ei võeta, siis võib öelda, et mis iganes uhiuue programmeerimiskeele ja pilvelahenduse peale ehitatud tarkvara oleks juba paari aasta pärast vaja ümber ehitada ja välja vahetada täies mahus, et organisatsioon ei kannataks.

Mida on domeenist juhinduva disaini rakendajatel võita ja kui palju kokku hoida?

Domeenist juhinduva disaini põhimõtted annavad võimekuse disainida lõpplahendused - protsessidest tehnoloogiateni - kujul, mis on paindlikumad ja sobituvad sellega, kuidas muutuvad ajas organisatsioonid ja nende tooted ning teenused. Kuna organisatsioonide ja toodete muutus vastavalt turule on elukriitiline ellujäämiseks, siis on tähtis, et tehnoloogia arhitektuur saaks ehitatud kujul, mis seda toetab. Seda eriti ajastul, kus tehnoloogiamaastik ja võimalused on rikkalikumad, kui kunagi varem ja tihti on kiusatus kõike uut proovida.

Näiteks üks suurimaid ootamatuseid, mis on juhtunud API-kesksete mikroteenuste arhitektuuri ehitamisega on see, et probleem on enamasti jäetud ainult inseneridele lahendada. Insenerid on tihti kõige helgemad pead terves majas, aga kui nende arenduses pole lähedast seost arendatava ärilise funktsiooniga nii, et nad seda terviklikult mõistaksid, siis ei saa olema ka arendatav tarkvara selline. Domeenist juhinduv disain aga välistab olukorra, kus arendusmeeskonnas oleks keegi, kes ei tunne 'toodet' põhjalikult ja pika elutsükliga tarkvara puhul on see hindamatu väärtus.