Event Sourcing oder traditionelles Modell: So entscheiden Sie, was als Wahrheitsquelle dient

Die Entscheidung, wie die Daten einer Anwendung gespeichert werden, ist nicht nur eine Frage der Speicherung. Sie bestimmt, was sich rekonstruieren lässt, wie Änderungen erklärt werden können und wie viel Aufwand die Wartung des Systems erfordert. Event Sourcing speichert eine Folge von Ereignissen als Wahrheitsquelle; ein traditionelles Modell hält in der Regel den aktuellen Zustand fest und bei Bedarf zusätzlich eine Historie.

Keine der beiden Optionen ist in allen Fällen überlegen. Entscheidend ist, wann die vollständige Historie und die Möglichkeit zur Rekonstruktion genug Nutzen bieten, um eine anspruchsvollere Architektur zu rechtfertigen. Dieser Leitfaden schlägt praktische Kriterien für die Entscheidung vor, zeigt einfachere Alternativen auf und empfiehlt einen kontrollierten Einstieg.

Was Event Sourcing bedeutet und worin es sich vom traditionellen Modell unterscheidet

Beim Event Sourcing protokolliert die Anwendung bereits eingetretene Geschäftsvorfälle, etwa BestellungErstellt, ZahlungBestätigt oder AdresseAktualisiert. Der aktuelle Zustand entsteht, indem diese Ereignisse der Reihe nach angewendet werden. Statt eine Zeile mit dem neuesten Wert zu überschreiben, bleibt eine Folge erhalten, die beschreibt, wie sich eine Entität entwickelt hat.

In einem traditionellen Modell enthält die Datenbank üblicherweise die aktuelle Version, zum Beispiel den gegenwärtigen Status und den Betrag einer Bestellung. Bei einer Aktualisierung werden frühere Werte ersetzt. Wenn nachvollziehbar sein muss, wer einen Wert wann geändert hat oder welchen Wert er zuvor hatte, lässt sich ein Audit-Protokoll oder eine separate Änderungshistorie ergänzen.

Der entscheidende Unterschied besteht nicht darin, dass der eine Ansatz eine Historie besitzt und der andere nicht. Entscheidend ist, welcher Datensatz maßgeblich ist. Beim Event Sourcing sind die Ereignisse die Wahrheitsquelle; aktuelle Ansichten werden daraus abgeleitet. Im traditionellen Modell ist der gespeicherte Zustand meist maßgeblich. Eine vorhandene Historie erfüllt dann eine zusätzliche Funktion.

Beginnen Sie beim Problem, nicht bei der Architektur

Klären Sie vor der Entscheidung, welche konkrete Geschäftsfrage Sie heute nicht beantworten können. „Wir wollen mehr Nachvollziehbarkeit“ ist zu allgemein. „Wir müssen rekonstruieren können, welche Entscheidungen den Kontostand zu einem bestimmten Zeitpunkt ergeben haben“ beschreibt hingegen einen überprüfbaren Bedarf. Diese Präzisierung ermöglicht einen Lösungsvergleich, ohne eine Architektur nur wegen ihrer technischen Attraktivität einzuführen.

• Historie: Frühere Änderungen müssen abrufbar sein, der gesamte Zustand muss aber nicht zwingend rekonstruierbar sein. Ein Audit-Protokoll kann genügen.
• Rekonstruktion: Der Zustand soll anhand gespeicherter Fakten neu berechnet werden können, etwa um eine Geschäftsregel zu korrigieren oder eine historische Situation zu analysieren.
• Nachvollziehbarkeit: Es ist wichtig zu erklären, was in welcher Reihenfolge geschehen ist. Dafür können Geschäftsereignisse oder eine eigens dafür entwickelte Historie dienen.
• Aktuelle Abfragen: Die meisten Ansichten benötigen lediglich den gegenwärtigen Zustand. Ein traditionelles Modell kann dafür einen direkteren Weg bieten.

