Domain Driven Design, can I put an Entity inside another Entity?

user_5165238 0
Viewed 76

I'm learning DDD and I've a some doubts about the entities. This is the scenario:

enter image description here

I've a Nation with 1 or more Destinations, every Destination can have 1 or more Experiences. If I delete the Nation, Destination and Experience will be deleted because they have sense only if the Nation exist. Using DDD pattern, the Nation must be the AggregateRoot, Experience should be an Entity, ExperienceCategory a Value Object. But Destination? Is an Aggreggate or is an Entity? Can I have Destination as Entity with a List of Experiences?

I'm really confused how to proceed when an Entity has a list of other Entities. In this case Destination exist only if Nation exist, same thing for Experience, this exist only if Destination and Nation exist.

Anyone can help me to understand?

Thanks!

domain-driven-design
1 Answers

can I put an Entity inside another Entity?

Having aggregates that are composed of multiple domain entities (which are loaded and stored together) is normal.

That said, the question of whether your Nation/Destinations/Experiences are one "chunk" of information that should be treated as a whole for the purpose of data changes, or several different chunks that are loaded and stored independently doesn't have a universal, cut and dried answer. You'll need to do the work of analyzing the domain to really understand how the information fits together.

My own experience is that "lifecycle" isn't actually a useful heuristic in designing aggregates, because it rarely turns out to be important to the business whether all of the different entities go away "at the same time".

Note too that there are lots of different notions that might reasonably be considered delete; removing data that was entered in error, archiving data (aka "closing the books"), responding to a GDPR "Right to be forgotten" request.

We sometimes get lazy and think "delete" when the actual requirement is "deactivate".

Part of the point of domain driven design is that, in the areas of the business where we derive our competitive advantage, nuance tends to be important. We want to take care that we understand the actual problem correctly, so that we can apply the correct solution.

user_547340
Related