Aggregate Root References Each Other
mstrYoda opened this issue · comments
In DDD, there is a strict rule that says "An aggregate root only can give reference each other by id". In your system ForumMessage aggregate root contains another aggregate root which is ForumThread.
"An aggregate root only can give reference each other by id" is wrong, aggregate root is a object ,object only can reference other objects, not their id.
I'm directly referencing from Vaughn Vernon's book "Implementing Domain Driven Design":
RULE: REFERENCE OTHER AGGREGATES BY IDENTITY
When designing Aggregates, we may desire a compositional structure that allows for traversal through deep object graphs, but that is not the motivation of the pattern. [Evans] states that one Aggregate may hold references to the Root of other Aggregates. However, we must keep in mind that this does not place the referenced Aggregate inside the consistency boundary of the one referencing it. The reference does not cause the formation of just one whole Aggregate.
Making Aggregates Work Together through Identity References
Prefer references to external Aggregates only by their globally unique identity, not by holding a direct object reference (or “pointer”).
Aggregates with inferred object references are thus automatically smaller because references are never eagerly loaded. The model can perform better because instances require less time to load and take less memory. Using less memory has positive implications for both memory allocation overhead and garbage collection.
Model Navigation
Reference by identity doesn’t completely prevent navigation through the model. Some will use a Repository (12) from inside an Aggregate for lookup. This technique is called Disconnected Domain Model, and it’s actually a form of lazy loading. There’s a different recommended approach, however: Use a Repository or Domain Service (7) to look up dependent objects ahead of invoking the Aggregate behavior.
Scalability and Distribution
Since Aggregates don’t use direct references to other Aggregates but reference by identity, their persistent state can be moved around to reach large scale. Almost-infinite scalability is achieved by allowing for continuous repartitioning of Aggregate data storage, as explained by Amazon.com’s Pat Helland in his position paper “Life beyond Distributed Transactions: An Apostate’s Opinion” [Helland]. What we call Aggregate, he calls entity. But what he describes is still an Aggregate by any other name: a unit of composition that has transactional consistency. Some NoSQL persistence mechanisms support the Amazon-inspired distributed storage. These provide much of what [Helland] refers to as the lower, scale-aware layer. When employing a distributed store, or even when using a SQL database with similar motivations, reference by identity plays an important role.
Also, we know that an aggregate is a transactional boundry. Composing aggregate objects might give ability to modify inner aggregate from parent and it might cause inconsistency.
I don't aggree with Vaughn Vernon, aggregate root object is business object ,is not any entity of ORM or database, ORM and database belongs to Infrastructure layer. Clean architecture/Hexagonal architecture is better choice of ""Implementing Domain Driven Design"".
aggregate root must has the ability to modify inner objects , its main responsibility is keep the logic consistency in a aggregate boundary.