Prüfen Sie außerdem, ob die Anforderung dauerhaft und zentral für das Produkt ist oder nur einen einzelnen Prozess betrifft. Event Sourcing ist besonders sinnvoll, wenn die Abfolge von Änderungen zum Kern der Domäne gehört – nicht allein dann, wenn jemand „alles speichern“ möchte.

Praktische Entscheidungskriterien

Bewerten Sie jedes Kriterium anhand konkreter Beispiele aus der Domäne. Nicht alle müssen für Event Sourcing sprechen. Wichtig ist, dass klar ist, welche Anforderung die Entscheidung vorantreibt.

• Änderungen haben eine eigene Bedeutung: „Reservierung bestätigt“ oder „Erstattung genehmigt“ sind relevante Fakten und nicht bloß Änderungen an Feldern. Das spricht für explizit modellierte Ereignisse.
• Eine Rekonstruktion ist erforderlich: Das Unternehmen muss frühere Zustände erneut ermitteln oder sie mit neuen Regeln berechnen können. Wenn lediglich die jüngsten Änderungen angezeigt werden sollen, kann eine Historie ausreichen.
• Die Reihenfolge ist wichtig: Die Abfolge der Aktionen bestimmt das Ergebnis, und das Team muss sie zuverlässig festhalten.
• Es gibt mehrere Ansichten desselben Prozesses: Verschiedene Teams oder Funktionen müssen dieselben Fakten auf unterschiedliche Weise abfragen. Projektionen können solche Lesezugriffe bedienen, verursachen jedoch zusätzlichen Aufwand.
• Die Domäne kennt Korrekturen und Ausnahmen: Diese müssen als neue Fakten – etwa als Korrektur oder Rücknahme – dargestellt werden, ohne das Geschehene stillschweigend zu löschen. Die Bedeutung jedes Ereignisses muss sorgfältig festgelegt werden.

Beschränkt sich der Bedarf darauf, Datensätze zu aktualisieren und ihre aktuelle Version abzufragen, ist das traditionelle Modell wahrscheinlich einfacher. Muss die Historie vollständig, verständlich und zur Ableitung von Zuständen nutzbar sein, verdient Event Sourcing eine genauere Prüfung.

Kosten, Risiken und Gründe gegen den Einsatz

Das Speichern von Ereignissen beseitigt Komplexität nicht, sondern verlagert sie. Lesezugriffe hängen häufig von Projektionen ab, also von abgeleiteten Ansichten, die anhand der Ereignisse aktualisiert werden. Werden sie asynchron verarbeitet, kann eventuelle Konsistenz auftreten: Für eine gewisse Zeit spiegelt eine Abfrage einen früheren Zustand wider. Das Produkt muss diese Verzögerung tolerieren oder festlegen, wie sie angezeigt und gehandhabt wird.

Gespeicherte Ereignisse lassen sich außerdem nicht wie gewöhnliche Datenbankzeilen bearbeiten. Ändert sich die Domäne, muss entschieden werden, wie alte Ereignisse interpretiert werden, wie sich ihre Formate weiterentwickeln und wie Projektionen erneut aufgebaut werden. Ebenso braucht es Verfahren, um Verarbeitungsfehler zu erkennen, Ereignisse bei Bedarf sicher erneut abzuspielen und Betrieb sowie Support sicherzustellen. Eine unvollständige oder unklar definierte Ereignisfolge kann genau die angestrebte Rekonstruktion beeinträchtigen.

Event Sourcing sollte verworfen oder aufgeschoben werden, wenn das Team nicht erklären kann, welche Ereignisse Geschäftsfakten darstellen, wenn die benötigten Abfragen einfach sind oder wenn keine Rekonstruktion erforderlich ist. Ein Warnsignal ist auch, wenn als Hauptargument lediglich „Auditierbarkeit“ genannt wird, ohne Anforderungen an historische Abfragen, Aufbewahrung oder die Nutzung des Protokolls. In solchen Fällen kann eine gut entworfene Historientabelle das Ziel mit weniger Komponenten erreichen.

