使用Axon Framework探索CQRS架构系列(零)：介绍

原文地址：http://www.geekabyte.io/2015/10/exploring-cqrs-architecture-with-axon.html

这是使用Axon Framework探索CQRS架构的一系列中的第一篇文章。

目的是首先从概念/架构的角度理解CQRS是什么，然后探索Axon Framework框架，以帮助构建遵循CQRS模式的应用程序。

本系列的帖子包括：

使用Axon Framework探索CQRS架构系列(一)：命令, 命令总线 和 命令处理组件
使用Axon Framework探索CQRS架构系列(二)：DDD一些概念的概览
使用Axon Framework探索CQRS架构系列(三)：构建实体、聚合、聚合根、存储库组件
使用Axon Framework探索CQRS架构系列(四)：介绍领域事件及事件处理
使用Axon Framework探索CQRS架构系列(五)： 事件溯源 Event Sourcing的应用
Exploring CQRS with Axon Framework: Overview of the Testing infrastructure.
Exploring CQRS with Axon Framework: Closing thoughts.

What is CQRS

CQRS是一种构建软件系统的方法，强调分离应用程序中改变应用程序状态的部分和查询应用程序状态的部分。 我们在以下部分进一步扩展：“CQRS的鸟瞰图”。

What is Axon Framework

Axon Framework标语说：“CQRS框架 for Java”。 我想这似乎总结了一下？ Axon Framework将自身描述为一个框架，通过支持开发人员应用命令查询责任隔离（CQRS）架构模式，帮助构建可伸缩，可扩展和可维护的应用程序。 它通过提供最重要的构建块的实现来实现，例如聚合，存储库和事件总线（事件的调度机制）

您可以在此处阅读有关此内容和Axon Framework背景的更多信息。

在我们开始研究Axon Framework为构建CQRS应用程序提供的构建块之前，让我们首先概述一下CQRS的内容。 如果您已经熟悉CQRS，并且只想了解Axon Framework如何为您提供帮助，那么请随时跳转到命令，命令总线和命令处理组件

A bird’s eye view of CQRS

我喜欢将CQRS视为一个简单概念的繁琐首字母缩略词，即应用程序的“write”部分与应用程序的“read“部分明显分开。

如果你看一下这个首字母缩略词的定义，那基本上就是说：Command（写入部分），Query（读取部分）Responsibility Segregation（应该分开）。

例如，如果我有这样一个类foo

public class Foo {

// changes state
private void makeFoo() {
}

// reads state
private Foo getFoo() {
}

改变状态和读取状态的功能责任分为两种方法，但它们仍然非常紧密地联系在一起，因为它们存在于同一类中，因此无法将它们明确地分开。

将getFoo()移动到另一个类，并将makeFoo()页移动到另一个类，实现了一些分离：CQRS是关于在基础结构级别而不仅仅是在类级别上实现这种分离。

这就是它的全部……

实现此分离的确切方法是保持开放，并且未在CQRS定义中指定。

但我们会注意到，根据CQRS规定的这个定义的本质，松散耦合最终成为CQRS的概念所固有的。 因此，我们经常发现基于组件和事件/消息驱动的设计作为通常用于实现CQRS的方法。

在某些方面/讨论中，CQRS甚至不被视为“架构”而是“模式”。 一种模式或方法，在遵循时可以打开空间以应用不同的其他架构来帮助实现。

在我看来，这是第一次接触CQRS时的混乱。 例如，我敢打赌，一旦你开始涉足CQRS，你几乎会立即接触到诸如事件溯源，最终一致性，消息和actor等概念。这最终会反映出CQRS所代表的想法。

例如，当提到CQRS时，事件溯源总是几乎一起出现在你的面前，所以你会认为它在技术上是CQRS的一部分，尽管事实并非如此。 您可以拥有一个没有事件溯源的CQRS系统！

我简单概括，事情变得更加清晰：CQRS很简单，它只是说写和读应该分开。 但由于松散耦合为我们开辟了基础，基于组件的方法，由消息驱动已经成为实现CQRS的最流行的方式之一。

下一个问题是构成典型CQRS设置的组件是什么？ 或者更确切地说，Axon框架为其提供基础架构的组件。

为了回答这个问题，我们将使用分层架构进行比较。

分层架构 vs 基于组件的架构

在分层体系结构中，应用程序的各个部分（组件）排列在层中，具有一个独特的特征，即一个层只能直接调用它下面的层。

也就是说，一层紧密地耦合到它旁边的层。
像这样:

source: https://dotnetpeoples.wordpress.com/2011/05/16/three-tier-architecture-in-asp-net/

或者这样

取决于你想要架构分的层数的疯狂程度。

订单上的基于组件的体系结构有利于通过使半自治组件松散耦合，并且能够使用消息传递机制与其他组件协作和通信来构建应用程序。

CQRS应用程序通常包括以下组件：UI，命令总线，命令处理程序，存储库，域对象，事件总线，事件处理程序，以及通过命令和事件组合在一起的所有组件。

这些组件如下所示：

蓝色部件是您的应用程序组件。 绿色的是Axon Framework提供的组件（尽管值得注意的是Axon很容易让您提供自己的组件实现…例如，您可以轻松地将命令总线的实现交换为自定义实现）。

从图中可以看出，顶部的组件是改变应用程序状态的组件。 它也是实现业务逻辑的领域，而底部的组件读取或查询应用程序的状态：在这种明确的分离中，我们有了CQRS。

应用程序中的流程总结为：

使用UI组件的用户启动改变状态的意图（预订票证，编辑文档，更新医疗记录等）。 这种改变状态的意图被建模为命令。 命令被传递到命令总线，命令总线找到可以处理用户发起的命令的必要命令处理程序。

状态更改在Command处理程序中处理，该处理程序使用Repository加载Domain对象并执行业务逻辑，将更改应用于其状态。

一旦状态发生变化，代表更改内容的事件将发布到事件总线。 事件总线确保通知到必要的事件处理程序。 然后，事件处理程序更新应用程序状态的表示，然后UI可以查询该状态。 在某些情况下，如果需要，您还可以启动命令以响应事件。

Where Event Sourcing comes in.

事件溯源的背后的想法是，我们存储改变应用程序的事件，而不是存储应用程序的当前状态。
事件溯源可以很容易地用于CQRS系统，但这并不意味着CQRS系统必须使用事件溯源。
您可以拥有完美的CQRS架构而无需事件溯源。Axon Framework提供了轻松使用事件溯源的工具。

What Next?

现在我们已经对CQRS进行了概述，看到了将要发挥作用的各种组件，接下来的问题是，如何使用Axon Framework？

这些系列中即将发布的帖子将正是如此。 我们将探索如何使用Axon Framework提供的工具构建CQRS应用程序的各种组件。

为了帮助说明本系列中将要涉及的主题，我在Github上创建了一个项目https://github.com/dadepo/exploringCQRSwithAxon。 这是一个简单的应用程序，可以为两个银行账户建模，并具有借记和贷记账户的能力。

本系列中的每篇文章都将以关于需要在其他方面检出的提交哈希的指令开始，以使项目处于该帖子的状态。

我们首先探索命令，命令总线和命令处理组件。