Softwareentwicklung: Lese- und Schreibmodelle gezielt trennen - CQRS mit Augenmaß
Viele Anwendungen beginnen mit einem gemeinsamen Datenmodell: Eine Entität dient gleichzeitig als Persistenzobjekt, Eingabemodell und JSON-Antwort, beispielsweise eine Entität für Reservierungen. Für überschaubare CRUD-Funktionen (Create, Read, Update, Delete) ist das vernünftig. Schwierigkeiten entstehen, sobald Lesen und Schreiben gegensätzliche Anforderungen stellen. Beim Schreiben soll das Modell fachliche Regeln schützen: Es darf ein belegtes Zimmer nicht erneut vergeben. Dafür braucht die Schreibseite das Verhalten, Transaktionen und Konflikterkennung. Eine Suchseite möchte dagegen Name, Zeitraum, Preis und Status mit einer schnellen Abfrage anzeigen. Sie braucht dafür weder das vollständige Aggregat noch dessen Methoden.
Das Architekturmuster Command Query Responsibility Segregation (CQRS) trennt das Modell für Zustandsänderungen vom Modell für Ausgaben. Commands formulieren eine Absicht und können einen fachlichen Zustand verändern. Queries liefern Daten, verändern dabei aber nicht den für Aufrufer beobachtbaren fachlichen Zustand. Interne Effekte wie Telemetrie oder das Befüllen eines Cache bleiben möglich, solange sie das fachliche Ergebnis der Abfrage nicht beeinflussen. So entstehen zwei spezialisierte Sichten auf dieselben fachlichen Informationen(öffnet im neuen Fenster). Wir zeigen anhand eines ausführlichen .NET-Beispiels, wann es sinnvoll ist.