
How to Prevent Your DDD App from Blowing Up by Implementing CQS/CQRS - stemmlerjs
https://khalilstemmler.com/cqs-article
======
ivan_gammel
Somehow this article misses key steps in the logical proof of the need not to
expect any data as a result of command. It’s quite hard to understand the way
of thought going from unspecified heisenbug to thesis about difficulties with
reasoning about state.

I doubt that such proof can exist and that even such purism makes any sense:
why adding another round trip between client and server? What architectural
problem justifies doubling the number of requests?

~~~
wppick
> What architectural problem justifies doubling the number of requests?

Simplicity. If I create some "component" that declares what its data from the
server needs to be (some subset of the domain), then it knows how to read/load
the data to display (query). The component can do any commands where the user
wants to change some domain entities/state and I don't need to care about
figuring out how to update my local state with some response from the
individual command. I can just ask the server "give me the updated state",
which is the same subset of the domain you declared for that component.
There's much less chances for things to go wrong in this design since there is
only one code path for updating the components state.

~~~
stemmlerjs
"There's much less chances for things to go wrong in this design since there
is only one code path for updating the components state" ^ - well said! I'm
going to update the article to be a bit more clear about that.

