CODEWITHSUNDEEP
architecturedomain-driven-design
Jimm
Jimm

Reputation: 8505

Domain Driven Design: Aggregate root & Sub Aggregate roots

In my project, i am finding the need to break my aggregate in a hierarchical fashion, with top root level aggregate, which ensures consistency of rules at root level, and then my objects under the root, can be sub grouped into various aggregates. When calculating the integrity of root level aggregate, the root validates it's own rules and then delegates to sub aggregate's roots to determine if sub aggregate is valid.

Also, to implement optimistic locking, i am finding that if i apply locks at various sub aggregate level, i can allow my system to be highly concurrent as opposed to putting a lock at aggregate root level.

Is this a valid ddd approach?

Upvotes: 4

Views: 1215

Answers (2)

Jay
Jay

Reputation: 3

I think you can have a AggregateTree aggregate to enforce your invariants, which keeps your aggregate hierarchy with each node having the aggregate id、list of child nodes、and other necessary properties. For create、delete、update operations, update validate and update AggregateTree first, then update Aggregate.

Upvotes: 0

Jason Bunting
Jason Bunting

Reputation: 58931

I don't know enough to "know," but it sounds good to me - besides, who is "in charge" of determining such things? This industry is so full of subjectivity when it comes to buzzwords and the application thereof to a given implementation.

For me, the most important core principle of DDD is whether or not you have kept the application true to the perspective of the business people and follows the ubiquitous language as closely as possible. I can't tell that from your description, but you should be able to make that judgment well enough.

Don't get too caught up in "perfection," just the fact that you are attempting to use DDD is admirable, and if you are doing it as best you know how given the knowledge about it that you posses, I don't see why it would be an invalid approach.

Obviously, there will be those that disagree, but I wouldn't be too hard on yourself. As long as you can look back at this implementation in a month or two and see where it could've been done better, you are probably just fine. :)

Upvotes: 4

Related Questions