Event Sourcing oder CRUD mit Historientabelle? Eine ehrliche Gegenüberstellung

Wenn Nachvollziehbarkeit gefordert ist, steht früh die Frage im Raum: Reicht eine Historientabelle, oder braucht es Event Sourcing? Die ehrliche Antwort lautet in der Mehrzahl der Fälle: Die Historientabelle reicht. Nur eben nicht in den Fällen, in denen sie nicht reicht — und die erkennt man vorher.

Was die Historientabelle leistet

Das Muster ist bekannt: Neben der Tabelle mit dem aktuellen Stand liegt eine zweite, in die jede Änderung als Kopie geschrieben wird, mit Zeitstempel und Nutzer. Meist per Datenbank-Trigger, damit nichts vergessen wird.

Das ist günstig, in Tagen umgesetzt, von jedem Entwickler verstanden und beantwortet die häufigste Frage zuverlässig: Wie sah dieser Datensatz am 3. März aus?

Wo sie bricht

Sie kennt das Warum nicht. Die Historie zeigt, dass der Rabatt von 5 % auf 12 % gesprungen ist. Ob das eine Freigabe durch den Vertriebsleiter, eine Rabattstaffel oder ein Fehler in einem Import war, steht nirgends. Im Audit ist genau das die Frage.

Sie kennt nur eine Tabelle. Ein Vorgang, der Auftrag, Position, Reservierung und Bonitätsprüfung berührt, hinterlässt vier unverbundene Zeilen in vier Historien. Der Vorgang selbst existiert nirgends.

Löschungen und Umbauten fressen sie. Ein Schema-Refactoring, eine Zusammenführung von Datensätzen, eine DSGVO-Löschung — danach ist die Historie lückenhaft, und zwar still.

Sie ist änderbar. Wer Schreibrechte auf die Datenbank hat, kann auch die Historie ändern. Für einen Prüfer ist das der entscheidende Einwand.

Was Event Sourcing anders macht

Nicht der Zustand wird gespeichert, sondern die Abfolge fachlicher Ereignisse: Auftrag erfasst, Rabatt freigegeben, Lieferung reserviert. Der aktuelle Stand ist daraus abgeleitet. Der Unterschied ist nicht technisch, sondern semantisch — das Ereignis trägt die fachliche Bedeutung und den Auslöser mit sich, die Historientabelle trägt nur das Ergebnis.

Der Preis ist real und sollte nicht kleingeredet werden: ein anderes Denkmodell im Team, Umgang mit abgeleiteten Sichten und deren Nachlauf, Versionierung von Ereignissen über Jahre, eine spürbare Lernkurve. Wer Event Sourcing dort einsetzt, wo eine Historientabelle reicht, zahlt Komplexität ohne Gegenwert.

Nebeneinander

Fünf Fragen, die die Entscheidung vorwegnehmen

1. Fragt jemand von außen — Auditor, Einkauf, Aufsicht — nach dem Grund einer Änderung, nicht nur nach dem Verlauf?
2. Überspannen die interessanten Vorgänge mehrere Entitäten?
3. Kommen regelmäßig Auswertungen auf, die man rückwirkend gern gehabt hätte?
4. Ist die Domäne stabil genug, dass sich ein Ereignismodell lohnt — oder ändert sich das Fachliche noch monatlich?
5. Gibt es im Team jemanden, der das nach unserer Übergabe trägt?

Dreimal Ja bei 1–3 spricht für Event Sourcing. Ein Nein bei 5 spricht dagegen, unabhängig vom Rest.

Der pragmatische Mittelweg

Man muss sich nicht global entscheiden. In fast jedem System gibt es eine kleine Zahl von Bereichen, in denen die Entscheidungen liegen, die im Prüfungsfall zählen: Freigaben, Preise, Berechtigungen, Vertragsstatus. Dort lohnt sich der Ereignisverlauf. Stammdaten, Konfiguration und Anzeigelogik bleiben klassisch. Das ist keine Kompromisslösung, sondern die meistens richtige Antwort.

Weiterlesen

• Event Sourcing: wann es sich lohnt
• Audit-Trail nachrüsten oder neu bauen
• Event Sourcing als Methodologie
• Nachweis-Check