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:

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.