我们就把 DDD 分层架构、整洁架构、六边形架构 这三种架构模型放到一起，对比分析，看看如何利用好它们，帮助我们设计出 高内聚、低耦合 的中台以及微服务架构。

整洁架构

整洁架构又名“洋葱架构”。为什么叫它洋葱架构？看看下面这张图你就明白了。整洁架构的层就像洋葱片一样，体现了典型的分层设计思想。

在整洁架构里，同心圆代表应用软件的不同部分。从里到外依次是：领域模型、领域服务、应用服务，以及最外围那些容易变化的内容，比如用户界面和基础设施。

整洁架构最主要的原则是 依赖原则。它定义了各层的依赖关系：越往里，依赖越少、代码级别越高，也越接近系统的核心能力。外圆代码的依赖只能指向内圆，而内圆不需要知道外圆的任何情况。

在洋葱架构中，各层的职能可以这样划分：

  • 领域模型实现领域内核心业务逻辑，它封装了企业级的业务规则。领域模型的主体是实体，一个实体可以是一个带方法的对象，也可以是一个数据结构和方法集合。
  • 领域服务实现涉及多个实体的复杂业务逻辑。
  • 应用服务实现与用户操作相关的服务组合与编排，它包含了应用特有的业务流程规则，封装和实现了系统所有用例。
  • 最外层主要提供适配的能力，适配能力分为主动适配和被动适配。主动适配主要实现外部用户、网页、批处理和自动化测试等对内层业务逻辑访问适配。被动适配主要是实现核心业务逻辑对基础资源访问的适配，比如数据库、缓存、文件系统和消息中间件等。
  • 红圈内的领域模型、领域服务和应用服务一起组成软件核心业务能力。

六边形架构

六边形架构又名“端口适配器架构”。追溯微服务架构的渊源，一般都会涉及六边形架构。

六边形架构的核心理念是：应用通过端口与外部进行交互。我想，这也是微服务架构下 API 网关盛行的主要原因之一。

也就是说，在下图的六边形架构中，红圈内的核心业务逻辑（应用程序和领域模型）与外部资源（包括 App、Web 应用以及数据库资源等）完全隔离，仅通过适配器进行交互。它解决了业务逻辑与用户界面代码交错的问题，也很好地实现了前后端分离。六边形架构各层的依赖关系与整洁架构一样，都是由外向内依赖。

六边形架构将系统分为“内六边形”和“外六边形”两层，这两层的职能划分如下：

  • 红圈内的六边形实现应用的核心业务逻辑；
  • 外六边形完成外部应用、驱动和基础资源等的交互和访问，对前端应用以API主动适配的方式提供服务，对基础资源以依赖倒置被动适配的方式实现资源访问。

六边形架构的一个端口可能对应多个外部系统，不同的外部系统也可能会使用不同的适配器，由适配器负责协议转换。这就使得应用程序能够以一致的方式被用户、程序、自动化测试和批处理脚本使用。

三种微服务架构模型的对比和分析

虽然 DDD 分层架构、整洁架构、六边形架构 的表现形式不一样，但你不要被它们的表象所迷惑。这三种架构模型的设计思想，正是微服务架构“高内聚、低耦合”原则的完美体现，而它们共同闪耀的核心，正是 以领域模型为中心 的设计思想。

我们来看上面这张图，结合图示对这三种架构模型做一个分析。

请你重点关注图中的红色线框。它们是非常重要的分界线，这三种架构里都有。它的作用，就是将核心业务逻辑与外部应用、基础资源隔离开来。

红色框内部主要实现核心业务逻辑，但核心业务逻辑本身也存在差异：有的属于领域模型能力，有的则属于面向用户的用例和流程编排能力。按照这种功能差异，我们在这三种架构中划分了应用层和领域层，分别承担不同类型的业务逻辑。

领域层面向领域模型，实现领域模型的核心业务逻辑，属于原子能力模型。它需要保持领域模型和业务逻辑的稳定，对外提供稳定、细粒度的领域服务，因此它处于架构的核心位置。

应用层实现面向用户操作的用例和流程，对外提供粗粒度的 API 服务。它就像一个齿轮，承担前台应用与领域层之间的适配职责：接收前台需求，随时做出响应和调整，并尽量避免将前台需求直接传导到领域层。因此，应用层就像一个“配速齿轮”，位于前台应用和领域层之间。

可以说，这三种架构都同时考虑了“前端需求的变化”与“领域模型的稳定”。需求变化无穷，但变化往往有迹可循：用户体验、操作习惯、市场环境以及管理流程的变化，常常会导致界面逻辑和流程频繁变化。但总体来说，只要企业没有发生大的变革，核心领域逻辑通常不会发生根本性变化。因此，领域模型相对稳定，而用例和流程则会随着外部应用需求不断调整。把握好这个规律，我们就知道该如何设计应用层和领域层了。

架构模型通过分层的方式，控制需求变化从外到里对系统的影响，使系统从外向里受到需求变化影响的程度逐步减小。面向用户的前端可以快速响应外部需求，灵活调整和发布；应用层则通过服务组合与编排，实现业务流程的快速适配上线，减少需求向领域层传导，从而让领域层保持长期稳定。

这样设计的好处就很明显了：它可以保证领域层的核心业务逻辑，不会因为外部需求和流程的变动而频繁调整，这对于建立“前台灵活、中台稳固”的架构非常有帮助。

