Domenedrevet design i FS
Denne siden forklarer hva domenedrevet design (DDD) er, hvordan det skiller seg fra systemarkitektur, og hvorfor det er viktig for utviklingen av FS som produkt. Den er skrevet for oss som utvikler FS – og er et utgangspunkt for samtaler om domenegrensene i FS også med lærestedene.
Hva er domenedrevet design?
Domenedrevet design handler om å strukturere et system rundt forretningslogikk og fagkunnskap – ikke rundt teknologi.
I stedet for å organisere kode og ansvar etter tekniske lag (database, API, frontend), organiserer DDD systemet etter meningsfulle faglige områder: domener. Et domene er et avgrenset område der begreper, regler og prosesser henger naturlig sammen.
To nøkkelbegreper:
Avgrenset kontekst (bounded context) er en tydelig grense rundt et faglig område der ett begrepsapparat gjelder. Innenfor grensen betyr ord det samme for alle – utviklere, fageksperter og produktfolk. På tvers av grenser kan samme ord bety noe annet, og det er helt greit – så lenge grensene er eksplisitte.
Entydig fagspråk (ubiquitous language) er det felles språket som brukes likt i kode, dokumentasjon og samtale innenfor en avgrenset kontekst. Det er ikke et teknisk språk – det er det faglige språket som fagekspertene og systemet deler.
Hva er forskjellen på domenearkitektur og systemarkitektur?
Systemarkitektur svarer på hvordan et system bygges: hvilke tjenester som deployes, hvilke databaser som brukes, hvordan komponenter kommuniserer. Det er viktig – men det kan ikke svare på hva systemet skal modellere eller hvorfor grensene er der de er.
| Domenearkitektur | Systemarkitektur | |
|---|---|---|
| Spørsmål | Hva og hvorfor | Hvordan |
| Fokus | Faglig logikk og begreper | Teknisk realisering |
| Eierskap | Produktteam og fageksperter | Tekniske arkitekter |
| Endringstakt | Langsom – domener er stabile | Rask – teknologi skifter |
| Uavhengig av teknologi | Ja | Nei |
Domenearkitekturen driver systemarkitekturen – ikke omvendt. En avgrenset kontekst er et naturlig kandidat for en tjenestegrense, men det betyr ikke at én kontekst alltid blir én mikrotjeneste. Det er et teknisk valg. Det faglige valget – hva som henger sammen – tas i domenearkitekturen.
En vanlig feil er å la tekniske grenser styre domenegrensene. Da ender man opp med et system som speiler organisasjonsstrukturen eller den historiske systemarkitekturen, ikke den faglige virkeligheten. Resultatet er tett kobling mellom ting som egentlig tilhører forskjellige domener – og løs kobling mellom ting som hører sammen.
Hvorfor er dette viktig for FS?
FS er et system der kompleksiteten primært er faglig, ikke teknisk. FS modellerer norsk høyere utdanning – et domene med 30+ års akkumulert regelverk, institusjonelle særordninger, nasjonale standarder og et lovverk som endres kontinuerlig.
Mye av den tekniske gjelden i FS stammer fra at systemgrenser historisk ble trukket etter hva som var finansiert og praktisk å bygge, ikke etter hva som er naturlige faglige konsepter. Resultatet er tett kobling mellom ting som egentlig tilhører forskjellige domener, og uklarhet om hvem som eier hvilke begreper og prosesser.
Hvilken praktisk nytteverdi gir domeneinndeling etter DDD?
Tydeligere grenser og eierskap. Vi trenger eksplisitte grenser for entiteter, begreper og prosesser – slik at det er klart hvem som eier hva, og hvem som kan endre hva uten å påvirke andre.
API og integrasjon. Domeneinndeling må inkludere API- og integrasjonsområder. Grensene i domenekartet er naturlige steder for API-grensesnitt og integrasjonspunkter.
Støttedomener. FS inneholder domener som ikke er studieadministrative – kommunikasjon, brukeradministrasjon, systeminnstillinger. Disse må ha et tydelig hjem i domenelandskapet, ellers forurenser de kjernemodellene.
Struktur på fs.sikt.no. Domeneinndeling gjenbrukes i begreps- og prosessoversikter på fs.sikt.no, slik at informasjon organiseres etter hvilket domene i FS teamet jobber innenfor.
Systemkrav. Domeneinndeling kan gjenbrukes som struktur for systemkrav som publiseres på fs.sikt.no.
Fra prosessorientert til objektorientert domenestruktur
Vi har tidligere forsøkt å modellere domener etter prosesser inspirert av HERM-modellen for høyere utdanningsinstitusjoner. HERM har et naturlig fokus på hva lærestedene leverer – prosessene rundt utdanning, studieadministrasjon, forskning og formidling, sett fra institusjonens perspektiv.
Denne modellen har tjent FS godt, men har begrensninger:
- Prosessgrenser følger ikke nødvendigvis naturlige objektgrenser – det gjør det uklart hvem som eier hvilke data
- Fokus på de høyere utdanningsinstitusjonenes prosesser gjør det vanskeligere å modellere personen og studenten som selvstendige objekter på tvers av læresteder
- Prosessarkitektur er vanskeligere å modernisere i deler, fordi prosesser gjerne går på tvers av det som faglig henger sammen
En objektbasert domenestruktur – slik DDD legger opp til – tar utgangspunkt i hva som finnes (person, utdanning, organisasjon, studieforhold) og hvilke regler som gjelder innenfor hvert område, uavhengig av hvilken prosess som trigger det.
Dette er ikke et brudd med HERM – det er en videreutvikling som gjør at FS kan modellere prosessene fra HERM, men med tydeligere eierskap og mer robuste grenser.
Kontekstkartet for FS
Kontekstkartet viser de avgrensede kontekstene i FS og relasjonene mellom dem. Det er et levende dokument som vil oppdateres etter hvert som domenegrensene diskuteres og justeres.
Se kontekstkartet.