3 ms·

How to Prevent Your DDD App from Blowing Up by Implementing CQS/CQRS

• ivan_gammel 7y ago
  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 7y ago
    > 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 7y ago
      "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.