CQRS (Command Query Responsibility Segregation) ist ein von Greg Young geprägtes Muster, das Bertrand Meyers Command Query Separation von Methoden auf Modelle überträgt: Schreiben und Lesen laufen über getrennte Modelle, jedes für seinen Zweck optimiert. Domain Events können Änderungen von der Schreibseite zu Lesemodell-Projektionen tragen; das Lesemodell darf dabei nachhinken, damit beide Seiten unabhängig skalieren. Event Sourcing ergänzt CQRS, ist aber nicht erforderlich.

CQRS (Command Query Responsibility Segregation)

Details
Auch bekannt als

CQS auf Architekturebene

Kernkonzepte:

Command Query Separation (CQS)

Bertrand Meyers Prinzip — Methoden ändern entweder den Zustand (Commands) oder geben Daten zurück (Queries), niemals beides

Commands

Schreiboperationen, die den Zustand ändern und void zurückgeben; repräsentieren Absichten als unveränderliche Command-Objekte

Queries

Leseoperationen, die Daten ohne Seiteneffekte zurückgeben; sicher wiederholbar und cachebar

Getrennte Lese-/Schreibmodelle

Unabhängige Datenmodelle, die für ihren jeweiligen Zweck optimiert sind

Eventual Consistency

Das Lesemodell kann hinter dem Schreibmodell zurückbleiben; akzeptabler Kompromiss für Skalierbarkeit

Ereignisbasierte Synchronisation

Domain Events propagieren Änderungen von der Schreibseite zu Lesemodell-Projektionen

Unabhängige Skalierbarkeit

Lese- und Schreibseite können unabhängig skaliert, deployt und optimiert werden

Event Sourcing optional

CQRS erfordert kein Event Sourcing; die Muster sind komplementär, aber unabhängig

Schlüsselvertreter

Greg Young (prägte CQRS), Bertrand Meyer (CQS-Ursprung, "Object-Oriented Software Construction", 1988), Udi Dahan

Wann zu verwenden:

  • Systeme mit asymmetrischer Lese-/Schreiblast

  • Komplexe Domänen, in denen Lese- und Schreibmodelle erheblich voneinander abweichen

  • Event-Sourced-Systeme, die materialisierte Views erfordern

  • Hochperformante Systeme, die unabhängige Skalierung von Lese- und Schreibzugriffen benötigen

  • Kollaborative Domänen mit aufgabenbasierten UIs

Verwandte Anker:

Kritik:

  • Martin Fowler, bliki: CQRS — warnt, dass "CQRS für die meisten Systeme riskante Komplexität hinzufügt", ein "erheblicher mentaler Sprung", der sich nur in bestimmten Bounded Contexts auszahlt, nicht als Default-Pattern

  • Udi Dahan, einer der Hauptvertreter von CQRS, eröffnet "When to avoid CQRS" (2011) mit "Most people using CQRS (and Event Sourcing too) shouldn’t have done so" — und ergänzt, CQRS "sollte nicht dein Top-Level-Architekturpattern sein"

  • Greg Young selbst trat dem Scope Creep entgegen in "CQRS is not an Architecture" (2012, archiviert): CQRS ist ein Pattern innerhalb einer einzelnen Komponente, kein Architekturstil für ein ganzes System