In the last days i'm making a sample application to apply/study DDD. One of the principles of DDD(Please correct me if I'm wrong) is that all the changes to an entity should be made through the Aggregate Root(AR) and an AR should be loaded with his child entities. In this way is eaiser to validate Aggregate consistency. There is only a little big detail that is bothering me. I'm not able to understand how DDD is dealing with performance issues. Imagine that i have an Order(AR) that have, let say, 20000, 30000 of OrderLine. Performance issues would exist eager loading a lot of child records. Saying Order as AR you can imagine another scenarios where this can happen. I'm looking forward to read you opinion about this subject.
DDD isn't always free from technical considerations. If you have an AR that can contain a very large number of child entities, consider if you can make the child entities ARs in their own right. This decision has to be made while taking eventual consistency into account.
In your provided example, consider whether the Order AR really needs to reference OrderLine entities in the first place in order to maintain integrity. If it does, consider making OrderLine an AR on its own, in which case you may have to deal with eventual consistency. Of course, if you make OrderLine an AR, you application logic will change, because an operations that need to be performed on the OrderLine will have to go through the OrderLineRepository to access the OrderLine instead of going through the Order AR.
For more on this, check out Effective Aggregate Design by Vaughn Vernon.
来源：https://stackoverflow.com/questions/12179348/ddd-performance-issue-eager-loading-ar-child-entities