Anwendungsbereiche

Vorweg eine Warnung: Die Autoren empfehlen CQRS nicht als "globale" Architektur. Tatsächlich lässt sich ein hinreichend komplexes Softwaresystem nicht durchgängig mit einem einzigen Architekturmuster erstellen. Architektonische Entscheidungen für jeden Teilbereich sind explizit und unabhängig voneinander zu treffen. Nur so lassen sich verschiedene nichtfunktionale Anforderungen optimal implementieren. Jedoch bietet CQRS einen Ansatz für eine Reihe unabhängiger Probleme. Im Folgenden seien Typen von Systemkomponenten vorgestellt, bei denen der Einsatz von CQRS einen deutlichen Mehrwert darstellt.

Komponenten, bei denen Daten wesentlich häufiger gelesen als verändert werden, profitieren am offensichtlichsten von der Trennung in Abfrage- und Domänenmodell. Für alle Formen von Datenabfragen, wie der Bildschirminhalte einer Applikation, Ausdrucke im Reporting oder Schnittstellen zu externen Systemen, liegen die benötigten Daten jederzeit exakt so aufbereitet vor, wie die jeweilige Datenabfrage sie benötigt. Somit ist das Abfragen von Daten immer maximal performant. Das Bearbeiten von Änderungen findet unabhängig vom Abfragemodell statt. Erst im Anschluss werden diese Daten aktualisiert und dadurch das Locking minimiert.

Komponenten der Kerndomäne eines Systems bieten ihren Mehrwert häufig durch komplexes Verhalten, dessen Spezifikationen sich mit der Zeit aus verschiedenen Gründen ändert. Sei es, dass Kunden neue Anforderungen stellen, Änderungen des Markts oder der Gesetzeslage Rechnung zu tragen ist oder Vertrieb und Marketingabteilung sich von Erweiterungen des Systems einen Mehrwert versprechen. CQRS ermöglicht gerade bei volatilen und evolvierenden Systemen, die Flexibilität in Wartung und Weiterentwicklung zu erhalten. Das Verhalten von mit CQRS aufgebauten Komponenten ist frei vom Ballast der Datenbereitstellung "leichtgewichtig" implementiert. Ausgehend von der klaren Erfassung der Benutzerintention in den Befehlsobjekten orientiert sich der Aufbau des Quellcodes entlang der fachlich spezifizierten Anforderungen. In Kombination mit Event Sourcing lassen sich diese Anforderungen optimal durch Akzeptanztests prüfen. Durch die Formulierung der Voraussetzungen eines Tests sowie der erwarteten Ergebnisse als Ereignisse werden Anforderungen direkt in Code übertragen. Umgekehrt lässt sich ein Testprotokoll von Fachanwendern sofort lesen und verstehen (Abb. 4).

Test eines Domänenmodells mit vorausgesetzter Historie, zu testender Funktion und als Ergebnis erwarteten Ereignissen (Abb. 4)

Das zentrale Anwendungsfeld von CQRS sind Systeme mit hoher Kollaboration und häufigen konkurrierenden Zugriffen durch mehrere Benutzer. Hier erlaubt CQRS, auf klassisches Locking zu verzichten und Zugriffskonflikte aufzulösen. Durch das Erfassen der Intention der Benutzer in den Befehlen lässt sich für jeden Befehl einzeln definieren, ob das auszulösende Verhalten mit anderen Befehlen oder dem vorliegenden Systemzustand kollidiert oder kompatibel ist. So kollidieren in einer Warenwirtschaft die parallelen Befehle "Füge Produktfoto hinzu" und "Erhöhe Produktpreis um 20 EUR" nicht, obwohl sie formal das gleiche Produkt beeinflussen.

In einer CRUD-Anwendung, in der beide Nutzer nur die Anweisung "SpeichereÄnderungenAmProdukt" zur Verfügung haben, bliebe nur die Entscheidung zwischen optimistischem oder pessimistischem Locking. Dort würde also einer der beiden Vorgänge bereits im Vorfeld unmöglich sein ("Ein Kollege bearbeitet gerade das gleiche Produkt ...") oder im Nachgang fehlschlagen ("Ein Bearbeitungskonflikt ist aufgetreten").

