domain-driven-design - 如何在存储库之间进行通信

Question

据我了解，Repository 之间存在 1-1 关系。和 AggregationRoot .
假设我有一个 AggregationRoot_A属性持有 AggregationRoot_B 的 id .
我会有Repository_A和 Repository_B .我在哪里处理需要来自 AggregationRoot_A 的数据的查询对象和 AggregationRoot_B目的？。
获取所有AggregationRoot_A对象并一一获取 AggregationRoot_B处理它们的对象很疯狂，因为操作可以通过简单的 join 来完成。或数据库端的任何东西。
所以，我的问题是，我在哪里可以处理涉及来自 2 个聚合根相关的数据的操作。

Answer 1

There is a 1-1 relation between a Repository and a AggregationRoot.

是的

Where do I handle a query that needs data from AggregationRoot_A object and AggregationRoot_B object?

目前对此的看法通常是完全绕过领域模型，尽可能高效地查询数据库。
如果你愿意的话，回想一下聚合的早期定义(Evans，2003)

An aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes.

如果我们不尝试更改数据，那么我们不需要“聚合”来确保更改正确完成。我们只需要一种方法来获取当前支持聚合的信息，并将该信息转换为我们想要的报告。
作为技术问题，您可以在与数据存储紧密耦合的基础架构代码和不应该耦合的应用程序代码之间创建清晰的边界。这样的外观可能看起来有点像聚合体。关键区别在于，在这种情况下，外观无法更改底层数据。
换句话说，这个外观可能表面上看起来像一个存储库，但它会缺少一些关键元素——不能添加新对象，没有类似保存的功能，也没有支持更改的对象。
执行查询时，您使用的是不可变值，而不是可变实体。

the response of this pseudo-repository should be an instance of some domain class? or it's just a plain object? Should I create an specific class for the items in this report query?

其中任何一个都可能是正确的答案。在您只是生成报告、网页、html 文档的情况下，将原始数据复制到最终表示中而不搞乱仪式通常是有意义的。类(class)用马。

the response of this pseudo-repository should be an instance of some domain class? or it's just a plain object? Should I create an specific class for the items in this report query?

好吧，你真正想要从伪存储库中得到的是一个内存数据结构，你可以(a)按原样序列化，或者(b)转换。
如果您正在准备通过网络发送该信息，那么您可能需要尽可能少的仪式 - 如果您可以将记录集直接转换为信息的在线表示，完美 -尝试一遍又一遍地将信息移入和移出“对象”可能不会使您随着时间的推移更容易维护代码。
当您将该信息用作其他内容的输入时，您更有可能希望将信息包含在角色接口(interface)的某些实现中，以便消费者不会过于紧密地耦合到它不关心的数据结构关于。