Axon参考指南 - 1.DDD和CQRS概念

Axon很大程度上基于域驱动设计（DDD）和命令查询责任隔离的原则。尽管对这些概念的完整解释超出了本参考指南的范围和意图，但我们确实希望提供有关Axon应用程序上下文中最重要概念的摘要。

战略概念

战略概念是相对较高的概念，它们在体系结构级别上影响系统的设计。它提供了设计组件边界及其之间相互作用的概念。尽管它们不会直接影响单个Axon应用程序的设计，但此类应用程序的边界通常会受到这些概念的影响。

域和子域

在DDD上下文中，域的正式定义是：

知识领域，知识领域或活动领域用户向其应用程序的主题领域是软件的领域。

这个定义可能看起来很模糊，但确实很好地抓住了本质。域基本上是构建软件的环境。这种环境由法律，最佳实践，期望，传统等组成，它们定义了什么是重要的，什么不是重要的。

域可能非常大，并且域内的不同区域可能会产生不同的影响。例如，在银行业务领域，消费者银行业务，公司银行业务和财富管理之间存在明显的区别。

有许多技术可以帮助您发现域。事件风暴是特别有趣的事件。它是一种研讨会形式，用于快速探索复杂的业务领域。

模型

模型是：

一种描述领域选定方面的抽象系统，可用于解决与该领域相关的问题；

换句话说，模型捕获了对于我们解决领域内特定问题的重要信息。这个定义本身表明一个应用程序应该包含多个模型，因为每个问题都有一个不同的理想模型来解决。

有关基于Axon的应用程序中模型的某些构造块的更多信息，请参见战术概念。

界限上下文

上下文是：

单词或陈述出现的设置决定其含义。

换句话说，相同的领域概念对不同的人可能具有不同的含义。

例如，考虑一次飞行的概念。对于乘客而言，飞行是指从飞机起飞到到达目的地的时间。但是，地勤人员关心航班到达登机口的次数，要登上飞机的饭菜，枕头等的数量，这些事情在航班离开登机口时就完成了。对他们而言，出发时间是最后期限，而不是起点。

因此，对于模型和上下文有许多规则：

• 明确定义应用模型的上下文。
• 在团队组织，在应用程序的特定部分内的用法以及诸如代码库和数据库模式之类的物理表现方面，明确设置边界。
• 在这些范围内严格保持模型的一致性，但不要因模型之外的问题而分神或困惑。

上下文映射

有限的上下文永远不会完全靠自己生存。来自不同环境的信息最终将被同步。显式建模此交互很有用。域驱动设计列出了上下文之间的一些关系，这些关系决定了它们之间的交互方式：

• 伙伴关系（两个环境/团队共同努力建立互动）
• 客户-供应商（具有上游/下游关系的两个团队-上游可以独立于下游团队获得成功）
• 遵从者（上游/下游关系中有两个团队-上游没有动力向下游提供，下游团队也没有努力翻译）
• 共享内核（明确共享模型的一部分）
• 分开的方式（将它们切开）
• 反腐败层（下游团队构建一层，通过转换交互来防止上游设计“泄漏”到自己的模型中）

在基于Axon的应用程序中，上下文定义事件在其中携带值的边界。有些事件可能仅在其发布的上下文中才有价值，而另一些事件甚至在外部也可能有价值。发布事件（或任何消息，就此而言）的范围越广，最终有更多的组件耦合到发送者。

战术概念

为了构建模型，DDD（在某种程度上还包括CQRS）提供了许多有用的构建块。下面是一些在基于Axon的应用程序中很重要的构建块。

Aggregates

聚合是始终保持一致状态（在单个ACID事务中）的实体或实体组。
聚合根是聚合中负责维护此一致状态的实体。这使聚合成为在任何基于CQRS的应用程序中实现命令模型的主要构建块。

DDD的正式定义是：

关联对象的群集，出于数据更改的目的，它们被视为一个单元。外部引用仅限于聚合的一个成员，称为根。一组一致性规则适用于聚合的边界。

在基于CQRS的应用程序中，聚合在命令模型中非常明确地存在，因为这是启动更改的地方。但是，查询模型/投影也是由聚合建立的。但是，通常，查询模型中的聚合要简单得多，因为状态不变式在这些模型中通常不太严格。

Saga

并非每个命令都能在单个原子事务中完全执行。汇款是交易中经常出现的一个非常常见的例子。人们通常认为，绝对必要的是原子交易，将资金从一个帐户转移到另一个帐户。好吧，不是。相反，这是完全不可能的。如果资金从银行A上的一个帐户（BankAccount集合的实例A）转移到银行B上的另一个帐户（BankAccount集合的实例B），该怎么办？银行A是否获得银行B数据库的锁？如果正在进行转帐，银行A扣除了这笔金额但银行B还没有存入这笔款项，这很奇怪吗？不完全是，它正在进行中。另一方面，如果在将钱存入银行B的帐户时出了点问题，银行A的客户会希望退回他的钱。因此，我们确实希望最终会有某种形式的一致性。另一个示例可能是GiftCardPaymentSaga，它会在下订单（OrderPlacedEvent）后开始。它将确保一旦成功兑换礼品卡（CardRedeemedEvent），在另一侧确认订单（ConfirmGiftCardPaymentCommand）。

尽管在某些情况下ACID交易不是必需的，甚至是不可能的，但仍需要某种形式的交易管理。通常，这些事务称为BASE事务：基本可用，软状态，最终一致性。与ACID相反，BASE事务无法轻松回滚。要回滚，需要采取补偿措施来还原在事务中发生的任何事情。在礼品卡示例中，礼品卡的兑换失败将拒绝订单付款。

在CQRS中，可以使用Sagas来管理这些BASE事务。它们响应事件并可以调度命令，调用外部应用程序等。在域驱动设计的上下文中，通常将Sagas用作不同聚合（或聚合实例）之间的协调机制，以最终实现一致性。

View Models or Projections

在CQRS中，视图模型（也称为投影或查询模型）用于有效地公开有关应用程序状态的信息。与命令模型不同，视图模型着重于数据而不是行为。视图模型通常是为适应特定受众的信息需求而建模的。这些模型应清楚地表示模型的目标受众，以防止“分心”和范围蠕变，最终导致可维护性甚至性能的损失。

原文：https://docs.axoniq.io/reference-guide