看到这里，你是不是已经猜出中台和微服务设计的关键了呢？我给出的答案是：领域模型和微服务的合理分层设计。那么你的答案呢？

从三种架构模型看中台和微服务设计

结合这三种微服务架构模型的共性，下面我来谈谈中台和微服务设计的一些心得体会。

中台本质上是领域的子域，它可能是核心域，也可能是通用域或支撑域。通常大家认为，阿里的中台对应 DDD 的通用域，即将通用的公共能力沉淀为中台，对外提供通用共享服务。

中台作为子域，还可以继续分解为更细的子子域。当子域被分解到合适大小，并通过事件风暴划分出限界上下文以后，就可以定义微服务了，微服务用来实现中台能力。表面上看，DDD、中台、微服务这三者之间似乎没什么关联；但实际上，它们之间的关系非常紧密，组合在一起，完全可以作为一个理论体系，用于你的中台和微服务设计。

1. 中台建设要聚焦领域模型

中台需要站在全企业的高度，考虑能力的共享与复用。

中台设计时，我们需要建立中台内所有限界上下文的领域模型。DDD 建模过程中，会同步考虑架构演进和功能重组。领域模型建立的过程，会对业务和应用进行清晰的逻辑边界与物理边界（微服务）划分。领域模型的结果，还会影响后续的系统模型、架构模型和代码模型，最终影响微服务的拆分与项目落地。

因此，在中台设计中，我们首先要聚焦领域模型，并将它放在核心位置。

2. 微服务要有合理的架构分层

微服务设计要有分层思想，让各层各司其职，建立松耦合的层间关系。

不要把与领域无关的逻辑放到领域层实现，要保证领域层的纯洁和领域逻辑的稳定，避免污染领域模型。也不要把领域模型的业务逻辑放到应用层，否则会导致应用层过于庞大，最终让领域模型失焦。如果实在无法避免，我们可以引入防腐层，完成新老系统之间的适配与转换；等过渡期结束后，再将防腐层代码直接抛弃。

微服务内部的分层方式我们已经清楚了。那么，微服务之间是否也有层次依赖关系呢？又该如何实现微服务之间的服务集成？

有的微服务可以与前端应用集成，一起完成特定业务，这是项目级微服务；而有的则是职责单一的中台微服务，企业级业务流程需要将多个这样的微服务组合起来才能完成，这是企业级中台微服务。由于两类微服务的复杂度不同，它们的集成方式也会有所差异。

项目级微服务

项目级微服务内部遵循分层架构模型即可。领域模型的核心逻辑在领域层实现，服务的组合与编排在应用层实现，并通过 API 网关为前台应用提供服务，从而实现前后端分离。不过，项目级微服务也可能调用其它微服务。你看下面这张图，比如某个项目级微服务 B 调用认证微服务 A，完成登录和权限认证。

通常，项目级微服务之间的集成发生在微服务的应用层，由应用服务调用其它微服务发布在 API 网关上的应用服务。你看下图中微服务 B 红色框内的应用服务 B，它除了可以组合和编排自己的领域服务外，还可以组合和编排外部微服务的应用服务。只要将编排后的服务发布到 API 网关供前端调用，前端就可以直接访问自己的微服务了。

企业级中台微服务

企业级业务流程往往需要多个中台微服务协作完成。那么，跨中台的微服务该如何实现集成呢？

企业级中台微服务的集成，不能像项目级微服务那样，在某一个微服务内部完成跨微服务的服务组合与编排。

我们可以在中台微服务之上增加一层。你看下面这张图，新增的这一层就位于红色框内，它的主要职能就是处理跨中台微服务的服务组合与编排，以及微服务之间的协调；同时，它还可以完成前端不同渠道应用的适配。如果再把它的业务范围扩大一些，甚至可以将它做成一个面向不同行业和渠道的服务平台。

我们不妨借用 BFF（服务于前端的后端，Backend for Frontends）这个词，暂且称它为 BFF 微服务。BFF 微服务与其它微服务有一个较大的差异：它没有领域模型，因此这个微服务内部也不会有领域层。BFF 微服务可以承担应用层和用户接口层的主要职能，完成各个中台微服务的服务组合与编排，并适配不同前端和渠道的要求。

3. 应用和资源的解耦与适配

传统以数据为中心的设计模式中，应用往往会对数据库、缓存、文件系统等基础资源产生严重依赖。

正是由于这种强依赖关系，一旦更换基础资源，就会对应用产生很大影响，因此必须实现应用与资源的解耦。

在微服务架构中，应用层、领域层与基础层之间的解耦，是通过仓储模式并结合依赖倒置的设计方法来实现的。在应用设计中，我们会同步考虑与基础资源之间的代码适配。这样一来，一旦基础设施资源发生变更（比如更换数据库），就可以屏蔽资源变更对业务代码的影响，切断业务逻辑对基础资源的依赖，最终降低资源变更对应用的冲击。

总结

今天我们详细讲解了整洁架构和六边形架构，并对包括 DDD 分层架构 在内的三种微服务架构模型进行了对比分析，总结出了它们的共同特征；同时，也从这些共性出发，梳理出了中台建模和微服务架构设计的几个要点。后面我们还会继续展开，更详细地讲述这些设计如何真正落地。

从今天的内容中我们不难看出： DDD 分层架构、整洁架构、六边形架构，都是以领域模型为核心，采用分层架构，将内部核心业务逻辑与外部应用、资源进行隔离与解耦。请务必记住这个设计思想，今后一定会大有用处。