Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Aggregate Root References Each Other #8

Closed
mstrYoda opened this issue Nov 19, 2019 · 3 comments
Closed

Aggregate Root References Each Other #8

mstrYoda opened this issue Nov 19, 2019 · 3 comments

Comments

@mstrYoda
Copy link

@mstrYoda mstrYoda commented Nov 19, 2019

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.

@banq

This comment has been minimized.

Copy link
Owner

@banq banq commented Nov 19, 2019

"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.

@mstrYoda

This comment has been minimized.

Copy link
Author

@mstrYoda mstrYoda commented Nov 19, 2019

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.

@banq

This comment has been minimized.

Copy link
Owner

@banq banq commented Nov 20, 2019

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.

@banq banq closed this Dec 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.