Children of aggregate root when get it from database

[sbolum]

When we have an instance of aggregate object, we expect it to have all child objects are also filled.

For example if we instantiate a meeting object, we want to be sure atendees of meeting are also get.

For the code below, we get the meeting from database without including their children entities. So I expect meeting.AddAtendee to not work properly.

Am I missing something here?

thanks

[kgrzybek]

Hi @sbolum

Each collection and complex type is mapped using Owned Entity Types. It means that always everything is loaded using eager loading technique:

EF Core allows you to model entity types that can only ever appear on navigation properties of other entity types. These are called owned entity types. The entity containing an owned entity type is its owner.

Owned entities are essentially a part of the owner and cannot exist without it, they are conceptually similar to aggregates. This means that the owned entity is by definition on the dependent side of the relationship with the owner.

Please check it here:

modular-monolith-with-ddd/src/Modules/Meetings/Infrastructure/Domain/Meetings/MeetingEntityTypeConfiguration.cs

Line 55 in 4f1cf11

builder.OwnsMany<MeetingAttendee>("_attendees", y =>

[sbolum]

I missed that point. Thank you.
In this case, we are dependent to an external tool(Entity Framework) while constructing domain model.
It means that, if we decide to use dapper instead of EF, we should redesign domain model. Am I right?

[kgrzybek]

In domain-centric architectures (Clean Architecture, Onion, Hexagonal) Domain Model is isolated and it does not have any dependency on another layer or external library. This is achieved by the Dependency Inversion principle. Infrastructure and Application Layer are dependent on the Domain Model. This is a very important attribute of the Domain Model, and the lack of dependency on persistence is called Persistence Ignorance.

However, it is impossible to be 100 % ignorant of persistence. Always some part of your Domain Model will be affected, but as a general rule, it should be limited.

For example - using Entity Framework Core, each Entity must have a private, parameterless constructor, because EF Core needs them during loading data from a database. Using EventSourcing you need to store events (or return them) in an entity itself. Using Dapper you don't have information about the change (it does not have Change Tracking) so you need to always save everything (no matter what was changed - you can have performance issues).