Event Sourcing
Event Sourcing speichert Zustandsänderungen als geordnete Ereignisse. Der aktuelle Zustand wird durch Wiederabspielen dieser Historie aufgebaut.
- EreignisprotokollGeordnete Liste fachlicher Tatsachen
- AbspielenZustand aus Ereignissen neu berechnen
- Nur anhängenNichts überschreiben, nur ergänzen
Einordnung
Warum das wichtig ist
Wer nur den aktuellen Stand speichert, verliert die Herkunft: Wie kam die Bestellung zu diesem Wert? Event Sourcing hängt jede fachliche Änderung als Ereignis nur an; der Zustand entsteht durch Abspielen. Der Preis ist dauerhafter Mehraufwand. Für bloße Veröffentlichung gespeicherter Änderungen siehe Transactional Outbox.
Dieser Baustein erklärt Ereignisse als maßgeblichen Zustandsspeicher. Für bloße Veröffentlichung gespeicherter Änderungen siehe Transactional Outbox.
Auf einen Blick · Zustand aus Ereignisfolge
Zustand aus Ereignissen abspielen
Eine experimentelle Bestellkomponente speichert jede akzeptierte Änderung an B-1042 als Ereignis. Der übrige Shop bleibt ein modularer Monolith.
So liest du das Bild
- Ereignisprotokoll Die Zeilen v1 bis v4 im Protokoll der Bestellung
- Abspielen Der Regler wendet die Ereignisse bis zur Version an
- Nur anhängen Im CRUD-Modus überschreibt jede Änderung die Zeile; der Verlauf fehlt
Ereignisprotokoll · nur anhängen · Stream Bestellung B-1042
- v110:00BestellungAngelegt2 × Tasse
- v210:01BestandReserviertReservierung R-77
- v310:02ZahlungBestätigtZahlung eingegangen
- v410:04VersandFreigegebenLager darf versenden
Abgeleiteter Zustand
- Status
- versandbereit
- Positionen
- 2 × Tasse
- Reservierung
- R-77
- Zahlung
- bestätigt
Der Zustand wird aus den Ereignissen bis zur gewählten Version abgespielt; jeder frühere Stand bleibt jederzeit rekonstruierbar.
Zeiten illustrativ
Nutzen & Grenzen
Hilft, wenn
- Eine fachliche Ereignishistorie hält Änderungen nachvollziehbar fest und ermöglicht die Rekonstruktion des Zustandsverlaufs.
- Geordnete Ereignisse machen frühere Zustände zu einem bestimmten Zeitpunkt ableitbar.
- Getrennte Projektionen lesen denselben Verlauf für unterschiedliche Auswertungen.
Grenzen
- Mehraufwand ohne echten Historienbedarf: Replay, Versionierung und Aufbewahrung kosten dauerhaft; im Shop deshalb nur eine experimentelle Komponente.
- Lange Streams bremsen das Abspielen; Snapshots beschleunigen, bleiben aber abgeleitet.
- Löschen ist schwer: Ereignisse sind unveränderlich; plane Datenminimierung und Crypto Shredding vor dem Schemaentwurf.
In der Praxis
- Definiere Streamgrenze, Ereignisbedeutung und Reihenfolge dauerhaft. Speichere nur fachliche Tatsachen; technische Änderungen am Speicherformat gehören in eine kontrollierte Schemaentwicklung.
- Prüfe die erwartete Streamversion atomar beim Anhängen. Bei Konflikt wird der aktuelle Stand erneut geladen und die Änderung fachlich bewertet; Transaktionsgrenzen erklären lokale Atomarität.
- Versioniere Ereignisleser und teste Replay samt Kontrollwerten. Projektionen bleiben abgeleitete Lesemodelle; für deren Gestaltung siehe CQRS.
Ausführliche Erklärung lesen
Event Sourcing hält fachliche Zustandsänderungen als geordnete Ereignisse fest. Der gegenwärtige Zustand entsteht durch Anwendung der Ereignisse in ihrer Streamreihenfolge. Ein Schreibvorgang hängt neue Ereignisse nur an, wenn die erwartete Streamversion atomar noch gilt.
Abfragen verwenden oft Projektionen, die aus der Historie abgeleitet und neu aufgebaut werden können. Ereignisversionen, Reihenfolge und langfristige Lesbarkeit werden Teil des Datenvertrags. Historien können Datenschutz und Aufbewahrung anspruchsvoller machen als veränderliche Zustandsdatensätze.
CQRS kann Ereignisse in getrennte Lesemodelle projizieren, ist aber keine Voraussetzung für eine Ereignishistorie; Transaktionsgrenzen erklären das atomare Anhängen unter erwarteter Version.
Ein Snapshot ist ein gespeicherter Zwischenstand, ab dem weiter abgespielt wird, statt immer bei Ereignis 1 zu beginnen. Upcasting, ein Werkzeug der Versionierung, hebt alte Ereignisse beim Lesen auf das neue Schema, sodass sie lesbar bleiben. Crypto Shredding speichert Personendaten verschlüsselt und löscht bei Bedarf den Schlüssel; das ist eine Antwort auf die DSGVO-Löschpflicht trotz unveränderlicher Ereignisse.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Der Regler steht bei Version 2. Welchen Status und welche Reservierung hat B-1042?
Lösung mit Begründung ansehen
Status „angelegt“, Reservierung R-77. Zahlung ist noch nicht abgespielt, daher steht sie auf „—“.
AnwendenAuf eine neue Lage übertragen
Der Kunde ändert nach Version 4 die Menge auf 3 Tassen. Was passiert im Event Store?
Lösung mit Begründung ansehen
Ein neues Ereignis (Version 5) wird angehängt, etwa MengeGeändert. Die bisherigen Ereignisse bleiben unverändert; der Zustand ergibt sich beim Abspielen.
BewertenEine Alternative abwägen
Soll der ganze Shop auf Event Sourcing umstellen, weil die Historie nützlich ist?
Lösung mit Begründung ansehen
Nein, nicht pauschal. Vorteil: nachvollziehbarer Verlauf. Nachteil: Aufwand für Replay, Versionierung und Löschbarkeit. Empfehlung: nur dort einsetzen, wo der Verlauf fachlich gebraucht wird, wie in der experimentellen Bestellkomponente.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Martin Fowler · Event Sourcing (öffnet in neuem Tab)Beschreibt Ereignisprotokoll, Rekonstruktion und zeitbezogene Abfragen.
- Microsoft · Event Sourcing Pattern (öffnet in neuem Tab)Erklärt Ereignisspeicherung, Projektionen und Schemaentwicklung.
- Martin Fowler · What do you mean by Event-Driven? (öffnet in neuem Tab)Unterscheidet Ereignisbenachrichtigung, Zustandsübertragung und Event Sourcing.