如何组织实现CQRS和DDD的依赖项

Question

我尝试使用CQRS方法来实现DDD服务。我没有使用事件源。所以我有3层:应用层、基础结构层和域层。许多人说，你可以绕过域名进行查询，这是可以的。例如，假设这对我来说是必要的，因为性能问题。

在忽略持久性之后，我在基础架构中实现了存储库。正如我在DDD和books的所有实现中看到的那样，基础架构不应该依赖于应用层。

那么我需要从存储库返回什么呢？？如果DTO(Read models，View models，实际上无关紧要)是一个应用程序关注点。将它们放在基础架构层上会形成从应用程序到基础架构的循环依赖关系，反之亦然。但是实现查询逻辑(如果我使用Orm，它通过编写原始SQL进行查询)是一种糟糕的方法，因为出于这个目的，我们在基础设施中创建了存储库(这就是https://github.com/dotnet-architecture/eShopOnContainers的方式)。

另一种方法是从存储库加载聚合，然后将其转换为DTO，但由于我的虚构问题，这是不可能的。那么如何以正确的方式处理这个问题呢？(这就是https://github.com/JasonGT/NorthwindTraders/的方式)

Answer 1

如果您想遵循Robert C.Martin的Clean Architecture，您应该将稳定的业务规则(较高级别的抽象)与不稳定的技术细节(较低级别的详细信息)分开，定义清晰的边界。您的源代码依赖项应该只指向内部，指向更高级别的策略。要实现这一点，请使用依赖倒置原则。在您需要的层中为存储库定义接口。然后在基础架构层实现这些存储库。

这意味着应用层不应该依赖于基础架构层。但基础架构层可以依赖于应用层(基础架构可以使用应用程序)。

Answer 2

理想化的读取模型看起来很像缓存--您获得一个查询，使用该查询计算缓存键，并返回使用该缓存键存储的字节。

缓存未命中时会发生什么情况？然后，您必须查找数据，并计算返回的字节数。

因此，您要尝试实现的是从持久存储中获取所需的状态，然后将该状态转换为调用者能够理解的序列化表示，而不会产生不必要的麻烦。

例如，假设有一个web，客户端向您传递一个目标uri，并期待一个application/json响应。您的有状态数据存储是一些关系型数据库管理系统，因此您可以使用现成的sql客户机来执行查询，从而生成一个ResultSet。然后，您可以使用类似于DOM构建器的工具来构建树，迭代结果集中的行，并将数据列复制到树中。当树完成后，您将使用json库来为树额外添加一个UTF-8表示。Tada，您已经获得了响应的表示形式，您可以将其保存在缓存中并返回给客户端。

如果您更习惯使用O/RM，那么可以定义一个内存中的对象表示，让O/RM考虑创建结果的内存中表示，然后将其传递给JSON反序列化库。

这里的要点是，这个转换组件需要了解如何解释从持久存储中检索到的值，以及如何在客户端可以理解的表示形式中表示该值--但是您不需要实体。您“只是”接受消息并将其转换为其他消息。

根据翻译的哪些部分是稳定的，哪些部分需要替换，您可能会有许多有用的设计中的任何一个。但是您的翻译实现不需要依赖于您的编写模型的实现细节。

Answer 3

正如我在DDD和books的所有实现中看到的那样，基础架构不应该依赖于应用层。

这根本不是事实。基础设施依赖于应用层。看看Vaughn Vernon的红皮书IDDD的图4.3 (第124页)。

例如，横切服务(身份验证和授权、事务等)在应用层定义，而实现在基础架构中。

那么我需要从存储库返回什么呢？？如果DTO(Read models，View models，实际上无关紧要)是一个应用程序关注点。将它们放在基础架构层上会形成从应用程序到基础架构的循环依赖关系，反之亦然。但是实现查询逻辑(如果我使用Orm，它通过编写原始SQL进行查询)是一种糟糕的方法，因为出于这个目的，我们在Infrastructure中创建了存储库

如果您使用的是CQRS，那么Querys就有不同的模型。存储库是Command模型的一部分。在Q模型中，您在应用层定义所需的查询，返回客户端所需的对象(例如视图)。查询的实现是在基础架构层，直接使用SQL。