Mitä ymmärrän toimialuepohjaisesta suunnittelusta

DDD 101

Mitä suurempi projekti, sitä vaikeampi sitä on ylläpitää. Yksi tapa auttaa tässä on jakaa sovellus pienempiin osa-alueisiin niiden liiketoimintasääntöjen mukaan, joita kutsutaan toimialueiksi.

Periaatteessa toimialue on tietämyksen alue, joka on joko julkinen, kuten shakin säännöt, tai yksityinen, kuten voittoa tavoittelemattoman organisaation liiketoimintasäännöt.

Monimutkainen toimialue käyttää todennäköisesti tietämystä muilta toimialueilta. Esimerkiksi voittoa tavoittelematon järjestö, joka opettaa shakkia verkossa, tietää shakista, verkkoalustojen kautta tapahtuvasta opetuksesta ja, vaikkei sinua opiskelijana laskutettaisikaan, sen taloudesta.

Jokaista toimialueen osa-aluetta kutsutaan DDD:ssä rajatuiksi konteksteiksi (bounded contexts), ja kullakin niistä on oma mallinsa maailmasta, joka on rakennettu erikoistuneista ohjelmakoodin yksiköistä, niin sanotuista rakennusosista. Tässä keskityn entiteetteihin ja arvo-objekteihin, molempiin voidaan viitata objekteina.

Entiteetit ovat objekteja, joiden on tarkoitus olla ainutlaatuisia toimialueen sisällä. Tämä saavutetaan käyttämällä yhtä tai useampaa ominaisuutta tietyn entiteetin tunnistamiseen. Esimerkiksi kahdella käyttäjällä, jotka käyttävät samaa nimeä järjestelmässä, on aina eri sähköpostiosoitteet, koska sähköpostiosoitteita ei voi toistaa – useimmiten entiteetit erotetaan toisistaan id:llä ja joskus proprietien yhdistelmällä.

Arvo-objekteilla taas ei ole identiteettiä, joten vain niiden ominaisuuksia voidaan käyttää kahden instanssin erottamiseen. Otetaan esimerkiksi kaksi pelinappulaa (shakkipelimerkkiä), ne näyttävät samalta, jos ne tulevat samasta pelisarjasta ja niillä on sama väri, joten ei ole väliä, jos niitä vaihdetaan keskenään. DDD:ssä arvo-objektit ovat muuttumattomia, joten niiden kanssa on helpompi järkeillä.

Datan eheys

Rajoitettu konteksti ei paljasta kaikkia objektejaan taatakseen tiedon eheyden. Sen sijaan se paljastaa joitakin aggregaattijuuria eräänlaisena julkisena rajapintana itselleen.

Aggregaatti ei ole muuta kuin olio, joka koostuu muista objekteista. Tarkemmin sanottuna aggregaatti on joukko toisiinsa liittyviä objekteja, joita käsittelemme yhtenä yksikkönä tietoja muutettaessa.

Käytännössä aggregaatit omaksuvat puuksi kutsutun tietorakenteen muodon. Ja tästä syystä kaikilla aggregaateilla on juuri.

Ainut aggregaatin jäsen, johon muut objektit voivat viitata, on aggregaatin juuri, ja siksi me paljastamme sen. Tämä tehdään näin, koska se estää muita objekteja nipistämästä dataa tavalla, jota aggregaatti ei voi kontrolloida.

On tärkeää tehdä selväksi, että rajattu konteksti saattaa käyttää monia aggregaatteja, vaikka niiden juurta ei suoraan paljastettaisikaan ulkomaailmalle.

Käsittelemällä useita rajattuja konteksteja

Mutta asiat voivat muuttua mutkikkaammiksi, eikö niin? Jokainen rajattu konteksti saa hieman erilaisen mallin samoista objekteista, joilla on erilaiset ominaisuudet ja käyttäytyminen. Niinpä pelikontekstissa olevalla käyttäjällä voi olla ominaisuus, joka käsittelee pistemääräänsä, joka talouskontekstissa on merkityksetön ja jota ei siis ole olemassa.

Eikä siinä vielä kaikki. On myös mahdollista, että toimialueen käsite, joka esitetään oliona rajatussa kontekstissa, esitetään objekti-arvona toisessa kontekstissa, tai että se vain jätetään kokonaan pois.

Vaikka esimerkiksi opetuskonteksti vaatii, että opettajat esitetään olioina, jotta heidät voidaan kohdistaa opiskelijoille heidän id:nsä perusteella, rahoituskonteksti haluaa nähdä ”opettajan” mieluummin työntekijä-olion position-ominaisuuden arvona.

Joitakin muita DDD:n rakennuspalikoita ovat palvelut, arkistot, tehtaat ja tapahtumat. Yritän kuvailla niitä lyhyesti.

Palvelut ovat toimialueen kyvykkyyksiä, jotka eivät luonnostaan sovi entiteetteihin eivätkä objekti-arvoihin. Varo, että ne ovat toimialueen palveluita, eivät sovellus- tai infrastruktuuripalveluita.

Repositoryt ovat siltoja tallennusyksiköihin – hei CRUD!.

Tehtaat ovat menetelmiä toimialueen objektien luomiseen niin, että niillä ei koskaan ole virheellisiä arvoja. Tämä osa sai minut ajattelemaan tuotepohjaisia testejä.

Tapahtumat ovat objekteja, jotka edustavat jotakin toimialueella tapahtunutta – sen asiantuntijat välittävät niistä. Loistavia mahdollisuuksia luoda tapahtumapohjainen sovellus .

Evaikken muista Evansin niin sanoneen, rajatut kontekstit ovat mukava mahdollisuus jakaa koodisi mikropalveluihin, joissa jokainen palvelu on oma kontekstinsa. Ensimmäinen askel voisi olla ”virtuaalinen” pilkkominen, jossa jokainen konteksti laitetaan eri moduuliin samassa sovelluksessa, ja sitten jos havaitset, että ne ovat todella eristettyjä, siirrä ne eri moduuleihin.

A language to rule them all

Yksi ensimmäisistä asioista, joita ihmiset oppivat DDD:tä opiskellessaan, on se, että heidän järjestelmänsä tulisi kuvata ubiikkisella kielellä. Toisin sanoen meidän pitäisi kirjoittaa koodia käyttäen samoja verbejä (metodeille tai palveluille) ja substantiiveja (objekteille), joita toimialan asiantuntijat käyttävät meille puhuessaan.

Tällaisen koodin kirjoittamisen etuna on se, että se kuroo umpeen kommunikaatiokuilun kehittäjien ja asiantuntijoiden välillä heidän puhuessaan keskenään, mutta se on liiallista yksinkertaistamista todellisesta elämästä, joten itse käytän sitä ohjeena mutta en lopullisena ratkaisuna.

Säästin sen viimeiseksi, koska minulle tärkein asia DDD:stä jää yleensä lukematta, koska se on kirjan ”monimutkaisessa” osassa.

Viime aikoina olen oppinut, että kirjailija itse sanoi, että järjestys, jossa hän esittää asiat kirjassa, ei ole optimaalinen, ja se, mitä tässä kuvailin, on lähempänä sitä, mikä olisi ollut ihanteellista 😍. Kuulin sen eräässä podcastissa viitaten tähän