Kennen Sie das Gefühl, wenn Sie eine Software entwickeln und kaum ist sie fertig, kommen schon die ersten Änderungswünsche? Neue Funktionen, komplexere Analysen, mehr Reports – und oft fehlen die richtigen Daten oder die Code-Anpassungen sind aufwendiger als erwartet. Das Resultat: Frust bei Ihnen und Ihren Anwendern.
Was wäre, wenn es eine Möglichkeit gäbe, Software so zu entwickeln, dass Änderungen und Erweiterungen deutlich einfacher und flexibler möglich sind? Genau darum geht es in diesem Artikel: Wir betrachten, warum viele Systeme für diese Herausforderungen nicht gerüstet sind und wie wir es besser machen können.
Das Problem mit dem Status Quo
Egal, ob Sie einen Monolithen, ein Client-Server-System oder eine verteilte Service-basierte Anwendung entwickeln – eines bleibt in der Regel gleich: die Datenhaltung. Ob relationale Datenbank, NoSQL-Datenbank oder File Storage, alle speichern in der Regel den Status quo.
Nehmen wir einen Fahrradverleih als Beispiel: Für jedes Fahrrad wird ein Datensatz angelegt, der bei Ausleihe, Verlängerung oder Rückgabe aktualisiert und bei Aussortierung gelöscht wird. Das erscheint logisch, ist aber nicht immer sinnvoll.
CRUD und seine Tücken
Diese Art der Datenhaltung wird oft als "CRUD" bezeichnet: Create, Read, Update, Delete. Egal, ob PostgreSQL, Microsoft SQL Server, MongoDB oder Redis – das Konzept ist dasselbe.
CRUD funktioniert seit Jahrzehnten, hat aber auch Schattenseiten:
-
Löschen ist riskant: Gelöschte Daten sind unwiederbringlich weg. Oft wird stattdessen ein IsDeleted-Flag eingeführt, um das Löschen rückgängig zu machen.
-
Fachliches vs. technisches Denken: Ein "Delete" in der Datenbank kann fachlich unterschiedliche Vorgänge bedeuten (z. B. ein gestohlenes vs. ein aussortiertes Fahrrad).
-
Missverständnisse: Unterschiedliche sprachliche Ebenen (fachlich, technisch, intentionell) führen zu Missverständnissen zwischen Fachabteilung und Entwicklern.
Herausforderungen im Fahrradverleih
Stellen Sie sich vor, der Fahrradverleih möchte eine Analyse darüber, wie oft Fahrräder nach mehrfacher Verlängerung verspätet zurückgegeben werden und welche Routen diese Fahrräder typischerweise zurücklegen. Mit einem traditionellen CRUD-Ansatz wären solche Informationen schwer zu erfassen und würden umfangreiche Anpassungen am Datenmodell und der Anwendungslogik erfordern.
Das Girokonto-Prinzip
Ein besseres Beispiel ist ein Girokonto: Die Bank speichert nicht nur den Kontostand, sondern jede einzelne Transaktion. So kann nachvollzogen werden, wie der Kontostand zustande gekommen ist.
Die Bank verzichtet auf Delete und Update. Stattdessen wird für jede Transaktion ein neuer, unveränderlicher Eintrag erzeugt (Create). Der Kontoauszug ist das Ergebnis von Read-Operationen über diese Liste.
Fehlerhafte Transaktionen werden nicht korrigiert, sondern durch Gegentransaktionen kompensiert.
Vorteile von Event Sourcing
Dieses Modell hat enorme Vorteile:
-
Simples Datenmodell: Nur Create und Read.
-
Alle Rohdaten vorhanden: Sämtliche Fragen können beantwortet werden, auch solche, die vorher nicht bekannt waren.
-
Ad-hoc-Analysen: Analysen können ad hoc über sämtliche Daten der Vergangenheit durchgeführt werden.
-
Flexibilität: Keine Anpassung des Datenmodells oder des Codes für neue Anforderungen.
Verallgemeinerung
Dieses Prinzip lässt sich auf viele Bereiche übertragen. Im Fahrradverleih werden nicht die Fahrraddatensätze aktualisiert, sondern Ereignisse wie "Fahrrad aufgenommen", "Fahrrad ausgeliehen", "Fahrrad zurückgegeben" gespeichert. Daraus lassen sich vielfältige Analysen ableiten, wie beispielsweise Nutzungsmuster, Wartungszyklen oder beliebte Routen.
Der nächste Schritt: CQRS
Event Sourcing wird oft in Kombination mit CQRS (Command Query Responsibility Segregation) eingesetzt. CQRS trennt die Verantwortlichkeiten für das Schreiben (Commands) und Lesen (Queries) von Daten. Dadurch können komplexe Systeme effizienter gestaltet werden, indem das Schreiben von Daten durch Event Sourcing und das Lesen durch spezialisierte Read-Modelle erfolgt. Dies ermöglicht eine bessere Skalierbarkeit und Flexibilität, da die Lasten von Schreib- und Lesezugriffen getrennt werden können.
Fazit
Event Sourcing ist mehr als nur eine Datenbankstrategie. Es ist ein Paradigmenwechsel, der zu flexibleren, anpassungsfähigeren und verständlicheren Systemen führt. Es ermöglicht, auf neue Anforderungen schnell zu reagieren und die Vergangenheit neu zu interpretieren.
Interessanterweise ist Event Sourcing kein neues Konzept: Bereits John Carmack setzte es bei der Entwicklung des Kultspiel Doom ein, um Demospiele und Debugging zu ermöglichen. Natürlich war es damals noch nicht unter diesem Namen bekannt, aber das Prinzip war das Gleiche.
Wenn Sie mehr über Event Sourcing, CQRS und moderne Domänenmodellierung mit KI erfahren möchten, empfehlen wir Ihnen unseren Kurs Moderne Architekturen. Dort tauchen wir tiefer in diese zukunftsweisenden Konzepte ein und zeigen, wie sie die Softwareentwicklung revolutionieren können.