According the article of Martin Fowler and Microsoft CQRS Journey , the CQRS is a pattern applying in a BC, not the architecture for whole system. I get confused in how to get state of an aggregate from anything external in CQRS.
Should an aggregate have a command
Get to return its state in write model, or a corresponding query in read model?
It’s example of shopping cart service in Akka Platform Guide.
ShoppingCart is an aggregate, it has three commands:
Get . In the command handler of
Get , it replies summary of shopping cart to the command sender. In this way, each aggregate has a command
Get to return its state in write model.
But I suppose the
Get is a query exactly, not a command. Because in CQRS pattern, command changes the state of the aggregate and triggers events, but returns nothing. On the other side, query returns a copy of the current state of the aggregate, but changes nothing. All commands exist in write model, all queries exist in read model. If I want to get state, I shouldn’t send a command to write model but a query to read model. The eventually consistence is maintained by the event projection from write model to read model.
ShoppingCart should be moved into read model. Anything external wants to get the state of
ShoppingCart , it should send query
ShoppingCart and get reply
Summary finally. But in this way, the state maybe is stale. Should it get problem in consistence?
Which design is necessary and better?
Get in read model gets risk of consistence, putting it in write model gets semantic ambiguity otherwise. That’s my confusion.