CODEWITHSUNDEEP
domain-driven-designddd-repositoriesaggregateroot
Amr Elgarhy
Amr Elgarhy

Reputation: 68912

Should I CRUD the child Aggregates through Aggregate root - Repository Pattern DDD

I was reading some articles and watching some tutorials to refresh my DD knowledge, all of them mention that we should build Repositories just for Aggregate root entities and this makes full sense to me.

For example if we have Products and Variants entities, Product is the Aggregate root in this case so the repo should be just for the Product entity.
If we want to CRUD the variants we should do that through the product repo.
That's make sense because a variant has no meaning without a product.

Now in the admin section of the system, we will need an admin page just for Variations, to let administrators to Add/Edit Variants which has nothing to do in this case with any products.
For example admins need to add Variants like:
- Color: Red
- Size: XL - ..

And then later while creating products they can just attach these variants to the new product.

My Question:
For this admin page backend
- should its logic keep accessing the Variants through the Products repo?
- Or should we have another Separate Aggregate which has the Variant as a root?
- or should we break the rule and create a repo for the Aggregate Variant which has Aggregate root Products?

This example might be simple but in real there are many entities with same case as variants in our system such as stocks, variables,.. and they will all need admin pages same as the variants one.

Upvotes: 1

Views: 605

Answers (1)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57249

If different instances of the Product aggregate need to share data about a particular Variant, then Variant needs to be considered outside of the Product aggregate.

So you would normally find that you have a Products repository, where products may include references to a Variant identifier, which can be used to look up the variant when necessary.

Methods in Product which need (a stale copy of) the state of its variant normally have a "Domain Service" argument in the method signature; the domain service would have methods that accept the variant identifier as an argument and return a recent copy of that data.

Adminitration of the Variant collection would normally be done without reference to Products.

Upvotes: 1

Related Questions