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.
