0

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?

  • 3
    While I understand where your questions are coming from, I'm not sure there's a way to give you a concise and sensible answer. DDD is more of an approach to modeling, and less a prescription of patterns to use. Full-blown DDD is not always appropriate, although some of the principles can be applied even to simple systems. Entity Framework entities are not DDD entities; in fact EF entities shouldn't be a part of the domain model at all, but there are cases where that separation may not be worth the effort. So, IMO it's tricky to unpack all that without having an extensive discussion. – Filip Milovanović Aug 15 at 13:40
  • But maybe this will be of some help. For DDD, find a copy of Eric Evans' book, but don't focus only on the building blocks (Part 2). For navigation properties - you want to control consciously what gets loaded and when; part of that is database design, but you can also make strategic use of lazy loading ("strategic" in the sense that you make explicit decisions which navigation properties represent the boundaries) - see this. – Filip Milovanović Aug 15 at 13:42
  • Thank you Filip! I know lazy loading would be an option, but i have seperated the domain model and the persistence model, so either i would have to undo this or make custom lazy loading. – Mojo Aug 16 at 5:14
  • @Mojo, what do you mean by "separated the domain model and the persistence model"? – Alexey Aug 17 at 20:45
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.