从DDD: Tackling Complexity in the Heart of Software（第177页）：
添加处理事件时需要更新交付历史记录 Cargo AGGREGATE参与了交易。
a）在页面的下方，作者确实提出了一个替代解决方案，但仍然 - 在上面的摘录中不是作者，基本上建议我们通过DeliveryHistory.Events属性来实现关联每次访问属性时，都要查询数据库（通过 repository ）？
b）由于作者“提议”的实现几乎与延迟加载的实现方式相同（但延迟加载仅在第一次查询数据时例外）需要它，然后缓存它），我也会问以下：
许多人反对延迟加载，但无论如何，我认为如果相关实体驻留在相同的聚合中，我们绝不应该使用延迟加载，因为这样的关联用对象引用表示，这是在我们需要事务完整性时实现的？
如果相关数据永远不会被访问（因此永远不会被检索），因此完整性可能会受到损害，因为不变量可以修改聚合时是否正确执行？
更新
a）
可以在加载时加载DeliveryHistory.Events集合 DeliveryHistory实体由存储库加载。它也可以 通过延迟加载加载，在这种情况下，ORM注入一个集合 迭代时调用数据库的代理。
但是作者不是提出第三个选项，即每次访问DeliveryHistory.Events时查询事件（或者每次调用DeliveryHistory.GetEvents()时）？< / p>
b）
它类似于延迟加载，但重要的区别在于 求助于存储库查询允许省略事件 对象模型中的属性。这减少了“足迹” DeliveryHistory实体。
我 - 我假设“类似于延迟加载”你指的是每次从数据库中检索事件的设计要求？
II - 无论如何，如果我们省略DeliveryHistory.Events属性（并且可能没有定义为DeliveryHistory.GetEvents()的替代），那么我们如何实现作者提出的设计（如我所述）原帖，我知道在页面下方的作者确实提出了更好的选择）？
谢谢
答案 0 :(得分：1)
a）存储库加载DeliveryHistory实体时，可以加载DeliveryHistory.Events集合。它也可以通过延迟加载加载，在这种情况下，ORM会注入一个集合代理，迭代时会调用数据库。
b）它类似于延迟加载，但重要的区别在于求助于存储库查询允许省略对象模型中的Events属性。这减少了DeliveryHistory实体的“足迹”。
延迟加载的问题不是数据可能永远不会被访问，而是第一次访问延迟加载的属性将导致数据库调用，并且您必须确保连接仍然存在。从某种意义上说，这可能会损害聚合的完整性，这应该被视为一个整体。
<强>更新
a）无论哪种方式，净结果都是一样的。我不确定创建代理集合是否是编写本书时使用的技术（2003）。
b1）是的，它们的相似之处在于事件不与DeliveryHistory实体一起加载，而是仅在需要时加载。
b2）代替DeliveryHistory实体上的events属性，可以通过调用存储库来访问事件。存储库本身将由周围的应用程序服务调用。它将检索事件并将它们传递给需要它们的地方。或者，如果用例是添加事件，则应用程序服务将调用存储库以保留事件。