CQRS - wie man ein Szenario-Ausführungssystem modelliert

Question

Ich habe vor kurzem angefangen, CQRS und DDD für ein grünes Feldprojekt zu untersuchen, das ich gerade beginne. Ich habe sehr viel Material von Udi Dahan, Greg Young, Mark Nijhof und anderen studiert. Diese waren wirklich sehr hilfreich und ich denke, dass ich die Konzepte gut verstehe. Aber es gibt immer noch einige Fragen, wie ich diese auf meine eigene Domain anwenden kann.

Mein System wird im Grunde eine komplexe Regel-Engine sein - in der Regeln den Endpreis bestimmter Produkte diktieren werden. Die Produktdefinitionen und -regeln werden von Administratoren in das System eingegeben. Regeln werden von Administratoren entworfen, die einen vordefinierten Satz von Eigenschaften verwenden, die Werte aus einem vordefinierten Satz haben können, z. B. "Kaufzweck" (Weiterverkauf, Vermietung) oder Freiform-Werte wie Alter.

Jedes Produkt wird einen Grundpreis haben, und Regeln werden grundsätzlich vom Basispreis hinzufügen/entfernen, wenn sie gelten.

könnte eine sehr einfache Beispielregel sein:

Für Produkt X, IF (Purchase Purpose = Resell und Alter> 25) Fügen Sie $ 25 auf Basispreis.

So gibt es 2 Arten von Benutzern, die das System verwenden, Administratoren, die die Produkte, Regeln und Basispreise definieren; und andere Benutzer, die Preise basierend auf einem Szenario abfragen, das sie über eine Was-wäre-wenn-UI eingeben.

Meine Verwirrung hier ist dies: ein Szenario läuft ändert den Zustand der Domäne überhaupt nicht, kein anderes externes System/Person ist am Ergebnis der Szenarioausführung interessiert, sondern der laufende Benutzer selbst - es gibt die Ergebnis einer Preisberechnung nach dem Ausführen der anwendbaren Regeln für das gegebene Szenario. Beispielsweise könnte der Benutzer Produkt X auswählen und die Preisfindung für ein bestimmtes Szenario abfragen, z. B. (Kaufzweck = Weiterverkauf und Alter = 40). Da diese Operation den Domänenstatus überhaupt nicht ändert, denke ich, dass es sich um eine Abfrage handelt. Aber es gibt eine Regel-Engine, die mit dem Szenario arbeitet, um den Endpreis zu berechnen, was ich als Domain-Logik bezeichnen kann, die ausgeführt wird. Also - wo gehört diese Logik? Ist dies eine Abfrage, die nur vom Lesemodell ausgeführt wird, oder führt ein Szenario einen Befehl aus, der im Domänenmodell ausgeführt werden muss? Auch hier fühlt es sich an, als ob der Domänen-Layer der richtige Platz für diese Regeln wäre. Aber wie gebe ich das Ergebnis der Szenario-Ausführung an den Benutzer weiter (fühlt sich an wie eine Abfrage, die so darüber nachdenkt). Oder vielleicht ist CQRS nicht die richtige Lösung für dieses spezielle Problem?

Answer 1

Ich hatte dieses genaue Problem in meiner eigenen Domäne (e-Scheduling 4 Gesundheitswesen). Grundsätzlich wird das System mit einem Domänenmodell (Schreibseite) konfiguriert. Dies würde Regeln, Produkte und Basispreise in Ihrer Domain definieren. Was kommt aus der Domain? Ereignisse, Zustandsänderungen, Dinge, die zusammen mit dem passiert sind, warum es passiert ist. Nun, was ich getan habe, war, diese Ereignisse in einem anderen beschränkten Kontext zu konsumieren, in meinem Fall eine komplexe Suchmaschine, die freie Plätze in den Zeitplänen von Ärzten, Operationssälen und teuren Geräten findet. Dies könnte eine Route sein, die Sie auch nutzen könnten, indem Sie Ihr Produkt, den Basispreis und regelbezogene Ereignisse konsumieren und sie so speichern, dass die Regelengine, die auf diesen Daten sitzt, Benutzeranfragen für Szenarien ebenso effizient verarbeiten kann möglich. Sehr wahrscheinlich werden Sie feststellen, dass das Modell zum Speichern von Änderungen (Domäne) sich von dem Modell unterscheidet, das für die Abfrage dieser Was-wäre-wenn-Szenarien (Regel-Engine) optimiert wurde. Ihre Domain wird wahrscheinlich Regeln haben wie "Sie können nicht das gleiche Produkt zweimal angeben" oder "diese Regel wird nie übereinstimmen (Alter & Alter> 25)". Die Domäne befasst sich nur mit gültigen Statusänderungen. Dies ist kein Problem der Regelengine. Sie werden versucht sein, Konzepte/Klassen in Ihrer Regelengine wiederzuverwenden, die in der Domäne definiert sind. Widerstehen Sie diesem Drang.Frage, ob sie wirklich dem gleichen Zweck dienen. Zweimal zu einem anderen Zweck zu modellieren, ist nicht schmutzig oder eine Verletzung von DRY.

Answer 2

CQRS gibt nichts darüber aus, dass im Abfrageteil der Anwendung keine Domänenlogik vorhanden sein sollte. Wenn es möglich und praktisch ist, dann ist es in Ordnung, getrennte denormalisierte Abfragespeicher für jeden Aspekt oder sogar für die Abfrage Ihrer Anwendung zu haben, aber natürlich ist das nicht notwendig.

Kurz gesagt, eine Abfrage ist eine Abfrage, egal wie komplex die Aufgabe ist, ihre Antwort zu finden.