Was ist 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.

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.

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:

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.

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.

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.

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

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.

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.

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.

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. ;-)