Axon4.5参考指南-翻译-Architecture Overview

Architecture Overview - 架构概览

基于Axon的应用程序遵循一种基于领域驱动（DDD），命令查询职责分离（CQRS）和事件驱动的架构（EDA）原则的架构模式。结合这些原则，使得基于Axon的应用更健壮，以及更容易适应由业务领域的变化所需的应用程序变化。

Axon在大型巨石系统（一种内部结构对于保持整体结构的适应性至关重要的架构）中以及微服务（一种因其分布式特性而增加复杂度的架构）中都有应用。

Dealing with complexity - 复杂性处理

 Axon起源于试图找到一种处理不断增加偶发复杂性场景的解决方案。即使最精心设计的模型也不会在生产环境中自动运行，应用领域驱动设计的概念在很大程度上获得了帮助。

尽管Axon对如何与模型进行交互有自己的看法，但是Axon尝试避免任何限制模型自由的行为。即使当你的观念与Axon不同时，Axon也有足够的钩子，配置选项，以及触发器来改变某些Axon某些方面的行为。你讲发现这些贯穿在参考指南中。

DDD & CQRS

领域驱动设计描述了一种构建软件的方法论，这套方法论大量强调在统一语言下设计模型。领域模型是软件的心脏，并且能够正确的捕获与处理领域中的本质复杂性。

命令查询职责分离是一个架构模式，该模式描述了应用中处理Commands（请求变更应用状态）与答复Queries（请求获取应用状态的信息）之间的差别。

当结合了DDD与CQRS，一个将应用划分成组件，每个组件要么提供了应用状态的信息，要么修改应用状态。每一个组件为它们关注的职责提供了一个模型。

下列图片展示了一个经典的基于Axon应用的架构。

在上图架构中，一个UI（或API）能够发送命令去请求应用状态的变更。这些Commands被Command Handling组件处理，它们使用一个模型来验证这些命令以及在需要的情况下决策哪种附带结果将被触发。

 因Commands而产生的附带结果将被通过事件来发布。这些事件每一个将被一个或多个Event Handling组件接收并执行适当的操作。一个典型的操作可以是更新视图模型，该模型允许UI来渲染应用的状态。这些操作还可以是发送消息通知外部组件，甚至可以是通过创建一个新的命令来触发其他附带结果。

命令模型与查询模型（也被叫做视图模型或投影）的分离允许这些模型仅仅关注应用中的特定方面。这使得每一个独立的模型更容易被理解，因此从长远来看也更容易被维护。

Separation of business logic and infrastructure - 分离业务逻辑与基础设施

偶然复杂性的增加通常是由基础设施与业务逻辑混合在一起而导致的缺乏抽象造成的。Axon将保持这两个部分严格独立作为最高优先级。在Axon设计的每个地方，Axon都使得“你想要做什么（比如说，想要发布一个事件）”和“实际上这将怎样实现（如：事件发布的实现）”清晰的区分出来。

上述设计使得Axon在面向具体情况时极具可配置性与适配性。更重要的是，这种设计确保了偶然复杂性的最小化。比如说，在Axon使得实现Event Sourced Aggregates很简单的同时，却不会强制聚合被Event Sourced。因为Repository接口彻底地抽象了这一决策。还有，一个组件决定通过一个Command Bus来发送Command，但是完全不需要决定这个消息（Command）到处理器的传输过程是如何实现的。

Axon并不仅仅通过为组件提供清晰的接口来确保这种分离，它还结合了Configuration API中的基础设施选项，业务逻辑组件与应用中基础设施方便是分开配置的。

Explicit Messaging - 显式消息

Axon充分利用了显式消息的使用。这意味着么个在基于Axon的应用中的消息通常将通过应用中特定的Java类展现出来。尽管这样确实在实现一个基于Axon的应用时增加了一点开销，但这样也带来了一些优势：

• 显式消息的使用使得消息被透明的分发到远程组件更方便；
• 显式消息的使用强调消息设计，这在应用程序的长期可维护性方面被证明是非常重要的；
• 显式消息能够在后续的处理中被简单的存储；

尽管Messaging 是Axon的核心概念，但并不是所有Messaging 都是一样的。不同的意图需要不同的路由模式。举个例子，对一个确定的消息来说，有时将期望一个确定的结果，有时是固定的触发-遗忘（类似于广播）模式。

Axone将消息粗略的分为三类：

• Commands；表达意图修改应用状态。Commands被路由到一个单独的目标并且可能提供一个响应。
• Queries；表达对信息的渴望。依赖分发策略，Queries可以被同时路由到一个或多个目的地。
• Events；表现为一个通知，代表有些相关的事情发生了。Events被发送到任意关系的组件并且不提供任何格式的返回值。

Location transparency - 位置不可见性

使用显示消息的最大好处是组件间相互交互是不需要知道对方的位置。事实上，在大部分用例中，发送消息的组件甚至不关注消息实际的目的地。我们叫它“Location Transparency”（实际上这种事件驱动的的系统在没有流程编排器或其他统一跟踪消息能力时，是非常难追溯业务流程的-by translator）。

 

Axon实现位置不可见性的手段远超把服务放在逻辑URL后面。在Axon中，一个组件发送消息并不需要为消息指定目的地。根据Messages的定义（Command，Query，Event）和它们携带的有效载荷类型，Messages被Axon自动路由。Axon使用程序的功能自动的为消息找到合适目的地。

 

 由位置不可见的组件构建的系统可以使得系统具备很强的适应性。举个例子，由合理分离的组件构建的巨石系统，系统中的组件仅仅只需要通过Commands，Events和Queries交互，该巨石系统可以被很轻松的拆分成独立部署的单元，而不会有任何功能上的重大影响。

 

这使得Axon对微服务环境具备高实用性。在整个系统中，逻辑可以在不影响功能的同时，在已部署的组件中移动起来非常简单灵活。逻辑的位置可以根据系统中每个组件的非功能性需求来决定。具有明显不同性能特性的组件或需要不同发布周期的组件，可以从巨石系统中分离出来，并且减少更改对组件的影响。

Event Sourcing - 事件溯源

在许多系统中，事件被赋予了许多额外的关注。当Axon清晰的意识到不是所有的消息都是一个事件（还存在命令和查询），事件具备其特殊之处。

事件保留价值。Commands与Queries的价值在他们触发了附带结果或提供了结果之后会显著减少，Events代表了某些事情发生了，在发生很长时间之后再去看这些事件也是很有用的。

事件提供了一个非常好的审计跟踪的粒度级别。然而，要使得审计跟踪100%可靠，它不仅仅作为附带结果被生成，还必须确保审计跟踪能够正确的映射任意决策。

Event Sourcing是一种过程，Events并不仅仅当做触发命令后的附带结果，还作为一种保存数据原状态的格式。即当前应用状态没有被显示的存储到数据库中，它被隐式地存储为一个由事件组成的序列，该序列可用于推导出当前的状态。一旦收到Command，应用程序的状态会从数据库的事件序列中动态的推导出来，然后决策哪一种附带结果将被应用。

Event Sourcing自己实现起来会非常复杂。Axon提供了一套必要的API，以及一个构建命令模型更自然的方法来确保实现事件溯源非常简单。Axon的测试固件确保了这些指导方针和需求已被正确的遵循。

拥有一个可靠的审计追踪不仅仅被证明对系统的可追溯性非常有用，它还提供了构建视图模型的必要信息，并且为实施数据分析和机器学习算法提供了坚实的基础。