Hvorfor bruke domenedrevet design (DDD)?

I februar i år holdt vi en spennende fagkveld med fokus på Domain Driven Design i praksis. Formålet med arrangementet var å besvare et viktig spørsmål: hva kreves for å kunne si at man virkelig jobber domenedrevet? Vi ønsket å utforske hvordan et team som jobber domenedrevet faktisk ser ut, og hvordan denne tilnærmingen gjenspeiles i kodebasen.

Vi hadde besøk av to foredragsholdere som har praktisk erfaring med DDD. Einar Høst er sosio-teknisk rådgiver i NAV, og har lang erfaring fra prosjekter som har tatt i bruk DDD. Almir Mesic er utvikler i Resoptima, og er spesielt opptatt av hvordan DDD kan implementeres i kode. Denne superkomboen gav oss en god innføring i DDD.

DDD ble først introdusert av Eric Evans i 2003 i hans bok "Domain-Driven Design: Tackling Complexity in the Heart of Software". Evans utviklet DDD etter å ha jobbet i flere store organisasjoner og sett at mange av problemene i programvareutvikling skyldes manglende forståelse av domenet. Han mente at å forstå og modellere domenet vil gjøre det enklere å utvikle programvare som faktisk løser reelle utfordringer, og gir verdi for brukerne.

Hva er egentlig DDD og hvordan komme i gang

DDD er en metodikk for å designe programvare som fokuserer på forståelsen av problemområdet, eller domenet, som programvaren skal løse. Dette betyr at utviklerne må gå dypere inn i forretningsprosessene og bruke domenespesifikk kunnskap for å lage en modell som reflekterer virkeligheten på en nøyaktig måte.

Første foredragsholder på vår fagkveld, Einar Høst, er opptatt av alt det sosiale som påvirker koden og løsningene vi lager. Det hele starter med en hvordan et selskap organiserer seg. På grunn av grensesnitt og kommunikasjon mellom og innad i team og avdelinger vil organisasjonsstrukturen påvirke hvordan arkitektur og løsningene blir. Har du kjennskap til Conway's law og ikke lest boken Team Topologies anbefaler vi å lese den!

Et esel er ikke en hest

Videre er det viktig å få på plass et felles språk. Einar beviste dette gjennom eksempler på hvor komplekse problemer man kan få på grunn av språk. Et eksempel handlet om hester. Hvis man fra starten av i en ny løsning kaller en hest for en hest. Så legger man inn egenskaper og logikk knyttet til denne. Så får løsningen inn en ny type hest, nemlig et esel (som egentlig ikke er en hest og har helt andre egenskaper og logikk). I starten vil det kanskje fungere å snakke om eselet som en hest, men etter hvert kan dette skape problemer.

Et godt verktøy for å få på plass en felles forståelse for programvaren som skal lages er Event Storming. Med Event Storming sørger man for at alle behov og begreper knyttet til løsningen avdekkes. I praksis utføres Event Storming ved at alle samles i et rom hvor det er en stor tavle til modellering. På denne tavlen plasseres ‘Post It’-lapper som beskriver hendelser i domene (uttrykt i fortid). I kontekst av en nettbutikk, kan det f.eks. være «Ordre bekreftet» eller «Betaling mottatt». Alle har egne lapper og kan bidra til modelleringen. Denne øvelsen gjør at det er lav terskel for å bidra, og at man fokuserer på domenet og ikke på løsningen.

– Det er kostbart å samle alle interessenter i et rom en dag, men det koster mer å starte ut feil!

Med Event Storming får man også på plass et felles begrepsapparat og enhetlig språk i løsningen. I DDD kalles dette ‘Ubiquitous Language’. Etter man har delt modellen i flere domener, blir dette felles språket i domenet svært viktig. Det er viktig at alle som jobber med samme domene bruker de samme begrepene, slik at det ikke oppstår misforståelser.

Ord og uttrykk som brukes i modelleringen, bør også gjenbrukes i koden. Når dette gjøres på riktig måte, kan alle uansett fagområde, forstå koden. Det var dette Almir snakket om på fagkvelden. Han viste oss hvordan funksjonelle kodespråk, spesifikt F#, er godt egnet til å modellere domenet i kode. Almirs presentasjon var inspirert av boken Domain Modelling Made Functional av Scott Wlaschin, som dekker dette emnet i dybden.

Kan man bruke norsk som domenespråk?

Etter foredragene arrangerte vi en Fishbowl, der konseptet er at et panel med deltagere skal diskutere forhåndsdefinerte spørsmål. Hvis noen fra salen ønsker å komme med argumenter så kommer de opp og bytter ut en av de i panelet. Det fører til at panelet hele tiden roteres, og at alle som ønsker kan bidra i debatten. Panelet startet med Einar og Almir, samt Lars og Hallstein fra Novanet.

Spørsmålene var av type "Hva skal til for å kalle det DDD?", "Når skal man ikke bruke DDD?", "Kan man bruke litt DDD?", "Funker noen programmeringsspråk bedre til DDD enn andre?". Panelet var nogenlunde enig i sin egen argumentasjon, og den store opphetede debatten uteble. For spørsmålet "Kan man bruke norsk som domenespråk?" mente panelet at man burde bruke norsk for domenemodeller der organisasjonen snakker norsk, men her kom det reaksjoner fra salen og erfaringer om det motsatte. Dette er et spørsmål med mange meninger og erfaringer, og det ble en god diskusjon.

Våre erfaringer

Novanet har over tid fulgt utviklingen av DDD og har deltatt i flere prosjekter hvor vi har benyttet DDD i ulik grad, både av oss selv og andre. Det er viktig å påpeke at DDD består av flere deler, fra høynivå modellering til detaljert teknisk implementasjon. Det er avgjørende å tilpasse DDD til den aktuelle organisasjonen og teamet man har, og bruke de delene som passer best.

Ved å ta i bruk Domenedrevet Design, Event Storming og Team Topologies vil man sørge for bedre kunnskapsdeling mellom utviklere og domeneeksperter. Dette vil sørge for løsninger som treffer både de som skal utvikle og de som skal benytte løsningen bedre!

Lyst til å teste Even Storming og DDD? Ta kontakt med Lars hos oss for hjelp til tilrettelegging.