CQRS reading from the domain model?

Question

Is it totally forbidden (or just inappropriate) for the domain model in CQRS to return state to the client? e.g. if live updated information exists in the domain model. I'm thinking of a command causing events and changes to the domain model and returning info to the client.

The alternatives seem to be:

1. the client determines the updated state itself (duplication of code), which should hopefully match the eventual update of the read model,

2. the client waits for the read model to be updated (eventual consistency) and somehow knows when to read from there to update its state, or

3. the whole command is done synchronously and the read model somehow pushes the information to the client, e.g. with some sort of web socket.

I guess the latter relates to the desire to build reactive applications incorporating CQRS. The notion of the client polling for updates seem unsatisfactory (and similarly for the read model polling for updates from the domain model).

Answer 1

Is it totally forbidden (or just inappropriate) for the domain model in CQRS to return state to the client?

Assuming you mean DDD/CQRS, I think the dogmatic answer is "so inappropriate it may as well be forbidden". Sure, it's not going to hard-break anything on its own, but your architecture has taken a step down a very slippery slope that (at its bottom) is a big-ball-of-mud.

You want your Domain model to be isolated from all the issues of what people want to see afterwards.

returning info to the client

Consider that for any given Command sent to the Domain model, there can be multiple versions of "info" the client might want, depending on how the command is being invoked!

Imagine a button called "Send Invoice" that appears both on the "regular flow" page and the "bulk modify" page. Those might invoke the same Command yet have drastically different requirements for what the user sees as "the result" of what they did.

The alternatives seem to be:

I'd look at the Application Layer for this, or whatever layer would know "where" the user is when they are doing things. (Perhaps the same place where POST data is becoming an instance of a Command object.) That layer is the one that has enough context to determine what read-model to look at for the eventual results.

Whether you want the server to block (polling the DB), or the client do its own polling, or asynchronous websocket-stuff... That's another story.