Domain Driven Design // Navigation Properties and Aggregate

Question

I'm currently making a REST API, using DDD. As ORM i use Entity Framework Core, this ORM has easy mappings for navigation properties, as you sure are familiar with.

My question is about navigation properties and aggregates, what's your take on navigation properties inside the domain model?

Next question is about aggregates, so let's say i have an Order aggregate, which contain OrderLines, then it should only be allowed to insert OrderLines through this aggregate, right? And then send the aggregate to an repository, for example?

Lets say i have Customer as a navigation property inside the Order, then if i were to add and OrderLine, i have to retract the Order, resulting in me also retrieving the Customer. And if the case was that Order had 15 navigation properties, what would be the affect on the performance?

Answer 1

Disclaimer: I am not familiar with Entity Framework Core. I am familiar with Hibernate and Active Record ORMs, though.

what's your take on navigation properties inside the domain model?

First of all, Evans (originator of DDD) suggests to limit associations to be single directed, for clarity and simplicity of implementation. Also he says, that using navigation or db lookup is a "design choice".

So I think, that (single-directed) navigation properties are preferable within aggregate. In other cases you should consider case-by-case how navigation-vs-lookup affects your design: coupling, clarity, simplicity.

resulting in me also retrieving the Customer.

Provided that Customer is clearly not a part of Order aggregate, it makes sense to have it lazily loaded. Or to replace 'navigation property' with explicit db lookup.

i have separated the domain model and the persistence model, so either i would have to undo this or make custom lazy loading.

I think that if you have some ORM annotations on your domain object, it is not a big deal. AFAICT, there is also partial classes feature in C#, so you probably can have ORM part separated from domain part. To maintain a certain level of domain layer purity.

As a meta-comment, I think that the main goal of DDD in context of implementation is to keep business logic clearly expressed (that is you can easily see the intended business logic behind the code) and separated from other concerns. So that to keep domain code understandable and align with the intended model. You start with that you go as far in that direction as you can. When you see that the most pure approach conflicts with something like performance, you do the adjustments, that minimally distort the clarity of the business logic, while achieving the performance goals.