CODEWITHSUNDEEP
domain-driven-design
AlexL
AlexL

Reputation: 73

Can an AggregateRoot be a child to an Entity in DDD (Domain-Driven Design)?

I inherited a project that is using Domain-Driven Design architecture and I know very little about DDD. I have been reading a lot of blogs and literature on it. Currently, I have 3 domain models with the following graph relationship: Parent --> has many Children --> has many GrandChildren. I am using EF Core 2.1 to establish the relationship and to persist data into the database.

My question is: Is ok to have the relationship below for DDD

Problem: I cannot save a new grandchild to the existing child.

Parent as AggregateRoot ==> Child as Entity ==> GrandChil as AggregatRoot

I can save the "child" through the existing "parent" using parent.add(child) and the data persist into the database without any issue.

For the "grandchild", I use a similar approach by:

  1. Get the existing parent and then get the existing child

  2. Add a grandchild to the existing child [child.addNewGrandChild(new_grand_child)]

  3. UnitOfWork.Complete [this is where it throws an exception but I just cannot capture the exception using Try/Catch]

Upvotes: 1

Views: 732

Answers (2)

AlexL
AlexL

Reputation: 73

I solved my problem by converting the Grandchild class to Entity instead of AggregateRoot. Once I did that, everything worked. In other words, I was able to persist the data through the Parent.

I am so new to DDD that I have not grasped all the concepts yet. I inherited the project and was overwhelmed with the amount of code I have to write for a domain model, factory methods, and business logic for a simple task.

Upvotes: 0

Louis
Louis

Reputation: 1241

Understand that DDD done correctly will not place any restrictions on the database and conversely, the database won't place any on DDD or its' models.

Grandchildren should not be aggregate roots. When you have something like that, it's more than likely that you are missing a Context in your domain and/or the boundaries are improperly defined.

Keep in mind that the DDD concepts of relationships has got nothing to do with the database's and fk's. As far as DDD is concerned the database is modeled as an opaque storage dependency for the entire system.

Upvotes: 0

Related Questions