Selbst im Fall einer echten fachlichen Kollision zweier Befehle – wie “Lege Produkt in den Warenkorb” und “Setze Produktstatus zu nicht lieferbar” – kann man im Einzelfall genau definieren, wie die Software den Konflikt behandeln soll. Ein Produkt das nicht lieferbar sein soll, sollte grundsätzlich auch nicht mehr bestellt werden können, unabhängig davon, welcher Befehl nun einen Augenblick früher an der Domäne ankam. Wenn die Kollision allerdings mit einem Produkt auftrat, dessen Bestellwert einen gewissen Betrag überschreitet, könnte das System die Kollision zugunsten der Bestellung behandeln, da ein Mehrwert für das Unternehmen gegeben ist, der den Aufwand rechtfertigt, das Problem später manuell zu lösen. Für das Unternehmen wären die Kosten einer händischen Nachbestellung oder eines kostenlosen Upgrades auf ein höherwertiges Produkt geringer als der Verlust durch den sonst entgangenen Umsatz.

Eine häufige fachliche Anforderung an Software ist die detaillierte Nachvollziehbarkeit aller Vorgänge im System. CQRS mit Event Sourcing erfüllt diese Anforderung ganz nebenbei ohne weiteren Aufwand: Die Historie der Ereignisse ist ein garantiert vollständiges Protokoll, da der Systemzustand aus ihr abgeleitet wird. Darüber hinaus ist sie für die Analyse von Fehlern und unerwartetem Verhalten hilfreich. Anstelle der üblichen Support-Vorgehensweisen, wie Analyse einer Zustandsdatenbank aus dem Backup und Gespräche mit den Usern, kann man den Hergang einfach nachlesen. Auch lässt sich ein Systemzustand der Vergangenheit jederzeit gezielt für forensische Zwecke rekonstruieren.

Risiken und Nebenwirkungen

Der Einsatz von CQRS führt zu einer deutlich vereinfachten Systemarchitektur. Allerdings besitzt diese für viele Entwickler anfangs eine recht hohe "gefühlte" Komplexität. Das resultiert nicht so sehr aus der vermeintlich steilen Lernkurve, ein interessantes Podcast-Projekt zeigt, dass diese eher flach ist. Vielmehr bereitet das Entlernen des Einsatzes komplizierter Enterprise-Frameworks oftmals Schwierigkeiten. Objektiv gesehen ist dies durchaus ein Risiko, da größere Änderungen des Werkzeugkoffers einer Entwicklungsabteilung zunächst zu einem deutlichen Einbruch der Produktivität führen können. Auch besteht die Gefahr von Fehleinschätzungen aus mangelnder Erfahrung mit dem Werkzeug CQRS. Daher sollte bei der Einführung jeder neuen Methode zunächst an einem nicht übermäßig geschäftskritischen Projekt geübt werden.

Ein reales Problem hingegen ist die noch nicht umfangreiche Tool-Unterstützung für die Bestandteile einer CQRS-Architektur. Beide Autoren haben genau deshalb noch bei ihren letzten Projekten auf SQL-Server-Implementierungen zurückgegriffen. Zwischenzeitlich wird aber die Tool-Ausstattung deutlich besser. Nicht zuletzt ist seit Herbst 2012 ein kommerzieller (quelloffener) Event store auf dem Markt verfügbar, inklusive den für die zentrale Datenhaltungskomponente oft zwingend vorausgesetzten professionellen Supportangeboten.

Eine weitere Nebenwirkung sei nicht verschwiegen: Der starke Fokus auf das Verhalten der Software führt gerade bei einfachen Systemen zu größeren Aufwänden bei Analyse und Design als eine reine Implementierung von Datenstrukturen. Bei letzterer lässt sich das Verhalten schlicht weglassen und die regelkonforme Bearbeitung der Daten an den Benutzer delegieren. Da CQRS das Erfassen der Intention des Benutzers und das Abarbeiten der Geschäftslogik aufgrund dieser Intention in den Vordergrund stellt, ist eine saubere Analyse der Problemdomäne schwer zu umgehen. Ob das ein Vor- oder Nachteil ist, mag jeder Leser für sich entscheiden.