CQRS & Event Sourcing

CQRS (Command Query Responsibility Segregation) und Event Sourcing gehören zu den meistdiskutierten Architekturkonzepten im DDD-Umfeld.

Richtig eingesetzt lösen sie sehr konkrete Probleme. Falsch eingesetzt erzeugen sie Komplexität ohne Mehrwert.

Wann CQRS & Event Sourcing relevant sind

CQRS und Event Sourcing sind keine Standard-Architektur.

Sie entfalten ihren Nutzen vor allem in spezifischen Situationen, zum Beispiel wenn:

  • komplexe fachliche Abläufe korrekt nachvollzogen werden müssen
  • Anforderungen an Nachvollziehbarkeit oder Historisierung bestehen
  • hohe Änderungsfrequenz in der Domänenlogik vorliegt
  • unterschiedliche Lese- und Schreibanforderungen existieren
  • fachliche Ereignisse zentraler Bestandteil des Systems sind

In vielen Systemen sind diese Voraussetzungen nicht gegeben und das ist völlig in Ordnung.

Was CQRS & Event Sourcing leisten und was nicht

CQRS & Event Sourcing leisten:

  • klare Trennung von Schreib- und Leseverantwortung
  • explizite Modellierung fachlicher Ereignisse
  • hohe Flexibilität bei der Weiterentwicklung von Read-Modellen
  • sehr gute Nachvollziehbarkeit fachlicher Zustände

CQRS & Event Sourcing leisten nicht:

  • automatisch bessere Architektur
  • geringere Komplexität
  • einfachere Systeme
  • weniger Betriebsaufwand

Diese Konzepte verlagern Komplexität, beseitigen sie jedoch nicht.

CQRS und Event Sourcing getrennt denken

CQRS und Event Sourcing werden häufig gemeinsam genannt, sind aber konzeptionell unabhängig.

  • CQRS trennt Lese- und Schreibmodelle
  • Event Sourcing speichert Zustandsänderungen als Ereignisse

Beides kann kombiniert werden. Muss es aber nicht. In der Praxis kann es sinnvoll sein, diese Konzepte schrittweise und selektiv einzusetzen.

Architektonische Konsequenzen

Der Einsatz von CQRS und Event Sourcing hat weitreichende Auswirkungen auf:

  • Datenmodelle und Persistenz
  • Konsistenzmodelle und Erwartungen
  • Fehlerbehandlung und Debugging
  • Betrieb, Monitoring und Support
  • Teamverständnis und Wissensverteilung

Diese Konsequenzen müssen bewusst getragen werden, technisch wie organisatorisch.

Typische Fehlannahmen

In der Praxis begegnen mir häufig folgende Annahmen:

  • «CQRS & Event Sourcing sind Best Practice für Microservices.»
  • «Event Sourcing löst unsere Datenprobleme.»
  • «Wir brauchen das für Skalierung.»
  • «DDD bedeutet automatisch Event Sourcing.»

Diese Annahmen führen oft zu Architekturen, die schwer erklärbar und schwer wartbar sind.

Weiterführende Schritte

Je nach Fragestellung können CQRS & Event Sourcing sinnvoll vertieft werden durch:

Wenn Sie überlegen, CQRS oder Event Sourcing einzusetzen, lohnt sich fast immer eine bewusste Vorab-Einordnung.

Erstgespräch buchen