Um dies zu verdeutlichen, nehmen wir ein vereinfachtes Beispiel eines Unternehmens, das Daten über seine Mitarbeitenden führt. Bei Einstellung werden anfangs Daten wie die ID, der Vor- und Nachname, die Rolle und die Abteilung erfasst. Diese Informationen verändern sich im Lauf der Zeit, etwa wenn Angestellte befördert oder die Abteilung gewechselt werden. Herkömmlich wird bei einer Veränderung der entsprechende Datensatz aktualisiert, damit er den aktuellen Stand widerspiegelt. Dies ist zweckmässig für einfache Anforderungen.
Veränderungen an einem Datensatz führen zum Verlust der bisherigen Informationen.
Es kann vorkommen, dass Mitarbeitende mehrmals befördert werden oder Abteilungen wechseln. Wird der Datensatz aktualisiert, gehen alte Informationen verloren, obwohl sie für verschiedene Zwecke nützlich sein könnten. Es gibt jedoch Möglichkeiten, diese Informationen zu erhalten, bspw. durch eine Tabelle, die Veränderun- gen an den Daten protokolliert. Leider ist dieser Ansatz oft nicht ausreichend, da solche Anforderungen erst im Nachhinein gestellt werden. Als zentraler Bestandteil der Softwarearchitektur berücksichtigt Event Sourcing solche Anforderungen grund legend. Eine gründlichere Analyse unseres Beispiels zeigt, dass Zustandsänderungen aufgrund von fachlichen Ereignissen stattfi nden. Wenn man diese Ereignisse zeitlich ordnet, so erzählen sie eine Geschichte über die Veränderungen unserer Daten. So ist nicht nur der aktuelle Zustand einsehbar, es sind auch alle Zwischenzustände jederzeit rekonstruierbar. Was passiert nun, wenn anstelle des Zustands die Ereignisse, die zum Zustand führen, gespeichert werden?
Ereignisbasierte Datenspeicherung mit Event Sourcing
Event Sourcing ist ein Pattern, das eben diese Idee umsetzt. Zusammengehörige Events werden dabei an einen Event Stream angehängt. Die Events sind unveränderlich, während der Event Stream nur das Anhängen von Events am Ende erlaubt. Ein Event Store kümmert sich letztendlich um die Persistenz der Event Streams. Der Event Store ist dabei die primäre Datenquelle und bildet die Single Source of Truth.
Die Vorteile von Event Sourcing
1. No data left behind
Da Ereignisse nur angehängt werden, werden keine Informationen überschrieben. In unserem Beispiel gab es zwei Beförderungen: Anstatt durch Aktualisierungen Daten zu verlieren, wurden semantische Ereignisse gespeichert. Eine zusätzliche Protokollierung ist nicht erforderlich. Wir können nachträglich eine historische Liste der bisherigen Rollen und Abteilungen erstellen und dabei auch auf alle bisherigen Ereignisse zugreifen.
2. Datenhistorie erlaubt umfassende Analyse
Die Abbildung und Nachvollziehbarkeit der gesamten Historie erlaubt es, Rückschlüsse zu ziehen. Denn die fachliche Bedeutung von Ereignissen kann wertvolle Informationen liefern: Hat sich die Rolle durch eine Beförderung oder Änderungen am Unternehmensrollenmodell geändert? Wurde die Abteilung gewechselt oder unter einem neuen Namen geführt? Ausserdem bietet sich die Möglichkeit, sogenannte Temporal Queries durchzuführen: Wie viel Zeit vergeht im Durchschnitt zwischen zwei Rollenwechseln? Wie viele Mitarbeitende haben letztes Jahr die Abteilung gewechselt?
3. Höhere Transparenz
Wir können jederzeit einen vergangenen Zustand wiederherstellen, was sowohl für neue fachliche Anforderungen als auch für die technische Fehleranalyse von Interesse ist. Dadurch haben wir eine perfekte Nachvollziehbarkeit erhalten, die hervorragend den Anforderungen an einen Audit-Trail entspricht und Synchroni- sierungsprobleme vermeidet.
Event Sourcing und Command Query Responsibility Segregation ergänzen sich
Mit Command Query Responsibility Segregation (CQRS) lässt sich für Event Sourcing ein ergänzendes Pattern anwenden.
Es wird zwischen zustandsändernden und zustandslesenden Operationen unterschieden. Zustandsveränder nde Operationen werden als Commands bezeichnet und führen zu Events, welche durch Event Sourcing persistent gemacht werden. Diese Events werden mittels Projektionen in für Abfragen optimierte Modelle übersetzt. Zustandslesende Operationen hingegen werden als Queries bezeichnet und können effizient auf diese optimierten Modelle zugreifen. Diese Modelle werden bei der Projektion erzeugt und lassen sich effizient abfragen. Die Kombination von Event-Sourcing und CQRS ermöglicht hoch skalierbare Systeme. Nicht nur die Datenbank des Event-Stores und der projizierten Modelle lassen sich individuell skalieren, sondern auch die Schnittstellen für Commands und Queries sowie die Projektionen. Event Sourcing bringt jedoch auch Herausforderungen mit sich. Mit zunehmender Anzahl von Events steigt der Aufwand, einen Event Stream zu durchlaufen. Das Schneiden der Event Streams nach fachlichen Anforderungen, die Einführung von Snapshots und die Verwendung von CQRS sind dabei Lösungsvarianten. Änderungen, die nicht rückwärts kompatibel sind, erfordern die Migration von Event Streams. Und letztendlich ist die Lernkurve für Teams nicht zu unterschätzen. Dank Event Sourcing hören wir auf, Daten wegzuwerfen. Darüber hinaus erweist sich Event Sourcing als leistungsstarker und flexibler Ansatz zur Bewältigung von komplexen Anforderungen. Somit können nachhaltige, skalierbare und komplexe Softwaresysteme entwickelt werden, die nicht nur den aktuellen Anforderungen gerecht werden, sondern auch für zukünftige Herausforderungen gerüstet sind.
