Premise
A web application that has a frontend / backend separation. The frontend can be the JS framework of the month, which talks to a REST API in the backend.
The backend part of the system accepts commands, which are delegated via application services to a Rich Domain Model created by applying Domain Driven Design principles.
CQRS is applied, so queries don't use the domain model.
Consider the following fabricated scenario
We're building a system to ship orders. We have two date controls: a shipment departure date and a preferred shipment arrival date. We also have a dropdown menu with carriers. The user selects a carrier and sets the preferred shipment arrival date. Based on various factors like weight, country, container size, etc. some complex calculation determines the departure date.
So changing the dropdown should update the departure date, but only in the UI. The actual state of the shipment hasn't changed yet. The user can still decide that it's not possible to have the shipment ready at the calculated departure date, so (s)he could change the carrier and see what the departure date would be with that carrier.
Finally there's a Save button, that sends a command to update the shipment with the selected carrier, departure date and arrival date. The domain will have to perform the calculation again, to validate the combination of carrier and dates.
The problem
When applying CQRS, a request is either a command or a query. Typically the models are clearly separated.
A command is supposed to do something; do calculations, update and persist the aggregate's state and publish events. It typically doesn't return anything.
A query is much simpler; it returns the current state of a specific part of the system. A query has no side-effects.
In the above shipment example, how should we handle the part that updates the UI? It doesn't feel right to treat is as a command, because it has no side effects and we need a response. It also doesn't feel right to treat is as a query because of the complex calculations. Furthermore the same business logic is required twice, so if we treat it as a query, our cleanly separated models suddenly have code duplication or our query model gets a dependency on our domain model.
Proposed solution
I'm leaning towards creating a domain service that can perform the calculation and then have a dependency on this service from the query model. The implication is that I have to change the domain model; instead of having the calculation nicely encapsulated within an entity, a separate class is required leading to a more anemic domain model.
I'm curious how other who faced similar challenges solved it.
