order.LineItems.Count;

Obviously, it would be quicker to just get count(*) from the db if the list is not yet loaded.

As far as getting the data you need when you need, Udi Dahan had some interesting ideas regarding fetching strategies. Never tried that approach, we just use eager fetching queries when we need them, but you might want to give it a look.

Would an approach where we could explicitly say to a repository, at a high (as in DDD driven) level, give me this aggregate along with these associated aggregates be better?

@Jarod
Totally agree with your point, when you load an aggregate you *should* get the whole thing. I tend to view lazy loading as more useful between aggregate roots though.

That’s a great perspective. Not every fetch / db call are created equal. Use your judgment and design appropriately.

Thanks

While I agree that some things should be very explicit, having persistence concerns leak into your model (AHEM entity framework) is a bad idea.

I think your example is great and fits the subject of the post well. Yes, I do think that lazy loading violates DDD concepts. Another principle to consider here is Command-Query-Seperation. (I think?)

IMO, when I hit a repository, I want all the data for that aggregate. I want to be explicit with my query, I want to know exactly what I send to my db and when. If its too much data to get, then I say the aggregate is too big, or I am using the wrong one in context.

I agree with Kerry here, I see LL more and more as bad practice. (There may be some limited scenarios where it is useful)

Lazy loading can be a curse. As with your statement, I used to think it was ‘sooo cool’, but have since changed my mind. This mainly from working with distributed domains, and in pre-ddd days, working with teams who abuse lazy loading, just walking a graph sending endless queries to the db causing nasty perf issues… its, well, Lazy!

That’s a very good point. It’s always important to remember we don’t live in a perfect world and using property behavior may be an acceptable tradeof.

Thanks

Another consideration is true separation of concerns – if the business rules surrounding the loading of the property change, there is no indication to the consumer of this at all. Even if the property is lazy-loaded by calling an appropriate repository method, the existing code is still impacted with no indication to the developer that a change has been made.

I agree with you, it is a poor example and I knew it as I was writing it. Please look beyond the specific example and think about how we use Properties to lazy load. Do you think we are hiding important information from developers by lazy loading a Property?

IMO, the example above w/lazy loading is a smell the developer is using the wrong aggregate/repository for the job. If the developer doesn’t need the line items at the time, it is likely they are really dealing with a different aggregate, such as Customer.Orders, where the customer repository would not load line items.

This would become very apparent once you begin to distribute data accross bounded contexts, whether its messages or crud/sync.