CQRS: Anwendungsfälle

Inhaltsverzeichnis

1. Einleitung
2. Vorteile von CQRS
3. Anwendungsfälle
4. Wann sollte man CQRS besser nicht benutzen?
5. Zusammenfassung

Einleitung

CQRS (Command Query Responsibility Segregation) ist ein Architekturkonzept, welches darauf basiert, dass Operationen, welche den Datenzustand verändern (Create, Update), separat von den lesenden Operationen sind. Die Modelle zum Lesen und Schreiben sind also voneinander getrennt. Zuerst gab es den Begriff „Command Query Separation“ (CQS) von Bertrand Meyer aus seinem Buch „Objektorientierte Softwareentwicklung“. Die Grundidee besteht darin, dass die Systemvorgänge in zwei vollständig getrennte Kategorien aufgeteilt werden:

• Abfragen: Diese Abfragen geben ein Ergebnis zurück und ändern nicht den Zustand des Systems.
• Befehle: Diese Befehle ändern den Zustand eines Systems.

Command Query Responsibility Segregation (CQRS) wurde von Greg Young eingeführt. Es basiert auf dem CQS-Prinzip, ist aber detaillierter. Dieses Konzept basiert auf Befehlen und Ereignissen sowie optional auf asynchronen Nachrichten. Oftmals bezieht sich CQRS auf erweiterte Szenarien, in denen z. B. für Lesevorgänge (Abfragen) und für Schreibvorgänge (Befehle) unterschiedliche physische Datenbanken eingesetzt werden. Deshalb erfordert eine fortschrittlichere Lösung zwei separate Teile des Systems, die Lese- bzw. Schreibvorgänge verarbeiten, jedoch mit unterschiedlichen Designs, Modellen, Diensten und Datenbanken. Das folgende Bild zeigt eine solche CQRS-Implementierung mit separaten Datenbanken, Modellen und Diensten:

Vorteile von CQRS

• CQRS verspricht Ihnen verbesserte Performance und höhere Skalierbarkeit.
• Verschiedene Skalierbarkeit, schreibende Zugriffe können auf anderen Rechnern laufen als lesende und jeweils unterschiedlich skalieren.
• Eignet sich zum Einsatz in Serviceorientierten Architekturen, z. B. im Cloud Computing
• Verbesserte Sicherheit durch getrennte Rollen
• Simultaner Einsatz verschiedener Versionen möglich
• Beibehaltung von Rückwärtskompatibilität möglich
• Migration auf neue Version im Live-Betrieb ohne Downtime
• Anpassungsfähigkeit an veränderte Geschäfts-Anforderungen
• Entwicklung der einzelnen Bestandteile durch unterschiedliche Teams
• Kann mit Event Sourcing kombiniert werden

Wenn mehrere Anwendungen eine Datenbank verwenden, die nicht die jeweils applikationsspezifischen Anforderungen erfüllen kann, sodass diese voneinander getrennt und auf verschiedenen Datenbanken ausgeführt werden.

Die Separierung von Schreib- und Lesezugriffen auf zwei verschiedene Datenbanken lässt sich gut mit anderen Architekturmustern wie zum Beispiel Microservices oder Event Sourcing kombinieren.

Anwendungsfälle

Die Anwendung von CQRS ist perfekt im Falle eines großen Unterschieds zwischen der Anzahl der Lese- und Schreibvorgänge in einem System (soziale Netzwerke sind gute Beispiele dafür). Sie können beide Seiten unabhängig voneinander skalieren, z. B. den Lesediensten können weitere Ressourcen zugewiesen werden.

Wenn Leistung entscheidend ist, kann mit CQRS Lese- und Schreibseiten unabhängig voneinander optimiert werden. Auch für Anwendungen, die von vielen Benutzern verwendet werden oder viele parallele Operationen auf demselben Datensatz unterstützen müssen.

In Szenarien, wenn Sie über eine komplexe Geschäftslogik verfügen. CQRS kann das Verständnis der Domäne vereinfachen, indem das Problem in die Befehls- und Abfrageteile unterteilt wird.

Auch in Situationen, in denen Ihre Benutzeroberfläche auf Workflows basiert und das Interface-Muster verwendet. Es ist einfacher, die Absichten der Benutzer zu identifizieren und sie in Domänenereignisse zu übersetzen.

Wenn Sie die Entwicklung parallelisieren und zwei Teams einsetzen möchten. Ein Team könnte mit dem Lesen des Modells und einem zweiten mit der Schreibseite beauftragt werden.

Wenn Sie Event Sourcing bereits verwenden, lässt es sich gut mit CQRS kombinieren, da die Schreibseite den aktuellen Status als eine Reihe von Ereignissen speichern kann.

Allerdings gibt es auch die andere Seite…

Wann sollte man CQRS besser nicht benutzen?

Bei einfacher Benutzeroberfläche z. B. CRUD sollte CQRS besser nicht genutzt werden. Außerdem, wenn Sie über eine einfache Geschäftslogik verfügen, dann wäre die Implementierung von CQRS zu überwältigend. Verwenden Sie es nicht für eine vollständige Lösung - Sie benötigen CQRS nicht für jeden Teil des Systems. Es sollte sich nur auf diesen begrenzten Kontext, der wirklich CQRS benötigt, konzentriert werden.

Zusammenfassung

CQRS ist ein spannender Ansatz und eine Ergänzung zu vielen anderen Konzepten wie Domain-driven Design (DDD), Event-Sourcing und GraphQL. In Verbindung kann CQRS am besten seine Stärken ausspielen. Durch das Trennen von Schreiben und Lesen wird außerdem von Vornherein auf verteilte Architekturen abgezielt, was es für den Einsatz in service-basierten Systemen prädestiniert, welche im Web oder in der Cloud ausgeführt werden. Damit bietet CQRS auch alle Vorteile einer service-basierten Architektur: eine individuelle Skalier-, Wart- und Testbarkeit der einzelnen Dienste.