Introduktion
Event sourcing er et af de arkitekturmønstre, der lyder fantastisk i teorien, men som kan være udfordrende i praksis. Efter at have kørt et event-sourced betalingssystem i produktion i 2 år har jeg lært, hvornår det er kompleksiteten værd, og hvornår det ikke er.
Hvad er event sourcing?
I stedet for at gemme den aktuelle tilstand af dine data, gemmer event sourcing en sekvens af hændelser, der førte til den tilstand. Tænk på det som et kontoudtog: i stedet for blot at vise din aktuelle saldo, viser det hver eneste transaktion, der bragte dig dertil.
De gode dele
Fuldstændigt audit-spor
Dette er den afgørende funktion. Når en kunde rapporterer et betalingsproblem, kan jeg genafspille hver hændelse og se præcis, hvad der skete. Ikke mere “jeg ved ikke, hvorfor systemet gjorde det”.
Tidsrejse-fejlfinding
Muligheden for at genafspille hændelser op til et bestemt tidspunkt er utroligt kraftfuld til fejlfinding. Jeg kan reproducere produktionsproblemer lokalt ved at genafspille event-strømmen.
Fleksibilitet i projektioner
Har du brug for en ny visning af dine data? Opret bare en ny projektion og genafspil hændelserne. Ingen komplekse databasemigreringer nødvendige.
De svære dele
Kompleksitet
Event sourcing tilføjer betydelig kompleksitet. Man skal tænke på:
- Versionering af hændelser og skema-evolution
- Eventual consistency
- Genopbygning af projektioner
- Performance af event-lageret
Eventual consistency
Dine projektioner er kun eventually consistent med event-strømmen. Det kan være forvirrende for udviklere, der er vant til øjeblikkelig konsistens.
Fejlfinding er anderledes
Når noget går galt, kan man ikke bare kigge i databasen. Man skal forstå event-strømmen og projektionerne.
Hvornår man skal bruge event sourcing
Baseret på min erfaring er event sourcing det værd, når:
- Audit-spor er kritisk: Finansielle systemer, sundhedssektoren, stærkt regulerede domæner
- Kompleks forretningslogik: Når man skal forstå, hvordan man nåede den aktuelle tilstand
- Flere visninger af data: Når forskellige dele af systemet har brug for forskellige repræsentationer
Hvornår man IKKE skal bruge event sourcing
Undgå event sourcing til:
- Simple CRUD-applikationer: Kompleksiteten er det ikke værd
- Prototyper eller MVP’er: Start simpelt, tilføj kompleksitet senere om nødvendigt
- Når teamet ikke er klar: Event sourcing kræver et mentalt skift
Praktiske tips
Start småt
Lav ikke event sourcing på hele dit system. Start med én afgrænset kontekst, hvor fordelene er tydelige.
Investér i værktøjer
Byg gode værktøjer til:
- At se hændelser
- At genafspille hændelser
- At overvåge projektions-lag
- Versionering af hændelser
Planlæg for skema-evolution
Hændelser er uforanderlige, men din forretningslogik vil ændre sig. Planlæg versionering af hændelser fra dag ét.
Konklusion
Event sourcing er et kraftfuldt mønster, men ikke en mirakelkur. Brug det, når fordelene (audit-spor, tidsrejse, fleksibilitet) opvejer kompleksiteten. For de fleste applikationer er traditionel tilstandsbaseret lagring enklere og tilstrækkelig.
Nøglen er at forstå afvejningerne og træffe en informeret beslutning baseret på dine specifikke krav.