DDD, Aggregate roots and Entities

Question

According to DDD principles all CRUD operations working with entities related to a specific aggregate root object should be made by the aggregate root.

But how do we change only a single property of an Entity from the aggr root? Should we have setter methods in Entities and what accessors should these methods have ?

Or may be all entities should have a reference in theirselves pointing their aggregate root ?

Or we never change only a single property but replace the entity with a totaly new one instead with the current entity state?

Answer 1

According to DDD principles all CRUD operations working with entities related to a specific aggregate root object should be made by the aggregate root.

Yes; you can think of the aggregate root being a role interface that constrains how the application is allowed to manipulate the model.

But how do we change only a single property of an Entity from the aggr root? Should we have setter methods in Entities and what accessors should these methods have ?

The fact that the aggregate is a composed of multiple entities is an implementation detail. So behind the role interface you can delegate the responsibilities for the change any way you like.

Ideally, if you are modeling a change to an entity in the domain model, there should be corresponding vocabulary in the ubiquitous language describing the change. In other words, just as we use the language of the business to describe changes made to the aggregate root, so too do we use that same language to describe changes to the entities within the model.

The "CRUD" operations therefore tend to be internal implementation details of the entity manipulating its own state. When you find yourself reaching for get/set, or create/read/update/delete, that's a hint that you are crossing from the domain model to the data model.

Or we never change only a single property but replace the entity with a totally new one instead with the current entity state?

That probably indicates that you are modeling an entity where you should be modeling a value.

Answer 2

As a general rule, the identity of entities should not be visible outside of the aggregate. Updating entities can be easily done by the aggregate root. AR should have a method changeChildProperty1(newProprty) or changeChild(childData) and then AR will decide either to update the current entity or replace it with a new one. The reason for this is that the AR should be responsible for maintaining all the invariants of the aggregate.

Updating child entities and value objects should be relatively easy. If it looks hard to achieve in your current project maybe you should reconsider the design of your aggregate. Sometimes it makes more sense to split it into 2 different aggregates.