Was ist Event Sourcing?

|
Tobi hat mit euch in seinem Artikel Mittwald Inside: Ein neues Kundencenter? ein bisschen Buzzword-Bingo gespielt. Doch wisst ihr was unter den jeweiligen Begriffen zu verstehen ist? Falls nicht, aufgepasst: Ich möchte euch einige ebendieser erklären. Den Anfang macht Event Sourcing.

Kurz und einfach erklärt: Beim Event Sourcing wird nicht der aktuelle Stand der Daten gespeichert, sondern alle Events (Änderungen), die zu diesem Stand geführt haben.

Da dieser Satz aber keinen eigenen Blog-Artikel Wert wäre und ihr euch darunter womöglich noch nicht so viel  vorstellen könnt, möchte ich euch hier an einem Beispiel den Sinn und die Vorteile erläutern.

Daten als aktueller State

Wer immer den aktuellen Stand der Daten in einer Datenbank ablegt, beschränkt sich auf diesen State der Daten. Dabei ist es egal, ob eine klassische relationale Datenbank verwendet wird oder eine dokumentenbasierte NoSQL-Datenbank. Die aktuelle Wahrheit wird durch den aktuellen Stand der Daten definiert.

Mein Beispiel: Wir betrachten den Vorrat in unserem heimischen Kühlschrank.

Produkt  Anzahl Einheit
Butter500g
Käse750g
Spätzle1Pckg.

Kochen wir uns jetzt eine Portion Käsespätzle, so werden die Daten in der Tabelle um die benötigten Zutaten reduziert und wir erhalten folgende Anzahl der noch vorhandenen Daten:

Produkt  Anzahl  Einheit 
Butter400g
Käse300g
Spätzle0Pckg.

Jetzt kennen wir – und eventuelle Mitbewohner – nur noch diesen aktuellen Stand der Daten. Wir können nicht mehr herausfinden, wie diese Daten entstanden sind, ob es vorher mehr oder weniger war. Bei einem Einkauf würden die Werte dann natürlich wieder entsprechend erhöht.

Events als Wahrheit

Beim Event Sourcing sieht man aber nicht den gespeicherten Stand der Daten als Wahrheit an, sondern die Events, die diese Daten verändert haben. Man speichert also die Events plus ein paar Metadaten ab, beispielsweise den Zeitpunkt, zu dem das Event entstanden ist.

Das erste Event wäre für das o.g. Beispiel: Einkauf durchgeführt. Folgende Daten würden in dem Event stehen:

 

Produkt Anzahl Einheit
Butter500g
Käse750g
Spätzle1Pckg.

Das zweite Event wäre dann: Gericht gekocht

Gericht: Käsespätzle. Dafür würden diese Daten in dem Event stehen:

 

Produkt Anzahl Einheit
Butter100g
Käse450g
Spätzle1Pckg.

Hier wird – anders als beim klassischen Beispiel – die Änderung abgespeichert. Im ersten Beispiel waren noch   300g Käse verfügbar. Hier wird gespeichert, dass wir 450g Käse verbraucht haben.

Da wir jetzt über den aktuellen Stand der Daten noch nichts wissen, sollten wir uns anhand der Events ein sogenanntes Read-Model aufbauen. Hierbei legen wir die Daten in dem für uns optimalen Format ab. Das kann z. B. der aktuelle Vorrat sein. Es werden dabei nach und nach alle Events auf das Read-Model angewendet (Replay genannt) und je nach Bedarf verarbeitet. Bei dem Event Einkauf durchgeführt werden die Einträge zum Vorrat hinzugefügt, beim Event Gericht gekocht abgezogen. So haben wir am Ende in unserem Read-Model den gleichen Stand, wie im klassischen Ansatz – aber auch noch einiges mehr.

Die Vorteile von Event Sourcing

Änderungsprotokoll

Durch das Speichern der Events bekommen wir quasi ein Änderungsprotokoll direkt geschenkt. Vor allem bei Business-Anwendungen kann das ein entscheidender Vorteil sein.

Read-Model kann optimal angepasst werden

Das Read-Model, das wir uns beim Replay aufbauen, kann immer optimal auf die Art der Anfragen angepasst sein, die wir darauf ausführen wollen. Da wir zu jedem Zeitpunkt – die Historie liegt ja vor – beliebige Read-Models neu aufbauen können, ist es möglich, jede Abfrage sehr effizient zu gestalten. Wir können das Read-Model entweder in einer Datenbank, im Filesystem oder auch In-Memory ablegen.

Flexibler Umgang mit Daten

Außerdem haben wir die Möglichkeit, jederzeit neue Read-Models aus den Events zu entwickeln – auch solche, die am Anfang gar nicht vorgesehen waren. Beim klassischen Modell von oben hätten wir im Nachhinein keine Möglichkeit herauszufinden, wie viel Käse monatlich verbraucht würde. Wir müssten eine entsprechende Tabelle anlegen und in Zukunft befüllen. Beim Event Sourcing können wir einfach ein Replay starten und anhand der Metadaten die Statistik aufbauen.

Oder wir wollen wissen, welche Gerichte besonders beliebt waren und welche vielleicht gar nicht gegessen wurden? Auch das ist mit den vorhandenen Events kein Problem. Für einen Restaurant-Betreiber eine durchaus interessante Information, vielleicht ja sogar nach Saison aufgeschlüsselt. ;-) Will heißen: Ihr werdet viel flexibler im Umgang mit den Daten und Erweiterungen werden vereinfacht.

Die Beteiligten erarbeiten den Anwendungsbereich

Ein weiterer Vorteil, der oft übersehen wird: Das System wird durch die tatsächlichen Events des abgegrenzten Anwendungsbereiches (Domäne), in dem wir uns befinden, modeliert. Beispielsweise kann das System in einer Event-Sourcing-Session entworfen werden, bei der die jeweilige Domäne mit allen Beteiligten erarbeitet wird. Gerade bei großen Softwareprojekten mit vielen Stakeholdern sehr effizient.

Datenspeicherung neu gedacht

Event Sourcing verlangt in Bezug auf das Speichern von Daten eine neue Art des Denkens. Gerade, dass man im ersten Schritt nicht die Daten abspeichert, die man für seine Abfragen benötigt, ist zu Beginn etwas gewöhnungsbedürftig. Man erhält dadurch aber viele Vorteile, die man mit der Zeit immer mehr zu schätzen weiß. Die Umgewöhnung lohnt sich also – insbesondere, wenn zu Beginn noch nicht ganz klar ist, welche Datenabfragen in Zukunft benötigt werden. Und wir wissen doch alle, dass Anforderungen sich im Projektzeitraum gerne mal ändern. ;-)

Ähnliche Artikel:

Webentwicklung

AppImage, Flatpak und Snap: Was können die alternativen Paketformate?

Entwickler Fabian nimmt im Blog die alternativen Paketformate AppImage, Flatpak und Snap unter die Lupe. Welche Vor- und Nachteile sie haben, liest du hier.

Webentwicklung

Tool-Tipp: Sequel Pro wird zu Sequel Ace

Sequel Pro wird seit einiger Zeit nicht mehr weiterentwickelt. Doch die Community schläft nicht: Der Fork Sequel Ace steht bereit! Mehr dazu im Blog.

Webentwicklung

Warum Git-Repositories auf dem Server keine gute Idee sind

Git-Repositories auf dem Server können zur Sicherheitslücke werden. Wie du das umgehen kannst, erklärt dir Lukas im Blog.