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:
-
Domain-Driven Design - Wird oft mit CQRS für komplexe Domänen kombiniert
-
Hexagonal Architecture - Ports und Adapter ergänzen die CQRS-Trennung
-
Fowler Patterns - CQRS baut auf Enterprise-Application-Patterns auf
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