Domain-Driven Design

Esimerkki DDD-sovellusarkkitehtuurista.

Vaughn Vernon: ”Implementing Domain-Driven Design”

Domain-Driven Design on uusi lähestymistapa ohjelmistokehitykseen, joka on saavuttanut suosiota viime vuosien aikana. Termi voisi olla löyhästi suomennettuna ”sovellusalakeskeinen suunnittelu”. Lähestymistapa lähti liikkeelle Eric Evansin kirjasta ”Domain Driven Design”. Kirjassa esitetyt ajatukset olivat kuitenkin hieman ympäripyöreästi kirjoitettuja, joten Vaughn Vernon päätti kirjoittaa kirjan ”Implementing Domain-Driven Design”, jossa konseptia yritetään avata hieman enemmän. Vernonin kirja sai pienessä hetkessä suuren suosion. Kirjassa kerrotaan muun muassa DDD:n liiketoimintahyödyistä ja siitä siirrytään pehmeästi lähestymistavan teoreettiseen toteutukseen.

Kirjasta oppii Domain-Driven Designin käsitteitä ja miten niitä voidaan soveltaa ohjelmistokehityksessä. Käsitteiden tarkoitusta saattaa olla aluksi hieman hankala sisäistää, mutta monet, jotka ovat työskennelleet isoissa projekteissa, huomaavat heti niiden hyödyt. Käsitteillä on tarkoitus antaa lukijalle eväitä suunnitella ja toteuttaa sovelluksia siten, että niitä on helppo ylläpitää ja koodia on helppo lukea.

Monissa sovelluksissa ei ole otettu huomioon sovellusalan muuttuvuutta suunnitteluvaiheessa ja tästä johtuen sovelluksen muuttaminen myöhemmin aiheuttaa suuria ongelmia. Tämä on yleistä yritysmaailmassa, jossa asiakas haluaa uusia toiminnallisuuksia tai muutoksia jo olemassaolevaan sovellukseen. Domain-Driven Design on hyödyllinen näiden ongelmien ratkaisussa.

Kuvassa nähdään DDD-sovellus jaettuna erilaisiin toiminnallisuuskerroksiin. Kuvan keskiössä on sovellusala (domain model), jota muut tasot soveltavat. Sovellusala sisältää sovelluksen käsittelemän tietomallin ja siihen liittyvää bisneslogiikkaa. Sovellusalapalvelut (domain services) on taso, jonka avulla sovellusalaa voidaan käsitellä ja sinne kuuluu myös suurin osa sovelluksen bisneslogiikasta. Sovelluspalvelut (application services) –tasolla ei ole ollenkaan bisneslogiikkaa, vaan siellä tehdään sovellusalapalveluiden toiminnallisuuksista tarkoituksenmukaisia toimintoja, jota voidaan käyttää esimerkiksi käyttöliittymässä (UI).

DDD:tä olen itse soveltanut projektissa, jossa integroidaan vanha järjestelmä uuden sukupolven tekniikoihin, esimerkiksi mobiililaitteiden käyttöön. Vanhassa järjestelmässä on haastava tietomalli, joka konvertoidaan DDD:n periaatteiden mukaisesti suunniteltuun ”puhtaaseen” sovellusalaan (kirjassa s. 126). Puhdasta sovellusalaa voidaan käyttää uudessa sovelluksessa yllämainitun kaavion mukaisesti. DDD:n avulla suunniteltua sovellusalaa on helppo laajentaa ja muuttaa projektin kehittyessä, ilman että koko ohjelmisto hajoaa käsiin. Vanha järjestelmä siis jää kuitenkin käyttöön, mutta siihen luodaan ns. välikäsi, jota voidaan laajentaa tarvittaessa.

On tärkeää ottaa huomioon, että itse kirjoitan koodarin näkökulmasta tästä aiheesta. DDD on paljon muutakin kuin tapoja kirjoittaa koodia. Sen avulla voidaan varmistaa, että koko sovelluskehitysprosessi tehdään oikein (kirjassa s. 25). Koko homman voisi kiteyttää siihen, että DDD:ssä yritetään antaa työkalut ongelmien löytämiseen ja valuttaa ne pois hyvällä suunnittelumallilla, ennen kuin niistä aiheutuu haittaa.

Kirjan lukemiseen kannattaa varata reilusti aikaa, koska teksti ei ole keveintä ja muistettavaa on paljon. Välillä joutuu pureskelemaan asioita ennen kuin voi lukea seuraavan kappaleen. Suosittelisin kirjaa kaikille ohjelmistotuotannosta kiinnostuneille, joilla on ylimääräistä aikaa.

Linkki kirjaan

http://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577

Kirjoittaja on ohjelmistotuotannon opiskelija Henrik Toivakka.