Bliv agil med event sourcing

En af løfterne i forbindelse med agil udvikling er at det skal blive lettere at skifte mening. Forretningerne ændrer sig konstant og vi forsøger ihærdigt som udviklere at elske dette.

Som konsulent har jeg gang på gang set det ske – mine kollegaer sværger at de er agile, måske har de endda underskrevet manifestet. Men så kommer den store skelsættende ændring. En ændring der ikke passer med den aktuelle softwares arkitektur. Svaret til forretningen er ofte blandet med lidt unfair tech-snak;

Hvis vi skal lave den ændring kan vi lige så starte forfra – vi har en constraint på X så Y kan ikke frit ændre sig – det skal vendes helt om og så skal hele strukturen migreres.

Problemet er at udviklerne taler sandt – ofte ender vi op med en arkitektur hvor ændringer er svære at håndtere og giver sideeffekter i hele systemet.

Som udviklere navigerer vi igennem en kæmpe graf af et tilstandsrum – vægtene i grafen er erfaring, kreativitet, forretningskrav, deadlines og meget andet. Men ens for de valg vi foretager er at de også er lig med en række fravalg.

Skriver vi software efter de klassiske principper sker det typisk ved at vi skaber en model af virkeligheden i form af strukturer i kode. Nøgleordet her er model – der sker altså en forsimpling. Et aktivt fravalg af de koncepter og tilstande vores model kan beskrive.

Efter traditionelle udviklingsprincipper, kunne en forsimplet model for et ordresystem se sådan ud:

Et klasse repræsenterer selve ordren og en anden de varer der er tilknyttet. Da ordresystemer også tit ser sådan ud i lærebøgerne er det svært at argumentere mod at denne model er korrekt. Den kunne være implementeret efter en story der kunne lyde sådan her:

Som kunde vil jeg gerne kunne oprette en ordre, så jeg kan bestille varer

Ydermere kunne der være behov for at kunne fjerne varer fra kurven og det gør vi blot ved at fjerne ordrelinjen igen.

Lad os antage at vi nu har lavet et sådan system, og det har været i produktion i et stykke tid. Alt er i den skønneste orden og systemet fungerer som det skal men salget går lidt sløvt. En dag kommer en sælger på en fiks idé. Han har set at når man på amazon.com én gang har haft en vare i kurven, så målretter de al fremtidig markedsføring. Det må da være en smal sag at tilføje dette til vores shop? Det er det bare ikke – for vi har ikke den information. Det at vi fjerner varer fra kurven ved at slette data betyder samtidig at vi destruerer information.

Det er klart at problemet kan løses – en typisk løsning er at tombstone data, altså bare markere data med et flag i stedet for at slette dem. Det løser så kun dette ene problem, og giver kun data fra fremtidige transaktioner.

Event sourcing

Mogens Heller Grabe beskriver event sourcing som “… handler event sourcing om at der aldrig foretages destruktive ændringer i systemet”. Med disse principper kan eksemplet fra før modelleres således:

eventsourcing3

Hermed indfanger modellen alle de handlinger der er sket, når kravet om at finde varer der har været i folks kurv skal indfries, er det blot et spørgsmål om at lave et passende udtræk.

Man kan så igen argumentere for at vi designer for fremtiden men ud over fremdige gevinster er der også øjeblikkelige gevinster at hente:

  • Behovet for logning af brugerhandlinger falder drastisk.
  • Det at data ikke kan slettes kan gøre vores sikkerhedsmodel enklere.
  • I fejlsøgningssituationer har vi langt mere information til rådighed.
  • Ingen behov for låsninger i vores datastore, da vi aldrig overskriver data.
  • Ændringer foregår oftere ved at skrive ny kode (tilføje nye events), hermed falder risikoen for fejl.

Ulempen er så øget kompleksitet, især ved læsninger – noget af dette kan gøres enklere ved hjælp af snapshots som Mogens også har beskrevet.

En af de agile udviklingsprincipper er at udsætte beslutninger til sidste øjeblik, det nedsætter behovet for dokumentation og gør det lettere at skifte mening. Ofte hører man at det har negativ indflydelse på ens arkitektur – at den kun bliver god hvis man laver et større designarbejde up-front. Med event sourcing får vi løst en del af dette problem – vi får en arkitektur der noget nemmere kan flytte sig, uden at gå på kompromis.

4 comments for “Bliv agil med event sourcing

  1. Fed blogpost, og tak for det – jeg gjorde ikke så voldsomt meget ud af at snakke om fordele/ulemper ved event sourcing, så det er dejligt at du kommer ind på det.

    Efter min mening er der virkelig mange fordele ved event sourcing (og CQRS, som er det hack, der får event sourcing til at fungere i virkeligheden) – og fleksibiliteten i projektionsdelen af systemet er uden tvivl en af de største!

    Jeg får simpelthen stadigvæk det største kick hver eneste gang vores BI’ere beder om et par ekstra felter i SQL-eksporten (som naturligvis er et view på lige fod med alle andre views i systemet), hvorefter jeg tilføjer dem og WHOOP! så er alle event replayed og felterne er udfyldt som om de altid havde været der.

    Det giver en kæmpe reduktion i indledende analysearbejde da vi aldrig er nødt til at gemme noget fordi “hvad nu hvis?”

  2. Fed blogpost, og tak for det – jeg gjorde ikke så voldsomt meget ud af at snakke om fordele/ulemper ved event sourcing, så det er dejligt at du kommer ind på det.

    Efter min mening er der virkelig mange fordele ved event sourcing (og CQRS, som er det hack, der får event sourcing til at fungere i virkeligheden) – og fleksibiliteten i projektionsdelen af systemet er uden tvivl en af de største!

    Jeg får simpelthen stadigvæk det største kick hver eneste gang vores BI’ere beder om et par ekstra felter i SQL-eksporten (som naturligvis er et view på lige fod med alle andre views i systemet), hvorefter jeg tilføjer dem og WHOOP! så er alle event replayed og felterne er udfyldt som om de altid havde været der.

    Det giver en kæmpe reduktion i indledende analysearbejde da vi aldrig er nødt til at gemme noget fordi “hvad nu hvis?”

  3. Tak.

    Ja, har bevidst holdt CQRS-snakken ude af indlægget.

    Jeg stødte egentlig mest på det fordi at vi ønskede at hoste nogle ting på låsningsfri databaser (altså heller ikke optimistisk låsning). Da jeg så havde tænkt længe nok over de problemer der skulle løses så stod jeg tilbage med CQRS.

    Sjovt med sådan noget teknologi, der har eksisteret så længe – men man først selv er blevet rigtig klar til at indrage det nu.

  4. Tak.

    Ja, har bevidst holdt CQRS-snakken ude af indlægget.

    Jeg stødte egentlig mest på det fordi at vi ønskede at hoste nogle ting på låsningsfri databaser (altså heller ikke optimistisk låsning). Da jeg så havde tænkt længe nok over de problemer der skulle løses så stod jeg tilbage med CQRS.

    Sjovt med sådan noget teknologi, der har eksisteret så længe – men man først selv er blevet rigtig klar til at indrage det nu.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *