Can readmodel and writemodel inherit from Model for fields in DDD + CQRS?

Question

I'm new to DDD + CQRS, and I'm working in a project that has this implemented, but I wonder why the guy duplicates the models.

I understand, that one is for writing (commands) and one is for reading, but both implement the same fields, except that ReadModel only has getters.

Is there any advice against having the fields (id, name, socialnumber, etc) of a relational database AND getters in a model then inherit them in WriteModel and ReadModel?

For example:

Abstract UserModel

UserReadModel inherits UserModel

UserWriteModel inherits UserModel

Answer 1

Sharing a base model is against everything that CQRS stands for. If your models (write and read) are 99% percent then it is a CRUD architecture painted to look like CQRS.

You must split the write from the read because the two models have different behaviors: the write model is concerned with ensuring the invariants and the read model is concerned with the reading and displaying the data to the user. It is normal that some of the fields are shared but only as concepts. In the write side, you create Commands that have those fields, send them to the write models (Aggregates in DDD) and generate events that have some of the fields from the commands. In the read side you read the events and create some simple persistence objects, with no behavior that ensure the invariants; they can have behavior but a different kind from the write models.

On the read side you could have mega objects that contain fields from multiple write models. The main idea of the read models is to be very fast (i.e. no JOINS), so you include in a row or document all you need to display the data to the users.

On the other side, the write side, you put in commands only the minimum information needed to maintain the invariants (i.e. you refer other Aggregate roots only by their IDs).

So, as a metaphor, the write and read models are like matter and antimatter: they should not collide; they are separated (decoupled) by events that act like a magnetic fields.

UPDATE:

The read models only see the events generated by the Aggregates (the write models); they don't query the write models as it is forbidden; so the write models have only command methods and no query methods; on the other hand, the read models have only query methods (i.e. getters) and no command methods; the read models are immutable; the only way to mutate the read models is by listening to the events and apply those events them.

Answer 2

Is there any advice against having the fields (id, name, socialnumber, etc) of a relational database AND getters in a model then inherit them in WriteModel and ReadModel?

Actually, there is. The read model and the write model are conceptually different, and in particular evolve largely independently of each other.

Matthias Verraes wrote:

“Don’t Repeat Yourself” was never about code. It’s about knowledge. It’s about cohesion. If two pieces of code represent the exact same knowledge, they will always change together. Having to change them both is risky: you might forget one of them. On the other hand, if two identical pieces of code represent different knowledge, they will change independently. De-duplicating them introduces risk, because changing the knowledge for one object, might accidentally change it for the other object.

I would expect the read and write models to have many common concepts in them. Value types from the domain model, for example: if you have a Money type it will likely make sense in the read model just as it does in the write model.

But, as Constantin points out, the motivation for the CQRS pattern is to allow writes to use an underlying data structure optimized for writes (for example: a history), and the reads an underlying data structure optimized for reads. So I wouldn't be in a hurry to couple the read model and write model together.

I don't see how you're buying much from this except having immutable read objects. What purpose does that serve?

Code clarity is a big one -- putting a reference to an immutable interface into your method signature clearly documents that you will not be attempting to modify the argument in any way. Thus, in your write code paths, there's no confusion about which object is going to be written -- it's always going to be the mutable one.