应该在哪一层通过事件源实时读取 DDD 中的模型（投影）？

Question

在典型的 DDD 架构中，我们有 3 层：

域- 无参考

应用程序- 它引用了域层

基础设施- 它引用了域层

（+ Web / UI 项目）

领域模型当然存在于领域层中。但是应该在哪一层实时读取读取数据库的模型（投影），例如 MongoDb？

Answer 1

没有成文的法律规定读取模型应该存在于哪个项目中。在我个人看来，我认为拥有一个单独的读取模型项目有它的好处。通过命令查询责任分离，如果应用程序的命令部分可以访问应用程序的查询部分，事情往往会变得非常混乱。我认为这两者应该明确分开。

我花了一些时间研究一个示例项目，该项目演示了如何设置 DDD/端口和适配器/CQRS 应用程序。我已将代码放在 GitHub 上：https ://github.com/appie2go/steal-this-code

我还花了一些时间在以下文章中详细解释了我所做的选择：

• https://medium.com/@abstarreveld/implementing-dddomain-models-ports-adapters-and-cqrs-with-c-2b81403f09f7以及，
• https://medium.com/@abstarreveld/dddomain-models-ports-adapters-and-cqrs-reference-architecture-c-504817df65ec

希望能帮助到你！

干杯

Answer 2

简而言之，应用程序服务（应用程序层）和存储库（基础设施层）都知道 READ 模型。域层对底层持久性和加载机制保持透明。

长答案，确切的使用机制取决于您如何使用读取模型。您可以使用它们来构造域层中使用的对象，或者更常见的是，仅作为对 API 查询的响应。

第一种情况：使用Read Models作为领域层的对象

应用程序服务将 READ 模型从存储库加载到域实体中。存储库负责将 READ 模型正确填充到域实体中。存储库还负责将域实体转换为 WRITE 模型以保留在主数据库中。

当您到达域模型时，对象已经在存储库的帮助下加载到内存中。因此，领域层甚至不知道 READ 模型和 WRITE 模型；它只处理域实体。

第二种情况：使用读取模型存储对 API 查询的预构建响应

此场景是 READ 模型的更典型使用。通常，同一实体/聚合有多个读取模型，因为它们是针对特定 API 请求定制的。

在这种情况下，我们甚至不触及域层。应用程序服务接受请求，使用 READ 模型存储库加载对象，并向应用程序服务器返回响应。