CQRS - How to Model a Scripting System

Question

I recently started investigating CQRS and DDD for the green field project that I am about to start. I learned a lot of materials from Udi Dahan, Greg Young, Mark Nijhof and others. It was very helpful, and I think I have a good understanding of the concepts. But I still have certain questions about how I can apply them in my own domain.

My system will be basically a complex rule machine in which rules will determine the final price of certain products. Product definitions and rules will be entered into the system by the administrator. Rules will be developed by administrators using a predefined set of properties that can have values ​​from a predefined set, such as "Purpose of purchase" (resell, rent) or free form values ​​such as Age .

Each product will have a base price, and the rules will basically add / remove from the base price, if applicable.

A very simple sampling rule can be:

For product X, IF (Purpose of purchase = resale and age> 25) Add $ 25 to the base price.

Thus, there are two types of users who use the system, administrators who define products, rules, and base prices; and other users who request pricing based on a script that they enter through the what-if user interface.

My confusion here is this: running the script does not change the state of the domain at all, no other external system / person is interested in the result of the script, and the user is working - he returns the result of the price calculation after running the applicable rules for this script. For example, a user may select Product X and request pricing for a given scenario, for example (Purchase Purpose = Resale and Age = 40) . Again, since this operation does not change the state of the domain at all, I assume this is a request. But there is a rule mechanism in the script that calculates the final price, which, I believe, can be classified as executable domain logic. So - where is this logic? Is this a query that just runs on a read model or runs a script, a command that should be run on a domain model? Again, it seems that the domain level is the place that should be for these rules, but how can I pass the result of the script to the user (it seems that he thinks so about it). Or maybe CQRS is not the right solution for this particular problem?

Answer 1

I had this exact problem in my own domain (e-scheduling 4 healthcare). Basically, the system is configured using the domain model (recording side). This will be the definition of the rules, products and base prices in your domain. What goes out of the domain? Events, state changes, things that happened along with why it happened. Now what I was doing absorbed these events in another limited context, in my case, a sophisticated search engine that finds free slots in the schedules of doctors, operating rooms and expensive equipment. This could be a route that you could take, as well as use your product, the base price and the events associated with the rules, and store them so that the rules mechanism sitting on top of this data could handle user requests for scripts as efficiently as possible. Most likely, you will find that the change storage model (domain) is different from the model optimized for querying what-if scenarios (rule engine). Your domain will likely have rules such as "you cannot specify the same product twice" or "this rule will never be matched (age <25 & age & age 25)." The domain only applies to valid state changes. This is not a rule mechanism problem. You will be tempted to reuse concepts / classes in your rules engine, which are defined in the domain. Resist this urge. The question is whether they really fulfill the same goal. Modeling it twice for another purpose is not dirty or a violation of DRY.

Answer 2

CQRS does not say anything about the domain logic in the application request part. If this is possible and practical, then it’s normal to have separate denormalized query stores for every aspect or even request of your application, but of course this is not necessary.

In short, a query is a query, regardless of how complex the task of finding the answer is.