2

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:

  1. 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
  2. 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?

kayess
  • 3,384
  • 9
  • 28
  • 45
CraigM
  • 561
  • 8
  • 20

1 Answers1

3

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

Yes.

If you want to understand , it will help a lot to read up on -- 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

  1. Load the current state of the target of the command
  2. Invoke the command on the target
  3. Persist the changes to the book of record

My understanding is that CQS allows for a more easier transition to CQRS later on (if necessary)?

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.

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?

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.

VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91
  • Thanks for that. I've done a couple ddd courses and read a few Eric Evans, Greg Young and Martin Fowler posts around the subject, but found when trying to apply what I learnt, I just wasn't quite sure about a few aspects. Thank you for filling the gaps, it's much appreciated. – CraigM Dec 12 '16 at 20:11
  • Probably another stupid question which may be pretty obvious, but do the command and query handlers sit best in the BLL or DAL layer? I'm leaning more to the BLL layer as then I don't need to be mapping my domain models to my data/entity models from outside the handlers (the mapping could all be encapsulated within the handlers - preventing further pollution of my BLL with mapping code) - is this correct? This also adheres more to the Single Responsibility Principle. – CraigM Dec 13 '16 at 08:49
  • Business logic layer, typically -- in your unit tests, you would normally test commands using a test double for the repository (DAL). – VoiceOfUnreason Dec 13 '16 at 13:38