The question that has been on my mind ever since we discussed the developer of the future in Switzerland earlier this year. While I am still struggling with my own ideas and thoughts to answers this question I know one thing for sure. Irrespective of my answer, it will influence my development as a software developer.
InfoQ published the excellent JAOO panel where Martin Fowler, Jimmy Nilsson, Dave Thomas, Frank Buschmann and Steve Cook discuss the future of software development. Highly recommended!
Ayende’s example calculates the cost for an order. For this it needs the order lines associated with the order. Udi brings up an interesting fact about Ayende’s implementation. The order service knows a whole lot about the implementation details of the calculate cost operation on the order. Valid point! For this it optimizes the fetch query for this particular order so that all of the associated order lines are loaded as well. This solution is acceptable only if optimization is an absolute necessity.
I am not so keen on the suggested alternative solution. Cluttering the domain model with different fetch strategies for specific use-case scenarios is a bad idea. I know, I have been there myself!
It is very unlikely that we care about those order lines outside of the context of that particular order. What this example lacks is a clear boundary. We can do this by imposing ownership of the order by marking of the scope for calculating the cost. Order is then acting as the aggregate root and the order line is within its boundary. Since order is an aggregate and should maintain consistency it is loaded eagerly.
A tight connection with the problem domain at hand makes giving good examples for explaining Domain-Driven Design so hard.