Event sourcing

Definition

I en almindelig database overskrives værdien, når noget ændres. Du sidder tilbage med nutilstanden og har mistet vejen dertil. Event sourcing vender det om: hændelserne er sandheden, og nutilstanden er noget, du regner dig frem til ved at afspille dem i rækkefølge. Intet overskrives, og loggen kan læses igen.

Det giver tre egenskaber, der er svære at eftermontere. Du kan genskabe tilstanden på et hvilket som helst tidspunkt. Du har et revisionsspor uden at bygge det som en selvstændig mekanisme, fordi loggen ER sporet. Og du kan køre historikken gennem ny logik, altså afspille det, der skete, mod en model, der ikke fandtes dengang.

I praksis

I kraftbranchen findes mønsteret allerede, om end ikke altid under dette navn. Måleværdier korrigeres bagefter: en estimeret værdi erstattes af en aflæst, og en aflæst kan erstattes af en korrigeret. Afregningen, der blev lavet sidste måned, skal stadig kunne forklares ud fra det, man vidste dengang, ikke ud fra det, man ved nu. Derfor er versionerede tidsserier og sporbarhed et krav i VEE-arbejdet, og det er det samme problem, event sourcing løser. Den almindelige løsning på det samme problem er ikke event sourcing, men versionerede tidsserier i en tidsseriedatabase: hver værdi får en version, og den gamle bliver stående. Det løser sporbarheden uden at lægge om på, hvordan systemet lagrer tilstand. Event sourcing går videre ved at gøre hændelserne til den eneste kilde. Den mest håndgribelige gevinst er afspilning. Får du en ny model til tilstandsvurdering, kan du køre flere års faktiske hændelser gennem den og se, om den ville have fanget et havari, der skete. En database, der kun har nutilstanden, kan ikke svare på det spørgsmål.

Foreslå ændring

Definition

I praksis

Se også:

Du vil måske også synes om