DDD和SOA及微服务

微服务架构有哪些模型？中台、领域驱动设计及微服务之间有着什么样的关系？微服务的边界设计怎么做？怎么做设计和拆分？且看作者为你娓娓道来。

借用当下最流行的段子做个开场白。

“设计原则千万条，高内聚低耦合第一条，架构设计不规范，开发运维两行泪！”。

在分布式架构下，单体应用被拆分为多个微服务，为了保证微服务的单一职责和合理拆分，“高内聚、松耦合”是最宝贵的设计原则。

通俗点讲，高内聚就是把相关的行为聚集在一起，把不相关的行为放在别处，如果你要修改某个服务的行为，最好只在一处修改。如果做到了服务之间的松耦合，那么修改一个服务就不需要修改另一服务，一个松耦合的服务应该尽可能少的知道与之协作的那些服务的信息。

从集中式架构向分布式架构的技术转型，正如从盖砖瓦房向盖高楼大厦转变一样，必然要有组织、文化、理念和设计方法的同步更新，其中最不可或缺的能力就是架构设计能力。

如何做到“高内聚、低耦合”？我们先来学习几种典型的微服务架构模型。

微服务架构模型

整洁架构（又名洋葱架构）

在整洁架构里，同心圆代表应用软件的不同部分，从里到外依次是领域模型、领域服务、应用服务、最外围是容易变化的内容，如界面和基础设施（如数据存储等）。整洁架构是以领域模型为中心，不是以数据为中心。

整洁架构

整洁架构最主要原则是依赖原则，它定义了各层的依赖关系，越往里，依赖越低，代码级别越高。外圆代码依赖只能指向内圆，内圆不知道外圆的任何事情。一般来说，外圆的声明（包括方法、类、变量）不能被内圆引用。同样的，外圆使用的数据格式也不能被内圆使用。

整洁架构各层主要职能如下：

Entities：实现领域内核心业务逻辑，它封装了企业级的业务规则。一个 Entity 可以是一个带方法的对象，也可以是一个数据结构和方法集合。

Use Cases：实现与用户操作相关的服务组合与编排，它包含了应用特有的业务规则，封装和实现了系统的所有用例。

Interface Adapters：它把适用于 Use Cases 和 entities 的数据转换为适用于外部服务的格式，或把外部的数据格式转换为适用于 Use Casess 和 entities 的格式。

Frameworks and Drivers：这是实现所有前端业务细节的地方：UI，Tools，Frameworks 等。

六边形架构（又名端口适配器架构）

追溯微服务架构的渊源，一般会涉及到六边形架构。六边形架构的核心理念是：应用是通过端口与外部进行交互的，这也是微服务架构下 API 网关盛行的主要原因。六边形架构中，内部业务逻辑（应用层和领域模型）与外部资源（APP，WEB 应用以及数据库资源等）完全隔离，仅通过适配器进行交互。它解决了业务逻辑与用户界面的代码交错的主要问题，从而可以很好的实现前后端分离。

六边形架构

六边形架构将系统分为内部和外部两层六边形，内部六边形代表了应用的核心业务逻辑，外部六边形代表外部应用、驱动和基础资源等。内部通过端口和适配器与外部通信，对应用以 API 主动适配的方式提供服务，对资源通过依赖反转被动适配资源的形式呈现。一个端口可能对应多个外部系统，不同的外部系统使用不同的适配器，适配器负责对协议进行转换。这就使得应用程序能够以一致的方式被用户、程序、自动化测试、批处理脚本所驱动。

六边形架构各层的依赖关系与整洁架构类似。

CQRS（命令与查询职责分离）

CQRS 就是读写分离，读写分离的主要目的是为了提高查询性能，同时达到读、写解耦。而 DDD 和 CQRS 结合，可以分别对读和写建模。

CQRS（命令与查询职责分离）

查询模型是一种非规范化数据模型，它不反映领域行为，只用于数据查询和显示；命令模型执行领域行为，在领域行为执行完成后通知查询模型。

命令模型如何通知到查询模型呢？如果查询模型和领域模型共享数据源，则可以省却这一步；如果没有共享数据源，可以借助于发布订阅的消息模式通知到查询模型，从而达到数据最终一致性。

Martin 在 blog 中指出：CQRS 适用于极少数复杂的业务领域，如果不是很适合反而会增加复杂度；另一个适用场景是为了获取高性能的查询服务。

对于写少读多的共享类通用数据服务（如主数据类应用）可以采用读写分离架构模式。单数据中心写入数据，通过发布订阅模式将数据副本分发到多数据中心。通过查询模型微服务，实现多数据中心数据共享和查询。

领域驱动设计分层架构

分层架构的一个重要原则是每层只能与位于其下方的层发生依赖。

分层架构的好处是显而易见的。

首先，由于层间松散的耦合关系，使得我们可以专注于本层的设计，而不必关心其他层的设计，也不必担心自己的设计会影响其它层，对提高软件质量大有裨益。其次，分层架构使得程序结构清晰，升级和维护都变得十分容易，更改某层的代码，只要本层的接口保持稳定，其他层可以不必修改。即使本层的接口发生变化，也只影响相邻的上层，修改工作量小且错误可以控制，不会带来意外的风险。
 
关于分层架构的权威观点，Martin Fowler 在《Patterns of Enterprise Application Architecture》一书中给出了答案： 1. 开发人员只关注整个架构中的某一层。 2. 很容易的用新的方法来替换原有层次的方法。 3. 降低层与层之间的依赖。 4. 有利于标准化。 5. 利于各层逻辑的复用。

要保持程序分层架构的优点，就必须坚持层间的松耦合关系。设计程序时，应先划分出可能的层次，以及此层次提供的接口和需要的接口。设计某层时，应尽量保持层间的隔离，仅使用下层提供的接口。

DDD（领域驱动设计）分层架构

DDD 分层架构各层定义与职能：

展现层：它负责向用户显示信息和解释用户命令，完成前端界面逻辑。这里的用户不一定是使用用户界面的人，也可以是另一个计算机系统。

应用层：它是很薄的一层，负责展现层与领域层之间的协调，也是与其它系统应用层进行交互的必要渠道。应用层要尽量简单，不包含业务规则或者知识，不保留业务对象的状态，只保留有应用任务的进度状态，更注重流程性的东西。它只为领域层中的领域对象协调任务，分配工作，使它们互相协作。

领域层：它是业务软件的核心所在，包含了业务所涉及的领域对象（实体、值对象）、领域服务以及它们之间的关系，负责表达业务概念、业务状态信息以及业务规则，具体表现形式就是领域模型。领域驱动设计提倡富领域模型，即尽量将业务逻辑归属到领域对象上，实在无法归属的部分则以领域服务的形式进行定义。

基础设施层：它向其他层提供通用的技术能力，为应用层传递消息（API 网关等），为领域层提供持久化机制（如数据库资源）等。

架构模型对比和分析

虽然整洁架构、六边形架构以及 DDD 分层架构三种架构模型展现方式以及解决问题的出发点不一样，但其架构思想与微服务架构高内聚低耦合的设计原则高度一致。