Bedre backend-systemer: Hvorfor event sourcing og domain-modeller gør en forskel

I software-verdenen dukker event sourcing, domain-driven design og CQRS ofte op som magiske løsninger. De lyder avancerede og skræmmende. Mange udviklere springer dem over – eller bygger unødvendig kompleksitet.

Men disse mønstre løser ægte udfordringer. Og de er lettere at nærme sig i dag.

Hvad er problemet?

De fleste apps ser databasen som den eneste sandhed. Du gemmer en bruger, ændrer den, gemmer igen. Nemt nok.

Men hvad hvis du skal spore ændringer? Se præcis hvornår og hvorfor noget skete? Genskabe systemet for at debugge en fejl? Eller håndtere et domæne med masser af forretningsregler, der ikke passer i et simpelt snapshot?

Her kommer event sourcing ind. I stedet for kun nuværende tilstand lagrer du begivenhederne, der førte til den. Hver handling – betaling godkendt, ordre oprettet, lager opdateret – bliver en uforanderlig log. Den aktuelle tilstand? Den bygges ved at genafspille events.

Kombiner det med domain-driven design, der modellerer koden efter virkelige forretningsbegreber. Resultatet er systemer, der er:

• Altid auditerbare – alt er logget
• Lette at debugge – hop til ethvert tidspunkt
• Skalerbare – adskil skriv og læs
• Forretningsnære – koden matcher logikken

Den største faldgrube

Problemet er ofte tankegangen. Event sourcing kræver, at du tænker i aggregates (grupper af relaterede objekter), commands (handlinger, der ændrer tilstand) og events (hvad der skete).

Gør du det forkert, bliver systemet uoverskueligt. Gør du det rigtigt, dokumenterer arkitekturen sig selv.

Udfordringen? De fleste har ingen god måde at fange modellen på. Hvidtavle-sketser eller hovedet er ikke nok. Det skaber problemer ved:

• Ny medarbejder-onboarding
• Snak med ikke-tekniske folk
• Værktøjer, der skal forstå domænet
• AI, der skal hjælpe med modeller

ESDM: Et sprog til din arkitektur

Her hjælper ESDM (Event-Sourced Domain Modeling). Det er et YAML-baseret sprog til at beskrive event-sourced systemer:

• Aggregates – centrale forretningsenheder
• Events – hvad der skete
• Commands – hvad der udløste det
• Read Models – til spørgsmål om data
• Process Managers – til komplekse workflows
• Context Mappings – kommunikation mellem domæner

YAML er læsbart for mennesker og parsbart for værktøjer. Bedst af alt: Store sprogmodeller kan læse og skrive det direkte.

AI gør det nemmere

Moderne teams bruger allerede AI til kode. Hvorfor ikke til domain-modeller?

Giv din kode til en LLM med ESDM-vokabular – den udtrækker en model. Starter du frisk? Få hjælp til den første skitse. YAML-filen bliver dokumentation og grundlag for værktøjer.

Det erstatter ikke domæne-ekspertise. Nogen skal validere. Men det fremskynder vejen fra "sådan virker vores forretning" til "her er system-strukturen".

Tilpas til dit niveau

Ikke alle er klar til event sourcing:

Nybegynder? Start med grundlæggende eksempler. Gå fra "hvad er en aggregate?" til din første model.

Har allerede et system? Dokumenter det. En formel model hjælper onboarding og fremtidige valg.

Bygger værktøjer? Brug schemaet som kontrakt til validatorer, generatorer og plugins.

Bruger AI? ESDM's struktur gør det muligt for LLMs at arbejde præcist.

Det store billede

Event sourcing og domain-driven design er ikke mirakler. De tilføjer kompleksitet. Men i de rigtige retninger: audit, skalering og klarhed.

Værktøjerne bliver bedre. Et standardiseret format til modeller – med validering og kodegenerering – sænker barrieren.

Med AI til skitsering går du hurtigere fra idé til færdig ESDM-fil.

Hvad betyder det for dig?

Bygger du systemer, der skal:

• Være vedligeholdelige over tid
• Opfylde audit-krav
• Skalere med logik
• Være lette at forstå

Så er domain-modellering ikke sløseri. Det er grundlaget.

Start småt. Model ét bounded context. Se klarheden. Gentag. Brug AI til udkast. Strukturen tæller.

Din fremtidige selv og teamet takker dig for en klar log af hvad systemet gør – og hvorfor.