在 eShopOnContainers 中的 DDD 微服务中应用 CQRS 和 CQS 方法

The design of the ordering microservice at the eShopOnContainers reference application is based on CQRS principles. However, it uses the simplest approach, which is just separating the queries from the commands and using the same database for both actions.

eShopOnContainers 参考应用中订购微服务的设计基于 CQRS 原则。不过，它采用了最简化的方法，即仅仅将查询与命令分离开来，并且对这两种操作使用同一个数据库。

The essence of those patterns, and the important point here, is that queries are idempotent: no matter how many times you query a system, the state of that system won't change. In other words, queries are side-effect free.

这些模式的本质，也是这里的关键点在于，查询是幂等的（idempotent）：无论你查询系统多少次，该系统的状态都不会发生改变。换句话说，查询是没有副作用的。

Therefore, you could use a different "reads" data model than the transactional logic "writes" domain model, even though the ordering microservices are using the same database. Hence, this is a simplified CQRS approach.

因此，尽管订购微服务使用的是同一个数据库，你依然可以为“读取”操作使用与事务性逻辑“写入”领域模型不同的数据模型。正因如此，这被称为一种简化的 CQRS 方法。

On the other hand, commands, which trigger transactions and data updates, change state in the system. With commands, you need to be careful when dealing with complexity and ever-changing business rules. This is where you want to apply DDD techniques to have a better modeled system.

另一方面，命令会触发事务和数据更新，从而改变系统的状态。在处理命令时，你需要小心应对复杂的业务逻辑和不断变化的业务规则。这正是你希望应用 DDD 技术的地方，以便构建出建模更完善的系统。

The DDD patterns presented in this guide should not be applied universally. They introduce constraints on your design. Those constraints provide benefits such as higher quality over time, especially in commands and other code that modifies system state. However, those constraints add complexity with fewer benefits for reading and querying data.

本指南中介绍的 DDD 模式不应被普遍滥用。它们会给你的设计带来约束。这些约束能带来诸如随时间推移代码质量更高等好处，尤其是在命令以及其他修改系统状态的代码中。然而，这些约束也增加了复杂性，而在读取和查询数据时，这种复杂性带来的收益却很少。

One such pattern is the Aggregate pattern, which we examine more in later sections. Briefly, in the Aggregate pattern, you treat many domain objects as a single unit as a result of their relationship in the domain. You might not always gain advantages from this pattern in queries; it can increase the complexity of query logic. For read-only queries, you do not get the advantages of treating multiple objects as a single Aggregate. You only get the complexity.

聚合（Aggregate）模式就是这样一个例子，我们将在后续章节中更详细地探讨。简而言之，在聚合模式中，由于领域对象在领域内的关联性，你将许多领域对象视为一个单一的整体单元。在查询中，你可能并不总是能从这个模式中获得优势；相反，它可能会增加查询逻辑的复杂性。对于只读查询，将多个对象视为一个聚合整体并没有带来任何好处，你只会得到随之而来的复杂性。

As shown in Figure 7-2 in the previous section, this guide suggests using DDD patterns only in the transactional/updates area of your microservice (that is, as triggered by commands). Queries can follow a simpler approach and should be separated from commands, following a CQRS approach.

正如上一节图 7-2 所示，本指南建议仅在微服务的事务/更新区域（即由命令触发的部分）使用 DDD 模式。查询可以采用更简化的方法，并且应遵循 CQRS 方法与命令分离开来。

For implementing the "queries side", you can choose between many approaches, from your full-blown ORM like EF Core, AutoMapper projections, stored procedures, views, materialized views or a micro ORM.

在实现“查询端”时，你可以选择多种方法，从功能完善的 ORM（如 EF Core）、AutoMapper 投影、存储过程、视图、物化视图，到轻量级的微 ORM 都可以。

In this guide and in eShopOnContainers (specifically the ordering microservice) we chose to implement straight queries using a micro ORM like Dapper. This guide lets you implement any query based on SQL statements to get the best performance, thanks to a light framework with little overhead.

在本指南以及 eShopOnContainers（特别是订购微服务）中，我们选择使用像 Dapper 这样的微 ORM 来实现直接的查询。得益于这种轻量级框架带来的极低开销，本指南让你能够基于 SQL 语句实现任何查询，从而获得最佳性能。

When you use this approach, any updates to your model that impact how entities are persisted to a SQL database also need separate updates to SQL queries used by Dapper or any other separate (non-EF) approaches to querying.

当你使用这种方法时，任何对模型的更新（如果影响了实体如何持久化到 SQL 数据库）都需要对 Dapper 使用的 SQL 查询语句，或任何其他独立（非 EF）的查询方法进行单独的更新维护。

CQRS and DDD patterns are not top-level architectures    CQRS 和 DDD 模式并非顶层架构

It's important to understand that CQRS and most DDD patterns (like DDD layers or a domain model with aggregates) are not architectural styles, but only architecture patterns. Microservices, SOA, and event-driven architecture (EDA) are examples of architectural styles. They describe a system of many components, such as many microservices. CQRS and DDD patterns describe something inside a single system or component; in this case, something inside a microservice.

需要明确的是，CQRS 和大多数 DDD 模式（如 DDD 分层或带有聚合的领域模型）并不是架构风格（architectural styles），而仅仅是架构模式（architecture patterns）。微服务、面向服务架构（SOA）和事件驱动架构（EDA）才是架构风格的例子。它们描述的是由许多组件（例如许多微服务）组成的系统。而 CQRS 和 DDD 模式描述的是单个系统或组件内部的事物；在本例中，就是指微服务内部的架构设计。

Different Bounded Contexts (BCs) will employ different patterns. They have different responsibilities, and that leads to different solutions. It is worth emphasizing that forcing the same pattern everywhere leads to failure. Do not use CQRS and DDD patterns everywhere. Many subsystems, BCs, or microservices are simpler and can be implemented more easily using simple CRUD services or using another approach.

不同的限界上下文（Bounded Contexts, BCs）会采用不同的模式。它们承担着不同的职责，这自然会导致不同的解决方案。值得强调的是，强行在所有地方使用相同的模式会导致失败。不要在所有地方都使用 CQRS 和 DDD 模式。许多子系统、限界上下文或微服务其实更加简单，使用简单的 CRUD 服务或其他方法会更容易实现。

There is only one application architecture: the architecture of the system or end-to-end application you are designing (for example, the microservices architecture). However, the design of each Bounded Context or microservice within that application reflects its own tradeoffs and internal design decisions at an architecture patterns level. Do not try to apply the same architectural patterns as CQRS or DDD everywhere.

只有一个应用架构：那就是你正在设计的系统或端到端应用的架构（例如微服务架构）。然而，该应用内每个限界上下文或微服务的设计，反映了其自身在架构模式层面的权衡和内部设计决策。不要试图在所有地方都应用像 CQRS 或 DDD 这样相同的架构模式。