Hypothetisches Beispiel: Bestellungen mit Änderungen und Korrekturen

Stellen wir uns eine Anwendung zur Verwaltung von Bestellungen vor. Das Team muss den aktuellen Status, Betrag und die Lieferadresse anzeigen. Ein traditionelles Modell mit Bestelldaten und einer Änderungshistorie kann ausreichen, wenn es darum geht, die aktuelle Version abzufragen und jüngste Änderungen zu erklären.

Anders sieht es aus, wenn das Unternehmen rekonstruieren muss, wie der Betrag zustande kam, Bestätigungen von Korrekturen unterscheiden und historische Situationen anhand neuer Regeln neu berechnen möchte. Event Sourcing könnte Fakten wie „Bestellung erstellt“, „Zahlung bestätigt“ und „Betrag korrigiert“ speichern. Die Bestellansicht würde aus dieser Folge abgeleitet. Dabei müsste jedoch festgelegt werden, wie eine Korrektur dargestellt wird, wie mit alten Ereignissen umzugehen ist und welche Abfragen vorübergehend veraltete Daten anzeigen dürfen.

Das Beispiel bedeutet nicht, dass jeder Bestellprozess Event Sourcing benötigt. Die Entscheidung hängt von überprüfbaren Anforderungen ab: Welche Rekonstruktion ist vorgeschrieben, wer fragt die Historie ab und welchen Komplexitätsgrad kann das Team zuverlässig betreiben?

Prüffragen vor der Einführung von Event Sourcing

1. Welche konkrete Frage lässt sich mit dem aktuellen Zustand und einer einfachen Historie nicht beantworten?
2. Welche Entitäten oder Prozesse müssen rekonstruiert werden, und zu welchem geschäftlichen Zweck?
3. Beschreiben die Ereignisse Fakten mit stabiler Bedeutung oder bilden sie lediglich technische Feldänderungen ab?
4. Welche Ansichten müssen gepflegt werden, wer verwendet sie und welche Verzögerung ist akzeptabel?
5. Wie werden Korrekturen, doppelte Ereignisse, Formatänderungen und erneute Verarbeitungen behandelt?
6. Wer ist für die Überwachung der Projektionen und die Behebung von Verarbeitungsfehlern verantwortlich?
7. Gibt es eine einfachere Alternative, die die aktuellen Anforderungen erfüllt, ohne künftige Optionen auszuschließen?

Begrenzen Sie den Einstieg und überprüfen Sie die Entscheidung

Wenn die Anforderungen Event Sourcing rechtfertigen, begrenzen Sie die Einführung zunächst auf einen Prozess, dessen Historie einen klaren Nutzen hat. Legen Sie gemeinsam mit den Verantwortlichen der Domäne zuerst das Ereignisvokabular fest und vereinbaren Sie, was jedes Ereignis garantiert: Was ist geschehen, welche Daten werden zu seiner Interpretation benötigt und was darf sich danach nicht mehr ändern? Entwerfen Sie außerdem die wichtigsten Abfragen und die Wiederherstellung von Projektionen, bevor Sie den Umfang erweitern.

Halten Sie die Entscheidungen fest und überprüfen Sie die Architektur, wenn sich die Anforderungen ändern. Benötigt das Produkt keine Rekonstruktion mehr oder übersteigt der Wartungsaufwand für Projektionen ihren Nutzen, kann eine Vereinfachung sinnvoll sein. Entstehen neue Anforderungen an Nachvollziehbarkeit und Analyse, reicht eine herkömmliche Historie womöglich nicht mehr aus. Die beste Wahl erfüllt reale Anforderungen und lässt sich vom Team zuverlässig betreiben – nicht diejenige, die vorsorglich die meisten Mechanismen anhäuft.