undefined | Better HN

0 pointsJtsummers6mo ago0 comments

> it’s generally more robust for the command to return that information to the caller, who then can make use of it. But now the command is also a query.

You don't need the command to return anything (though it can be more efficient or convenient). It can set state indicating, "Hey, I was called but by the time I tried to do the thing the world and had changed and I couldn't. Try using a lock next time."

  if (query(?)) {
    command(x)
    result := status(x) //  ShouldHaveUsedALockError
  }

The caller can still obtain a result following the command, though it does mean the caller now has to explicitly retrieve a status rather than getting it in the return value.

0 comments

layer86mo ago

Where is that state stored, in an environment where the same command could be executed with the same parameters but resulting in a different status, possibly in parallel? How do you connect the particular command execution with the particular resulting status? And if you manage to do so, what is actually won over the command just returning the status?

I’d argue that the separation makes things worse here, because it creates additional hidden state.

Also, as I stated, this is not about error handling.

codebje6mo ago

CQRS should really only guide you to designing separate query and command interfaces. If your processing is asynchronous then you have no choice but to have state about processing-in-flight, and your commands should return an acknowledgement of successful receipt of valid commands with a unique identifier for querying progress or results. If your processing is synchronous make your life easier by just returning the result. Purity of CQRS void-only commands is presentation fodder, not practicality.

(One might argue that all RPC is asynchronous; all such arguments eventually lead to message buses, at-least-once delivery, and the reply-queue pattern, but maybe that's also just presentation fodder.)