I have a system that interacts with a REST API as the data source. This system is based on DDD and all of my current models are CRUD models. There is one model that the REST API is only able to query as a full aggregate, but only able to write as entities within that aggregate. The reasoning behind this API design is that writing any entity in the aggregate will change the state of the rest of the entities.
This seemed like a good opportunity to try some derivative of CQRS where I have a read aggregate which is populated by that query to the REST API and a series of smaller write aggregates (each of these corresponding to an entity in the read aggregate.)
Using the mediator pattern any write would trigger an event. This event in turn causes the read aggregate repository to re-query the REST API.
The read model is not that complex, but I think this is where my understanding of CQRS breaks down...
Assertion: When I instantiate a write model, it must have all of the properties of the corresponding entity in the read aggregate. Then I can use setters on the write model to manipulate its state and ultimately send it off to the data mapper to be persisted and dispatch my read model refresh event.
Question 1: What do I use to populate the write model upon its instantiation? My immediate thought was to create a mapper which translates the corresponding read aggregate entity to the write model.
Question 2: Since the write models and the read model will have the same properties and only different methods (only getters on the read model and only setters on the write model) their constructors should stay pretty much the same. Can I then reuse the same factories? Is this an appropriate decision?