Lazy Loading is a domain problem

Jimmy Nilson says

"I see Lazy Load as being something technical, and it is not important for the Domain Model itself."

I see Lazy/Eager Load as something very important to the domain problem. When you lazy load you can load data that is not consistent. If you lazy load an Order, first the header, then the lines, and someone adds a line in the meantime, your Order.Total won't be the sum of the lines. That can lead to important issues in your application. Matt Warren blogged about it sometime ago.

That's why DDD defined Aggregates, and IMHO that's the more interesting concept that the book introduces in the 'Domain Model' paradigm. An aggregate is a unit that needs to have internal consistency and needs to be saved and loaded at the same time. If you follow DDD then you should load aggregates eagerly, and that's a domain model level issue.

 

 

6 Comments

  • Hi Andres,



    Long time, no see! I hope all is well!



    Good point, Lazy Load is problematic. That's why I wrote:

    "Sure, this illusion creates some nasty problems, but let's not go there now."

    :-)



    I also remember Matt's blog post. Heck, I was the one proposing aggregates in the comments to that blog post as a way of dealing with the problem when Lazy Load *is* problematic.



    That said, I still don't think Lazy Load is something from the functional domain, it's a technical aspect. OK, OK, that might be just semantics and not the important thing here. And I changed the wording a bit as well.

    :-)



    Best Regards,

    Jimmy

    www.jnsk.se/weblog/

    ###

  • Isn't it just a matter of context? I mean: if 2 threads work on the same order (just an example) in memory, you can throw as much aggregates on them, but the results will never be 'correct', as the real order lives in the persistent storage.



    As it is with aggregates and functions calculating data based on other data: they're stale. When the data their results are based on changes, they are in fact 'undefined'.

  • Hi Frans,



    I was just wondering where you were!

    :-)



    Yep, I agree, but perhaps the problem then is another one? At least there is consistency within the order aggregate in memory if the whole aggregate is eager loaded. (Let's for the sake of this discussion assume that the reading has been done with a single physical database transaction, with the correct isolation level. Otherwise we just get into yet another discussion<g>.)



    What I mean is that what you describe is the general problem with copies of data. The problem of Lazy Load is more of possible inconsistency within a bunch of data.



    Your take?



    Best Regards,

    Jimmy

    www.jnsk.se/weblog/

    ###

  • I don’t think Lazy Load is not something that is part of DDD. It’s a solution for solving a performance problem. When you model your domains you should not think of using Lazy Load at the first place, it’s something that will be added later during if it’s required. Make everything as simple as possible at the first time, if you notice that you will have or have a performance issue, then add Lazy Load if that is the right solution to solve the problem.

  • Hi Frederik,



    My point is that the loading strategy (not lazy loading) is part of the domain problem. You need to load units that have internal consistency. When you say 'add lazy loading if it's the right solution to solve the problem' you probably mean that sometimes, even if you have a performance issue that could be resolved with lazy loading, you can't lazy load it. So, you need domain knowledge to make that decision.



    On the other hand, I agree with you that lazy load should be used once you get into a problem. The way people build this really depends on the O/R mapping product they use. If the product makes easier to do lazy loading, they then lazy load all the time and eager load when they have a performance issue. IMHO that's a bad thing to do.



    Regards,



    Andres



  • Andres:



    I agree with you.

Comments have been disabled for this content.