Event Sourcing und CQRS: was sie bringen und was sie kosten

Worum es geht

Bei Event Sourcing ist das führende System ein Append-only-Log von Domänenereignissen („ArticleCreated“, „ProposalAccepted“); der aktuelle Zustand ist eine Projektion, die durch Replay des Logs aufgebaut wird. Command Query Responsibility Segregation (CQRS) verwendet unterschiedliche Modelle für das Schreiben und das Lesen, typischerweise ein normalisiertes Schreibmodell und denormalisierte Lesemodelle, die aus den Ereignissen aktualisiert werden.

Warum es wichtig ist

Das Ereignisprotokoll ist eine vollständige Prüfspur und erlaubt es, neue Lesemodelle nachträglich aufzubauen. Lesemodelle lassen sich für jede Abfrage massschneidern. Die Kosten sind real: schliessliche Konsistenz zwischen Schreib- und Leseseite, die Weiterentwicklung des Ereignisschemas, Replay-Zeit und ein Denkmodell, das die meisten Teams nicht eingeübt haben.

So wird es angewendet

• Event Sourcing dort einsetzen, wo die Historie selbst eine Anforderung ist (Buchhaltung, Audit, gemeinsames Bearbeiten) und wo Ereignisse die natürliche Sprache der Domäne sind.
• CQRS lokal halten: ein Bounded Context, ein Team, explizite Projektionen mit Skripten zum Neuaufbau.
• Ereignisse von Anfang an versionieren und Upcaster für alte Versionen schreiben.
• Für die meisten CRUD-Systeme ist ein einzelnes relationales Modell mit einem bescheidenen Änderungsprotokoll (wie es dieses Wiki dreissig Tage lang führt) einfacher und ausreichend.

Stolpersteine

Das Ereignisprotokoll wie einen Message Bus für andere Systeme zu behandeln. Bei jedem Start Millionen Ereignisse ohne Snapshots erneut abzuspielen. Das Muster für eine Domäne zu übernehmen, deren einzige Anforderung „speichern und abrufen“ lautet.