在DDD中，聚合的根是检索其子对象的唯一引用。聚合根的存储库负责仅提供根对象引用。如果我需要子对象，则需要调用聚合的getter方法来检索导致数据库查询的子对象。
考虑我从DB检索多个聚合的情况。因此，在我的情况下，这种情况导致多个数据库查询，这导致非常慢的请求。如何在DDD方面避免这种情况。为了坚持下去，我遇到了一个名为Unit Of Work的模式。是否有任何搜索模式可以解决我的问题或任何其他方式来解决这个问题。
答案 0 :(得分：1)
首先，您的ORM解决了95％的问题（如果您碰巧使用关系数据库）。
聚合根存储库应该（在大多数情况下）返回包含所有子对象（实体）的完全加载的对象。延迟加载儿童应该是一个例外，而不是规则。
另一件事是，您应该避免一次加载和持久化多个聚合。尝试重新分区您的域，以便每个用户互动只处理一个聚合。
考虑一个文档数据库解决方案。它确实使整个聚合作为文档存储在doc数据库中。
答案 1 :(得分：0)
似乎你有一个场景，你在一个用例中想要从几个AR读取并且还将它们的状态保存到DB中。读取操作需要很长时间吗？还是需要时间读写？
您的域模型和聚合根应该通过用例的交互来部分定义。我所说的是，该模型的设计应符合您的客户需求。这种情况似乎不适合您的模型。
使用大数据视图的报表或其他操作应绕过域模型。不要将DDD用于报告等。只需快速访问数据。
二。如果您希望所有聚合参与交易，工作单是一种方法。
第三。我会说，使用延迟加载，但是一些需要性能提升的用例你可以做一个加载策略，这意味着你让root加载一些子集合，而不需要sql-sub-selection烧... 看看这篇文章http://weblogs.asp.net/fredriknormen/archive/2010/07/25/loading-strategy-for-entity-framework-4-0.aspx（甚至它的EF模式也适用于NH ORM）
然后最后你总是可以提供db索引，缓存等来提升性能，但是考虑到场景信息，你有一种错误的设计方法。我没有所有的事实，但也许一些用例不适合