I'm just trying to get my head around how one goes about updating an entity using CQS. Say the UI allows a user to update several properties of a particular entity, and on submit, in the back-end, an update command is created and dispatched.
The part I'm not quite understanding is:
- does the cmd handler receiving the message from the dispatcher then retrieve the existing entity from the DB to then map the received stock item properties to then save? Or
- is the retrieval of the existing item done prior to the dispatching of the cmd msg, to which it is then attached (the retrieved entity attached to cmd that is then dispatched)?
My understanding is that CQS allows for a more easier transition to CQRS later on (if necessary)? Is that correct?
If that is the case, the problem with 2 above is that queries could be retrieved from a schema looking very different to that from the command/write schema. Am I missing something?
Yes.
If you want to understand cqrs, it will help a lot to read up on ddd -- not that they are necessarily coupled, but because a lot of the literature on CQRS assumes that you are familiar with the DDD vocabulary.
But a rough outline of the responsibility of the command handler is
That's not quite right -- understanding Meyer's distinction between command and queries make the CQRS pattern easier to think about, but I'm not convinced that actually helps in the transition all that much.
Maybe - queries typically run off of a schema that is optimized for query; another way of thinking about it is that the queries are returning different representations of the same entities.
Where things can get tricky is when the command representation and the query representation are decoupled -- aka eventual consistency. In a sense, you are always querying state in the past, but dispatching commands to state in the present. So you will need to have some mechanism to deal with commands that incorrectly assume the target is still in some previous state.