Event sourcing

Definisjon

I en vanlig database overskrives verdien når noe endres. Du sitter igjen med nåtilstanden og har mistet veien dit. Event sourcing snur det: hendelsene er sannheten, og nåtilstanden er noe du regner deg fram til ved å spille dem av i rekkefølge. Ingenting overskrives, og loggen kan leses om igjen.

Det gir tre egenskaper som er vanskelige å ettermontere. Du kan gjenskape tilstanden på et hvilket som helst tidspunkt. Du har et revisjonsspor uten å bygge det som en egen mekanisme, fordi loggen ER sporet. Og du kan kjøre historikken gjennom ny logikk, altså spille av det som skjedde med en modell som ikke fantes den gang.

I praksis

I kraftbransjen finnes mønsteret allerede, uten at det alltid heter dette. Måleverdier korrigeres i etterkant: en verdi som var estimert erstattes av en avlest, og en avlest kan erstattes av en korrigert. Avregningen som ble gjort forrige måned må likevel kunne forklares ut fra det man visste da, ikke ut fra det man vet nå. Derfor er versjonerte tidsserier og sporbarhet et krav i VEE-arbeidet, og det er det samme problemet event sourcing løser. Den vanlige løsningen på det samme problemet er ikke event sourcing, men versjonerte tidsserier i en tidsseriedatabase: hver verdi får en versjon, og den gamle blir stående. Det løser sporbarheten uten å legge om hvordan systemet lagrer tilstand. Event sourcing går lenger, ved å gjøre hendelsene til den eneste kilden. Den mest håndfaste gevinsten er avspilling. Får du en ny modell for tilstandsvurdering, kan du kjøre flere år med faktiske hendelser gjennom den og se om den ville fanget opp en svikt som skjedde. En database som bare har nåtilstanden kan ikke svare på det spørsmålet.

Foreslå endring

Definisjon

I praksis

Se også:

Kan også interessere deg