CQRS - how to model a scenario execution system

Question

I recently started investigating CQRS and DDD for a green field project that I\'m about to start. I studied a great deal of material from Udi Dahan, Greg Young, Mark Nijhof and

Answer 1

CQRS states nothing about that there shouldn't be domain logic in the query part of the application. If it's possible and practical then it's ok to have separate denormalized query stores for every aspect or even query of your application but of course it is not necessary.

In short, a query is a query, no matter how complex the task of finding it's answer.

Answer 2

I had this exact issue in my own domain (e-scheduling 4 healthcare). Basically the system is configured using a domain model (write side). This would be defining rules, products and base prices in your domain. What comes out of the domain? Events, state changes, things that happened along with why it happened. Now what I did was consume these events in a different Bounded Context, in my case a complex search engine that finds free slots in the schedules of doctors, operating theaters, and expensive equipment. This could be a route you could take as well, consuming your product, base price, and rule related events and store them in such a way that the rule engine, sitting on top of that data, can handle user requests for scenarios as efficiently as possible. Most likely you'll find out that the model to store changes (domain) differs from the model optimized to query those what-if scenarios (rule engine). Your domain will probably have rules like "you can't specify the same product twice" or "this rule will never be matched (age < 25 && age > 25)". The domain is concerned with only allowing valid state changes. This is not a concern of the rule engine. You'll be tempted to reuse concepts/classes in your rule engine that are defined in the domain. Resist that urge. Question if they really serve the same purpose. Modelling it twice for a different purpose is not dirty or a violation of DRY.