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.
2
votes
could you define a requirement ?
- Stephan Schinkel
The question is how you handle performance issues in DDD. OrderLine is a child of Order AggregateRoot and a Order could have 20000 of lines(products). That OrderLines had to be eager loaded when a Order is loaded
- JPP
why do they have to be eager loaded ? please define an actual or fictional requirement. no one says you have to eagerly load something you could lazy load or load something entirely aggregated. no one will tell you we have to load those 200.000 orderlines because we want to display them on a webpage. there are limits to everything - therefore could you please elaborate on a definitive requirement ? performance issues are handled in your repository (optimize queries) or in your domain (optimize object iterations) or in your service layout (do i need to know every orderline in my viewdatabase)
- Stephan Schinkel
Orders with 20K lines, really? Get your head examined.
- Yves Reynhout
@Yves Reynhout if you really understood the question you should get an answer like the next one...20k of lines was an example to explain the issue
- JPP
1 Answers
5
votes
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.
