I'm just getting started in DDD, and I'm having some trouble figuring out how to accommodate the relational nature of my data. I have what I believe would be considered my aggregate root, but the aggregate also has an aggregate of its own. Not wanting to violate the Law of Demeter, I'm wondering if I'm thinking about this wrong and am hoping that some DDD expert can offer some insight.
My aggregate root is my Account
object, which has an aggregate of numerous AccountElement
entities, which are themselves logical groupings of individual ProductComponent
entities.
An AccountElement
outside of the context of an Account
has no meaning, so I'm comfortable with my conclusion that the Account
object is my aggregate root, and I anticipate that entity having an aggregate Elements
property. It's the ProductComponent
collection that has me confused. This aggregate has no meaning outside of an AccountElement
, and really has no meaning outside of an Account
.
I don't think I should be accessing individual ProductComponent
objects by dotting my way to it, like:
var reference = account.Elements(0).ProductComponents(0).ReferenceCode;
But at the same time it doesn't make sense (from a domain perspective) to access a ProductComponent
directly from an Account
entity.
I'm sure that this is all a little difficult to comprehend without knowledge of my domain, but I'm hoping it's enough to get some good feedback.
[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.
Each Microservice uses its own database to persist data of domain model of a Bounded Context. A single Bounded Context can include many aggregate roots, or we can organise a single aggregate root into a single Bounded Context.
A DDD aggregate is a cluster of domain objects that can be treated as a single unit. An example may be an order and its line-items, these will be separate objects, but it's useful to treat the order (together with its line items) as a single aggregate.
An AGGREGATE is a cluster of associated objects that we treat as a unit for the purpose of data changes. Each AGGREGATE has a root and a boundary. The boundary defines what is inside the AGGREGATE. The root is a single, specific ENTITY contained in the AGGREGATE.
The article Robert linked to is a good one. I would add that if ProductComponent exists only in the context of AccountElement and AccountElement exists only in the context of Account, then by extension ProductComponent is in the context of Account.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With