Domenedrevet utvikling — Domain-Driven Design (DDD) — er en måte å bygge programvare på der virksomhetens fagområde, domenet, styrer hvordan systemet designes. Ikke databasen. Ikke rammeverket. Ikke det siste innen teknologi. Faget først, teknologien etterpå.
Begrepet ble etablert av Eric Evans i 2003, men ideen er tidløs: de beste systemene bygges av folk som forstår problemet de løser. Et regnskapssystem bygget av utviklere som forstår bilagsføring, blir bedre enn ett bygget av utviklere som bare forstår SQL.
Domenet er sjefen
Tenk på et system for et dekkhotell. En «kunde» er ikke bare en rad i en tabell — det er noen med et dekksett på lager, en sesongavtale og et hjulskift som skal bookes før snøen kommer. Ordene bransjen bruker, er nøkkelen til hvordan systemet bør henge sammen. I domenedrevet utvikling tar vi disse begrepene på alvor: de blir klassene, tjenestene og reglene i koden.
Resultatet er et system der en fagperson og en utvikler kan se på samme skjerm og snakke samme språk. Når regnskapsføreren sier «denne fakturaen skal krediteres», finnes det en krediter()-operasjon i koden — ikke en «UPDATE status=4».
De tre kjerneideene
1. Felles språk
Utviklere og fageksperter bygger et felles vokabular — og bruker det konsekvent i samtaler, dokumentasjon og kode. Misforståelser oppdages tidlig, og endringer går raskere fordi alle vet hva ordene betyr.
2. Domenemodellen i sentrum
Forretningsreglene samles i en tydelig modell — ikke spredt utover databasetriggere, skjermbilder og hjelpeklasser. Modellen kan testes isolert, forklares på en tavle og videreutvikles uten å velte resten av systemet.
3. Avgrensede kontekster
Store virksomheter har mange delfag — salg, lager, fakturering — og samme ord kan bety ulike ting i hver av dem. I stedet for én stor modell som skal passe alle, deles systemet i avgrensede kontekster med hver sin presise modell. Les mer om dette i praksis her.
Hva får du igjen for det?
- Systemer som gjenspeiler virkeligheten — og derfor er lettere å endre når virkeligheten endrer seg
- Færre misforståelser mellom bestiller og utvikler
- Forretningslogikk som kan testes grundig, uavhengig av databaser og grensesnitt
- En kodebase nye utviklere forstår raskere, fordi den «snakker» virksomhetens språk
Domenedrevet utvikling er ikke et rammeverk du installerer — det er en arbeidsform. Den krever at utviklerne bryr seg om faget ditt. Det er nettopp derfor vi i Native Software har gjort den til kjernen i alt vi bygger.