Disclaimer: This question may be related to the framework I’m using to support CQRS/ES rather than the concepts themselves but many of these frameworks implement the same strategies, making me think the two are tightly coupled regardless.
CQRS tells us to…
use a different model to update information than the model you use to read information1
And in event sourcing…
The fundamental idea of Event Sourcing is that of ensuring every change to the state of an application is captured in an event object2
My design includes aggregate root objects, upon which methods are called to make changes (in my particular case called from Commands/Handlers). Those methods check the invariants and then publish an event to a bus, which in turn updates some aspect of the aggregate, typically setting properties or adding items to a collection. These events also update my read model so that I have a projection of the most recent state of the system that can be easily queried. Most of my queries simply act upon the most recent state, but occasionally I need to create a projection for an aggregate as it existed at a point in the past (hence the use of event sourcing).
As such my aggregate root and read model share a very similar “shape”, so similar that I’ve created an interface that both implement so that I can treat them equally depending on the type of query being executed.
Given that the aggregate root and read model are so similar, and even though the aggregate appears to belong to the write model (as the commands act upon it) does it in fact belong in the read model?
Or, where does the aggregate root belong? In the write model, the read model or in a shared domain model, which seems to go against the whole CRQS idea?