Zum Hauptinhalt springen

Event Sourcing

Einleitung​

Event Sourcing speichert nicht den aktuellen Zustand eines Systems –
sondern jede Zustandsänderung als Ereignis.

Der aktuelle Zustand wird aus der Event-Historie rekonstruiert.

Das bedeutet:

Der Event-Stream ist die Quelle der Wahrheit.
Der State ist nur eine Ableitung.

Einordnung

Event Sourcing ist ein Persistenz-Pattern auf Applikationsebene.

Es beschreibt:

  • wie Zustand gespeichert wird
  • wie Aggregate rekonstruiert werden
  • wie Historie modelliert wird

Es ist:

  • kein Messaging-Pattern
  • kein Integrations-Pattern
  • kein Microservices-Pattern

Es wird häufig mit CQRS kombiniert, ist aber unabhängig davon.

Grundprinzip

Kernaussage:

  • Events sind dauerhaft
  • State ist rekonstruierbar
  • Projections sind abgeleitet

Zielsetzung

Event Sourcing adressiert:

  • vollständige Auditierbarkeit
  • Reproduzierbarkeit von Abläufen
  • zeitliche Queries („State zu Zeitpunkt X“)
  • flexible, spätere Read-Modelle

Nicht:

  • reine Performance-Optimierung
  • CRUD-Vereinfachung

Zentrale Konzepte

1️⃣ Aggregate als Konsistenzgrenze​

Ein Aggregate:

  • verarbeitet Commands
  • validiert Invarianten
  • erzeugt Events

Die Events repräsentieren:

fachliche Tatsachen, nicht technische Updates.

2️⃣ Append-Only Event Store​

  • Events werden niemals verändert
  • Nur neue Events werden hinzugefügt
  • Historie bleibt unverändert

Das macht das System:

  • nachvollziehbar
  • aber auch unveränderlich

3️⃣ Snapshots​

Bei langen Event-Streams:

  • Rekonstruktion wird teuer
  • Snapshots speichern Zwischenzustände
  • Events nach Snapshot werden re-applied

Snapshots sind Performance-Optimierung – keine Quelle der Wahrheit.

4️⃣ Versionierung​

Events sind Teil des öffentlichen Vertrags.

Änderungen erfordern:

  • Versionierung
  • Upcaster
  • Migration-Strategien

Event-Schema-Design ist kritisch.

Vorteile

  • Vollständiger Audit-Trail
  • Zeitliche Abfragen möglich
  • Replaying zur Fehleranalyse
  • Flexible Projektionen
  • Debugging durch Rekonstruktion

Risiken / typische Fallstricke

1️⃣ Hohe Modellierungsanforderungen​

Event Sourcing funktioniert nur gut, wenn:

  • Aggregate sauber geschnitten sind
  • Invarianten klar definiert sind
  • Events fachlich präzise sind

2️⃣ Event-Schema-Drift​

Schlecht versionierte Events führen zu:

  • Rebuild-Problemen
  • Kompatibilitätschaos

3️⃣ Komplexität​

Event Sourcing erhöht:

  • Entwicklungsaufwand
  • Testing-Aufwand
  • Betriebsaufwand

4️⃣ Falsche Motivation​

„Weil es modern ist“ „Weil wir Kafka haben“ „Weil wir CQRS machen“

Das sind keine validen Gründe.

Event Sourcing ≠ Event-Driven Architecture

Event Sourcing:

  • speichert interne Zustandsänderungen

EDA:

  • integriert Systeme über Events

Beide können kombiniert werden – sind aber unterschiedliche Konzepte.

Wann sinnvoll?

  • Hohe regulatorische Anforderungen
  • Finanzsysteme
  • Vertrags- oder Ledger-Systeme
  • Stark zeitabhängige Domänen
  • Hoher Bedarf an Audit und Replay

Wann Overkill?

  • CRUD-dominiert
  • Kleine Teams
  • Einfache Geschäftslogik
  • Keine Audit-Anforderungen

Varianten

🟢 Event Sourcing + CQRS​

Typische Kombination, aber nicht zwingend.

🟡 Event Sourcing ohne getrennte Read-DB​

Einfachere Variante.

🔴 Event Sourcing + Microservices​

Hohe Komplexität, nur bei Reife sinnvoll.

Strategische Perspektive

Event Sourcing verschiebt Komplexität:

Von:

  • komplizierten Migrationen
  • fehlender Historie

Zu:

  • Event-Design
  • Versionierung
  • Rebuild-Strategien

Es ist ein mächtiges Werkzeug – aber nur für reife Domänen.

Fazit

Event Sourcing speichert Geschichte statt Zustand.

Es ist sinnvoll, wenn:

  • Historie ein Kernbestandteil der Domäne ist
  • Audit nicht optional ist
  • langfristige Evolvierbarkeit entscheidend ist

Es ist kein Architektur-Statussymbol. Es ist ein bewusstes Persistenzmodell.