是否依赖延迟加载代码异味？答案

【问题标题】：Is depending on lazy loading a code smell?是否依赖延迟加载代码异味？
【发布时间】：2013-12-28 22:59:30
【问题描述】：

在我对 DDD 的短暂体验中，我经常发现自己希望使用某种类型的延迟加载机制来解决一些可能加载大型嵌套数据集的危险情况。

但过了一段时间，我意识到每次都是聚合根设计不当的症状，它承担了过多的责任。此外，过去应该完全加载聚合以执行一致性操作。习惯使用 Entity id 会让事情变得稍微容易一些。

所以过了一会儿，我想知道......延迟加载是否有代码味道？难道只是建立非成熟模型而不会造成大问题吗？

【问题讨论】：

你应该阅读 Vaughn Vernon 关于有效聚合设计的文章：vaughnvernon.co/?p=139
我在尝试搜索 YouTube 网站明显延迟加载观看历史记录删除后发现了这个问题。在 Google 上搜索了 延迟加载反模式（笑）。无论如何，我只是想让你知道，你提出了一个我认为我从未考虑过的绝妙问题。我想我迟到了 7 年零 4 个月的比赛哈哈哈。无论如何，干杯！编辑：哇！这个网页在我保存评论后立即更新为“7 年零 3 个月前”！别操你。让我想知道 Chrome、Google (Alphabet) 和 Stack Exchange 之间进行了多少延迟加载。

【解决方案1】：

我的简短回答：是的！

延迟加载和其他获取策略表明域模型正在用于执行查询。这是不应该做的事情。一个简单的查询层最适合那个目的。所以，在我看来，你得出了正确的结论:)

领域模型应该只包含当前的事务状态。这意味着，通常不应该有大数据集，因为这些对于历史数据来说更为常见。但这并不意味着历史数据不能用于创建新的交易汇总。

【讨论】：

就在几天后，我遇到了这样一种情况，让我松了一口气，我强迫自己仅通过 ID 引用实体，并避免使用延迟加载隐藏查询。虽然延迟加载会阻止将巨大的嵌套数据集加载到内存中，但它更容易遇到将实体序列化为巨大文档（如用于 Web 界面的 JSON）的问题，并且不得不“重新考虑”一个额外的模型来导出我的域层之外的数据。