据我了解，Repository 和 AggregationRoot 之间存在 1-1 关系。
假设我有一个AggregationRoot_A，其属性包含一个AggregationRoot_B 的ID。
我将拥有Repository_A 和Repository_B。我在哪里处理需要来自AggregationRoot_A 对象和AggregationRoot_B 对象的数据的查询？。
获取所有AggregationRoot_A 对象并一个接一个地获取AggregationRoot_B 对象来处理它们太疯狂了，因为可以使用简单的join 或数据库端的任何东西来完成操作。
所以，我的问题是，我在哪里可以处理涉及来自 2 个聚合根相关的数据的操作。
【问题讨论】：
标签： domain-driven-design ddd-repositories
Repository 和 AggregationRoot 之间存在 1-1 关系。
是的
在哪里处理需要来自 AggregationRoot_A 对象和 AggregationRoot_B 对象的数据的查询？
目前对此的看法通常是完全绕过领域模型，尽可能高效地查询数据库。
如果你愿意的话，回忆一下聚合的早期定义（Evans，2003）
聚合是关联对象的集群，我们将其视为一个单元以进行数据更改。
如果我们不尝试更改数据，那么我们不需要“聚合”来确保正确完成更改。我们只需要一种方法来获取当前支持聚合的信息，并将该信息转换为我们想要的报告。
作为技术问题，您可能会在与数据存储紧密耦合的基础架构代码和不应该耦合的应用程序代码之间创建清晰的界限。这样的外观可能看起来有点像聚合体。关键区别在于，在这种情况下，外观无法更改底层数据。
换句话说，这个外观可能表面上看起来像一个存储库，但它会缺少一些关键元素 - 无法添加新对象，没有类似保存的功能，也没有支持更改的对象。
当您执行查询时，您使用的是不可变值，而不是可变实体。
这个伪存储库的响应应该是某个域类的实例？或者它只是一个普通的对象？我应该为此报告查询中的项目创建一个特定的类吗？
其中任何一个都可能是正确的答案。在您只是生成报告、网页、html 文档的情况下，将原始数据复制到最终表示中而不搞乱仪式通常是有意义的。课程用马。
这个伪存储库的响应应该是某个域类的实例？或者它只是一个普通的对象？我应该为此报告查询中的项目创建一个特定的类吗？
嗯，您真正想从伪存储库中取出的是一个内存数据结构，您可以 (a) 按原样序列化，或 (b) 转换。
如果您正在做的是准备通过线路发送该信息，那么您可能希望尽可能少的仪式 - 如果您可以将记录集直接转换为信息的在线表示，完美——尝试一遍又一遍地将信息移入和移出“对象”可能不会让您随着时间的推移更容易维护代码。
当您将该信息用作其他内容的输入时，您更有可能希望将该信息包含在某个角色接口的实现中，这样消费者就不会过于紧密地耦合到它没有的数据结构不在乎。
【讨论】：