Hvad er Domain-Driven Design?

Domain-Driven Design (DDD) er en metode inden for softwareudvikling, som har et særligt fokus på at skabe en tæt kobling mellem forretning og software. I stedet for at tage udgangspunkt i teknologi eller arkitektur alene, begynder man med at forstå den forretningsmæssige kontekst — det såkaldte "domæne" — og designe softwaren ud fra det. Domænet repræsenterer det område, som softwaren skal understøtte, for eksempel e-handel, sundhedssektoren eller logistik. DDD handler om at opbygge en softwaremodel, der afspejler forretningens begreber, regler og processer på en præcis og konsistent måde. Ved at tage udgangspunkt i forretningslogikken frem for udelukkende tekniske overvejelser, bliver softwaren både lettere at forstå og mere tilpasset de faktiske behov. En af grundtankerne i DDD er, at software skal udvikles i tæt samarbejde mellem domæneeksperter (altså nogle, der ved en masse om deres fagområde/domæne) og softwareudviklere. Gennem en løbende dialog mellem disse parter opstår der en fælles forståelse, som hjælper med at forme den underliggende softwaremodel. Dette samarbejde gør det også lettere at imødekomme ændringer i forretningen, fordi softwaren er bygget op omkring begreber og regler, der er nemme at relatere til. Domain-Driven Design forbedrer ikke kun kvaliteten af koden, men også kommunikationen i hele udviklingsprocessen.

Bounded Context er et vigtigt begreb indenfor DDD

Bounded Context - Afgrænset kontekst

Et af de mest centrale og betydningsfulde begreber i Domain-Driven Design er Bounded Context. En bounded context definerer en klar afgrænsning, hvor en bestemt model og et sæt regler er gældende. Det betyder, at man opdeler det overordnede domæne i mindre, mere håndterbare områder, hvor begreber og logik giver mening inden for netop den kontekst. Formålet med bounded contexts er at reducere kompleksitet og undgå misforståelser, især når de samme begreber kan have flere betydninger. For eksempel kan begrebet “kunde” betyde noget forskelligt i forskellige afdelinger: I en faktureringsafdeling refererer “kunde” til en betalingsenhed med tilhørende fakturaoplysninger, mens det i en supportafdeling kan henvise til en person med en historik af supporthenvendelser. Hvis disse betydninger blandes sammen i softwaren, kan det føre til fejl og forvirring. Ved at inddele systemet i bounded contexts, sikrer man, at hvert område bruger begreber, regler og modeller, der giver mening netop dér — og kun dér.

Ubiquitous Language - Fælles sprog

Et andet nøglebegreb i Domain-Driven Design er Ubiquitous Language. Dette er et fælles sprog, der bruges af både udviklere og domæneeksperter både i dokumentation, i møder og ikke mindst i selve koden. Det handler om, at alle parter skal tale det samme sprog, med de samme ord og begreber, der har den samme betydning. Når fagspecialister og udviklere bruger forskellige udtryk for de samme ting, opstår der let misforståelser. Med et ubiquitous Language minimerer man disse problemer og skaber en bedre fælles forståelse, der går igen hele vejen fra koden til forretningsmøder. Dette fælles sprog gør det også muligt for personer uden teknisk baggrund at læse og forstå centrale dele af softwarens kode. Når kode afspejler virkelighedens domæne, bliver det både lettere at vedligeholde og nemmere at forstå for nye udviklere.

Bliv klogere på Domain-Driven Design hos CodeOptimus

Brug for rådgivning om Domain-driven Design?

Kontakt CodeOptimus for en uforpligtende snak om hvordan vi kan hjælpe jer med Domain-Driven Design og udvikling af skræddersyet software.