tawiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== CQRS ======
//Command and Query Responsibility Segregation// ist ein Konzept das auf CQS((Command  and Query Separation [[http://en.wikipedia.org/wiki/Command-query_separation]])) von Bertrand Mayer(([[http://en.wikipedia.org/wiki/Bertrand_Meyer]])) basiert, und von Greg Young entwickelt wurde. CQS trennt die Aufgaben eines Objektes in zweierlei. Entweder setzt eine Methode eines Objektes einen Befehl um, oder sie beantwortet eine Frage. Wenn sie einen Befehl umsetzt hat die Methode keinen Rückgabewert. Wenn sie eine Frage beantwortet bleibt das Objekt unverändert, so dass die Antwort auf die Frage ((und alle anderen)) immer dieselbe bleibt.
\\ \\ CQRS geht einen Schritt weiter indem es die Aufgaben auf zwei Objekte aufteilt. Ein Objekt führt Befehle aus, das andere beantwortet Fragen. So kann jedes Objekt für die eigenen Aufgaben optimiert werden.
===== Implementierung =====
==== Command ====
----
Um eine Aktion in der Domäne durchzuführen werden folgende Schritte durchgeführt
  * UI baut einen [[technology:cqrs:command|Command]]
  * UI schickt diesen Command an die [[technology:patterns:remotefacade|Remote Facade]]
  * die Remote Facade ruft in der Applikationsschicht den entsprechenden [[technology:cqrs:commandhandler|Command Handler]] auf
  * der Command Handler sammelt alle notwendigen Informationen um den Befehl durchzuführen, führt eigene Prüfungen durch((so wenig wie möglich, die Logik soll in der Domäne bleiben)), lädt das [[technology:domainmodel:aggregate|Aggregate]] über das dafür vorgesehene [[technology:domainmodel:repository|Repository]] und ruft die entsprechende Methode in dem Aggregate auf, wobei alle notwendigen Daten dafür mit übergeben werden
  * Das Aggregate prüft alle [[technology:domainmodel:invariant|Invariants]] und führt die Methode dann durch indem es [[technology:cqrs:domainevent|Domain Events]] veröffentlicht
  * Der Command Handler speichert das geänderte Aggregate zurück über das Repository((welches die veröffentlichten Domain Events aus dem Aggregate abfragt und speichert))
==== Abweichende Implementierung ====
----
Die Regel lautet, dass man [[technology:cqrs:command|Commands]] einzeln ausführt, welche auf natürliche Weise in einer Transaktion geschachtelt werden. Will man zwei oder mehr Commands ausführen, werden dafür auch zwei oder mehr Transaktionen gestartet. Dabei kann es passieren, dass der erste erfolgreich ausgeführt wird, der zweite nicht.
\\ \\ Das ist i.d.R. kein Problem. Die Domäne ist per Definition nach Ausführung eines Befehls immer in einem konsistenten Zustand, weil jeder Befehl durch die Domäne läuft, mit Aggregaten, die alle Business Regeln prüfen bevor der Befehl ausgeführt wird. Es ist für den Anwender aber u.U. etwas irritierend, wenn er in einem Dialog Änderungen vornimmt, den Dialog mit OK bestätigt, und nur ein Teil von den Änderungen gespeichert werden. Das wäre keine zufriedenstellende Benutzererfahrung, der Benutzer erwartet von Natur aus, dass alle Änderungen entweder gemeinsam gespeichert werden oder gemeinsam abgelehnt werden.
\\ \\ Was kann man machen? Man könnte einen [[technology:domainmodel:domainservice|Domain Service]] bauen, der alle Befehle des Dialogs in einen großen Befehl packt, und diesen dann ausführt. Das wäre nicht sehr sinnvoll, weil der Domain Service dieselben Aufgaben übernimmt wie andere veröffentlichte Methoden des Aggregates, und es pro Command-Kombination einen Domain Service geben müsste. Ein Domain Service ist dafür da, Regeln zu prüfen, die nicht in ein einzelnes Aggregate gepackt werden können, würde also in diesem Fall für UI-Zwecke missbraucht werden und würde somit eine Abhängigkeit zum UI erhalten, die absolut nicht vorhanden sein darf.
\\ \\ Man könnte das UI entsprechend bauen, so wie es Greg Young vorschlägt - behavior driven UI. In dem Fall würden die Dialog die Befehle wiederspiegeln, kleiner sein und sicherlich auch übersichtlicher. Das ist sicherlich die am erstrebenswerteste Lösung.
\\ \\ Man könnte [[technology:cqrs:compensatingaction|Compensating Actions]] umsetzen, die den ersten Befehl negieren, wenn der zweite fehl schlägt. Das ist völlig übertrieben, erhöht den Programmieraufwand um ein Vielfaches wenn man das an diversen Stellen umsetzen möchte.
\\ \\ Der für mich beste Kompromiss ist [[technology:cqrs:multiplecommandhandling|Multiple Command Handling]], der es erlaubt, dass mehrere Befehle in einer Transaktion durchgeführt werden, unter ganz bestimmten Bedingungen((im Grunde nur die eine, dass alle Befehle für ein und dasselbe Aggregate sind)).
tawiki

User Tools

Site Tools

Page Tools
