使用没有分离服务和存储库的 CQRS 真的会影响代码质量吗？

Question

我想问一下WEB Api架构。我的项目由少量 DDD、CQRS（无 ES）微服务组成。每个服务都有域、应用程序、基础设施和 UI 层。对于此示例，我将使用 BikeMicroservice。它在 UI 层中有 BikeController，它向 MediatR 发送命令或查询对象。在应用程序层中，我定义了处理程序（对于每个 C 或 Q），它们使用相同的 BikeService 对象来执行 C/Q。此外，BikeService 具有 BikeRepository，它也使用 EF Core DbContext 对象执行命令和查询。

它是合适的 CQRS 设备吗？

我担心服务和存储库对象是否真的应该执行查询和命令。我在项目中观察到的唯一优点是控制器更薄（仅发送查询或命令）。

如何升级微服务架构？

我应该将 DAL 和服务划分为使用 EF Core 的 BikeCommandRepository 和使用 Dapper 的 BikeQueryRepository 吗？

Answer 1

诚然，我不是一个资深的软件开发人员，但最近几个月我对这个主题思考了很多，以下是我的观察和结论。

您认为 CQRS 比将一些 MediatR 使用的类前缀为“命令”、将其他类前缀为“查询”更复杂，这是完全正确的。

不幸的是，由于某种我不明白的原因，人们最近开始将 MediatR 与 CQRS 等同起来，尽管 Jimmy Bogard 通常在垂直切片架构的背景下谈论 MediatR 。

垂直切片

一般的好处来自于这样一个事实：您正在创建垂直切片，而不是使用传统的、分层的、服务密集型的方法。这将用例彼此解耦，减少了由于共享服务而导致各种操作之间有问题的隐式依赖关系所产生的错误和复杂性。

这是一种基本模式，您可以在简单的应用程序中实现而不会遇到太多麻烦，并且可以说在任何地方都能提供一致的好处。

连续QRS

另一方面，CQRS 需要为查询和命令创建并行数据访问结构，并且还可以选择创建并行模型。这本质上增加了复杂性和开销，并且一般来说，它提供了更简单的系统......

• 没有性能优势，因为您不必独立扩展读取和写入。

• 没有结构上的好处，因为您不需要例如两个独立的开发团队独立处理读取模型和写入模型。

唯一适用的好处是更容易推理操作，因为它们是单独封装的，也称为命令模式。但仅使用垂直切片您就已经获得了这种好处。

（老实说，我认为 MediatR 应该被称为 CommandR。它实现了命令模式，而不是中介模式。）

因此，您应该问自己的是，通过增加复杂性和开销，当前在您的特定用例中可以获得什么样的优势。

关键点：

1. CQRS 并不是软件架构中一个基本的、普遍关注的问题，例如 SOLID 和（可以说）垂直切片。

2. 如果优势不明显，大多数查看该代码库的经验丰富的开发人员都会将其 CQRS 方面视为对代码质量的干扰和臃肿。

3. 当使用垂直切片和 MediatR 时，很容易在实际需要时实现 CQRS 关注点。这进一步降低了以表面上的方式增加复杂性的理由。

所以，我个人的建议是：

1. 继续对命令和查询使用相同的存储库，放弃您正在执行“CQRS”的想法，但作为语义细节，继续将这些IRequest类称为“命令”和“查询”。

2. 当您遇到这样的情况时，您发现给定实体上的查询需要针对您面临的负载独立扩展，您可能需要使用单独的数据库或 Dapper 而不是 EF Core，和/或不同的数据库模型，然后为系统的该部分实现并行 CQRS 结构。而且，随着项目的发展，请严格根据需要扩展 CQRS 结构。

当然，如果您只是想创建一个示例项目来探索 CQRS，那么请继续实施对您的学习体验有用的任何内容。