Event Sourcing und CQRS

Kurz: Beim Event Sourcing speichert man nicht den aktuellen Zustand, sondern alle Ereignisse, die dazu geführt haben. CQRS trennt das Schreiben (Commands) vom Lesen (Queries).

Genauer: Der Zustand ergibt sich, indem man die Ereignisse nacheinander abspielt. Das liefert vollständige Historie und Nachvollziehbarkeit. Für schnelle Abfragen baut man aus den Ereignissen separate Lesemodelle (Projektionen).

Im Detail

• Ereignis: Unveränderliche Tatsache in Vergangenheitsform („BestellungAufgegeben“).
• Snapshot: Zwischenstand, um nicht immer alles abspielen zu müssen.
• CQRS: Eigenes Schreibmodell und eigene, optimierte Lesemodelle.
• Vorteile: Audit-Trail, Zeitreisen, Neuberechnung, gute Skalierung der Lesezugriffe.
• Nachteile: Komplexität, Eventual Consistency zwischen Schreib- und Lesemodell, Versionierung von Ereignissen.
• Wann: Nur bei Bedarf an Historie oder starker Last-Trennung, nicht als Standard.

Siehe auch: Verteilte Transaktionen: Zwei-Phasen-Commit und Saga, Domain-Driven Design