2

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?

|improve this question
  • 1
    Have you read this? martinfowler.com/bliki/CQRS.html – Robert Harvey Mar 16 '18 at 3:58
  • Ahh! I Have read that several times but missed a part of a diagram. It comes from the information the user submits! – Allenph Mar 16 '18 at 4:37
  • Question about factories remains. I will answer my own question, or I will approve your answer if you submit it. – Allenph Mar 16 '18 at 4:38
  • There is no such thing as a "read aggregate". Aggregates are only for the write/command part. They can only protect invariants if they are on the writes side. What you mean is a "read model" instead. – Constantin Galbenu Mar 16 '18 at 5:14
  • What else do yo u call an object that is a collection of entities? Aggregate and entity still seem like a rational description to me? – Allenph Mar 16 '18 at 5:50
1

In reference to your question 2, it seems like if you were to change the data model you would need to change both the thing that makes read models (so you read the new version of the model) and the thing that makes write models (so you write things into the new version of the model). These are so closely coupled that separating them seems artificial, it is appropriate to have a single factory for both cases.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.