Q:

Does snapshot change tracking break DDD principles?

I'm building a website with MVC 5 and Entity Framework 6, implementing the Unit of Work & Repository patterns, and - for flexibility and performance - would like to utilize Entity Framework's snapshot change tracking rather than proxy change tracking. The drawback of this feature is that navigation property fix-up is not done until DetectChanges is called by DbContext.
Adding an item to a collection...
order.LineItems.Add(orderLineItem);

The inverse association will not be updated until DetectChanges is called...
lineItemOrder = orderLineItem.Order; // lineItemOrder == null
dbcontext.DetectChanges();
lineItemOrder = orderLineItem.Order; // lineItemOrder == order

This navigation property fix-up behavior seems too specific to Entity Framework for the level of abstraction I'd like to see. Does this behavior break principles of Domain Driven Design, or can DetectChanges be considered a business transaction?

A:

It clearly not a business transaction, as one would expect lineItemOrder.Order to be readily populated without needing to call separate method, 
With this approach not only it would be hard to debug, the domain model is not working as one expect it to work.
When designing a domain model one should try to keep domain model clean from supporting frameworks such as persistence.
personally I would not use 
order.LineItems.Add(orderLineItem);

when designing a domain model, instead I would use 
order.AddLineItem(orderLineItem);

and make the order.LineItems readonly
If it is possible to encapuslate the dbcontext.DetectChanges();inside the method AddLineItem it would be a better domain model even though it's not the optimal design,

