几种微服务架构模型对比分析
前面重点介绍了DDD分层架构，同时也提到了微服务架构模型有很多种，这些架构模型在微服务架构设计中具有很高的借鉴价值。
这里我们首先介绍两种常用的微服务架构模型：洋葱架构模型和六边形架构模型。然后，对比分析DDD分层架构、洋葱架构和六边形架构这三种架构模型，了解不同架构模型的优缺点，以便更好地利用好它们，设计出"高内聚，低耦合"的中台领域模型和微服务。
洋葱架构
2008年Jeffrey Palermo提出了洋葱架构（Onion Architecture）。为什么叫它洋葱架构？看到下面这张图，相信你很快就能明白。洋葱架构的层就像洋葱片一样，它体现了分层的设计思想。
在洋葱架构中，同心圆代表应用软件的不同部分，从里向外依次是领域模型、领域服务、应用服务和最外层容易变化的内容，比如用户界面和基础资源。
在洋葱架构中，各层的职能是这样划分的。
1）领域模型实现领域内核心业务逻辑，它封装了企业级的业务规则。领域模型的主体是实体，一个实体可以是一个带方法的对象，也可以是一个数据结构和方法集合。
2）领域服务实现涉及多个实体的复杂业务逻辑。
3）应用服务实现与用户操作相关的服务组合与编排，它包含了应用特有的业务流程规则，封装和实现了系统所有用例。
4）洋葱架构最外层主要提供适配能力，适配能力分为主动适配和被动适配。主动适配主要实现外部用户、网页、批处理和自动化测试等对内层业务逻辑访问的适配。被动适配主要是实现核心业务逻辑对基础资源访问的适配，比如数据库、缓存、文件系统和消息中间件等。
其中，加粗线框内的领域模型、领域服务和应用服务一起组成应用的核心业务能力。
六边形架构
2005年Alistair Cockburn提出了六边形架构（Hexagonal Architecture），六边形架构又名"端口适配器架构"。追溯微服务架构的渊源，一般都会涉及六边形架构。
六边形架构的核心理念是：应用是通过端口与外部进行交互的。我想这也是微服务架构下为什么API网关盛行的主要原因吧。也就是说，在六边形架构中，加粗线框内的核心业务逻辑（应用程序和领域模型）与外部资源（包括App、Web应用以及数据库资源等）完全隔离，仅通过适配器进行交互。它解决了业务逻辑与用户界面的代码交错问题，很好地实现了前后端分离；也解决了业务逻辑与基础资源逻辑耦合的问题，实现了依赖倒置。六边形架构各层的依赖关系与洋葱架构一样，都是由外向内依赖。
六边形架构将应用分为内六边形和外六边形两层，这两层的职能划分如下。
▪加粗线框内的六边形实现应用的核心业务逻辑。
▪外六边形完成外部应用、驱动和基础资源等的交互和访问，对前端应用以API主动适配的方式提供服务，对基础资源以依赖倒置被动适配的方式实现资源访问。
六边形架构的一个端口可能对应多个外部系统，不同的外部系统也可能会使用不同的适配器，由适配器负责协议转换。这就使得应用程序能够以一致的方式被用户、程序、自动化测试和批处理脚本使用。
三种微服务架构模型的对比和分析
我们先来看一下这三种架构模型的发展和演变关系。虽然这三种架构模型在对外的表现形式上存在很大的差异，实际上它们包含了一种演化的关系，其核心设计思想是一致的。
DDD在2003年诞生，在DDD分层架构中体现的是上下层的依赖关系。六边形架构在2005年提出，它将这种上下层关系演化为内外六边形的关系，内六边形代表应用业务逻辑，外六边形代表外部应用、适配驱动以及基础资源逻辑。但这时内六边形的业务逻辑中还没有特别明显的领域模型概念。
2008年洋葱架构出现，六边形架构实际上是洋葱架构的一个超集。洋葱架构与六边形架构设计思路基本相同，都是通过适配器实现业务逻辑与基础设施解耦，避免基础逻辑代码渗透到业务逻辑中。洋葱架构在业务逻辑中引入了DDD分层概念和要素，如应用服务、领域服务和领域模型等。另外，它还定义了外层依赖内层，内层对外层无感知的依赖原则。
虽然DDD分层架构、洋葱架构、六边形架构的架构模型表现形式不一样，但不要被它们的表象所迷惑。它们的核心设计思想，都是要做到核心业务逻辑和技术实现细节的分离和解耦。这三种架构模型的设计思想，正是微服务架构"高内聚，低耦合"设计原则的完美体现，而它们身上闪耀的正是以领域模型为中心的核心设计思想。
领域层面向领域模型，实现领域模型的核心业务逻辑，属于原子业务模型，它需要保持领域模型和业务逻辑的稳定，对外提供稳定的细粒度的领域服务，所以它处于架构的核心位置。
应用层面向用户操作相关的用例和流程，对外提供粗粒度的API服务。它就像一个齿轮一样进行前端应用和领域层的适配，接收前端需求，随时做出服务编排和流程的响应及调整，尽量避免将前端需求传导到领域层。应用层作为配速齿轮，则位于前端应用和领域层之间。
可以说，这三种架构都充分考虑了前端需求的变与领域模型的不变。需求变幻无穷，但变化总是有矩可循的，用户体验、操作习惯、市场环境以及管理流程的变化，往往会导致界面逻辑和流程的多变。总体来说，不管前端业务和流程如何变化，在企业没有大的业务变革的情况下，领域模型的核心领域逻辑基本不会大变。
把握好这个规律，我们就知道该如何设计应用层和领域层了。
这几种架构模型均通过分层，逐层控制需求由外向里的传导，尽量降低对领域模型的影响。面向用户的前端应用可以通过页面逻辑和流程调整，快速响应外部前端界面需求变化。应用层则通过服务组合和编排，来实现业务流程和服务的快速编排，避免将需求传导到领域层，使得领域逻辑能够保持长期稳定。只有真正的领域逻辑发生了变化，我们才去调整领域模型。
这样设计的好处很明显，就是可以保证领域层的核心业务逻辑不会因为外部需求和流程的变化而受到影响。核心领域逻辑稳定了，应用就能够保持长期稳定，就不容易出现致命的逻辑错误。
看到这里，你是不是已经猜出中台和微服务设计的关键了呢？
我给出的答案就是："领域模型和微服务的合理分层设计。"那么你的答案呢？
从三种架构模型看中台和微服务设计
结合这三种微服务架构模型的共性，下面来谈谈我对中台和微服务设计的一些心得体会。
中台本质上是业务领域的子域，它可以是DDD概念中的核心子域，也可以是通用子域或支撑子域。通常大家认为阿里的中台对应DDD的通用子域，它们将通用的公共能力沉淀到中台领域模型，对外提供通用的共享服务。
中台作为子域其实还可以继续分解为子子域，当子域分解到大小适合通过事件风暴划分限界上下文以后，你就可以定义和拆分微服务了，然后通过微服务落地来实现中台的能力。
中台建设要聚焦领域模型
三种微服务架构模型中，领域模型都处于应用的最核心位置，在领域层实现最核心的领域逻辑。
中台领域建模时，会对业务和应用的逻辑边界（聚合）和物理边界（微服务）进行清晰划分。这种边界划分，充分考虑了未来微服务架构演进和以聚合为单位的功能重组。
领域模型作为微服务设计的输入，其结果会影响后续的系统模型、架构模型和代码模型，最终影响微服务设计和项目落地。
既然领域模型这么重要，在中台设计时，我们就要首先聚焦领域模型，将它放在项目最核心的位置。
领域模型的质量决定了未来微服务的质量，它可以为你带来以下价值：
▪领域模型核心业务逻辑聚焦于核心原子业务逻辑，职责单一，可自由组合出新的复杂服务，受前端页面和流程需求影响会大大降低，有助于提升应用的稳定性；
▪领域模型高度聚焦核心领域逻辑，其代码位于最核心的领域层，有利于精炼核心代码，提高核心代码的复用率，在提升代码质量的前提下，同时降低代码行数量；
▪领域模型业务的高内聚和职责单一的特性，有利于数据内聚和数据质量的提升，有助于数据中台建设；
▪领域模型"高内聚，低耦合"的聚合边界和解耦策略，有利于提升微服务的架构演进能力；
▪合理的架构分层和职责分工，可有效降低外部需求变化对核心业务逻辑的影响。
微服务要有合理的架构分层
微服务设计要有分层的设计思想，让各层各司其职，建立松耦合的层间关系。不要把与领域无关的应用逻辑放在领域层实现，以保证领域层的纯洁和领域模型的稳定，避免污染领域模型。也不要把领域模型的领域逻辑放在应用层，这样会导致应用层过于庞大，最终造成领域模型失焦。
通过前文对三个架构模型的分析和对比，我们已经清楚了微服务内部的分层和职责边界。现在进一步思考一下，微服务之间的服务依赖关系是什么样的？如何实现微服务之间的服务集成？
在一些小型项目中，有的微服务可以直接与前端应用集成，实现某个完整的业务功能，这种是项目级微服务；有的微服务则只是中台某个子域领域模型所构建的微服务，企业级应用需要组合多个这样的微服务，才能实现企业级的业务逻辑，这种是企业级微服务。
两类微服务由于集成环境的复杂度不一样，所以集成实现方式也会有差异。下面我们将展开详细说明。
- 项目级微服务
在项目级微服务内部遵循DDD分层架构模型的规则就可以了。领域模型的核心逻辑在领域层实现，领域服务的组合和编排在应用层实现，用户接口层封装成facade接口后，发布到API网关为前端应用提供服务，实现前后端分离。
通常项目级微服务之间的集成复杂度相对较小，微服务之间的服务组合和编排，可以在某个关键微服务的应用层，通过应用服务组合和编排来完成。
- 企业级微服务
企业级的业务流程往往是多个中台的微服务一起协作完成的。那跨中台的微服务到底是如何完成服务集成的呢？
企业级微服务的集成会涉及大量应用服务的集成，因此不能像项目级微服务一样，在某一个微服务内完成跨微服务的服务组合和编排。
我们可以在多个微服务上增加一层，这一层就是BFF层（服务于前端的后端，Backend for Frontends），它的主要职能是处理跨中台微服务的服务组合和编排，实现微服务之间的服务和事务的协作。它还可以通过facade接口实现前端不同渠道应用的接口和数据适配。如果你将它的业务范围再扩大一些，或许还可以将它改造成一个面向不同行业或渠道应用的服务集成平台。
BFF微服务与其他微服务存在较大差异，BFF微服务只有应用层和用户接口层的职能，完成各个中台微服务的服务组合和编排，适配不同前端和渠道应用的个性需求，为前端应用提供粗粒度的组合服务。所以它没有领域模型，也不会有领域层，它不需要实现领域逻辑。
BFF微服务与应用服务的差异主要体现在：BFF主要是微服务之间的服务组合和编排，而应用服务主要是微服务内的服务组合和编排。
应用逻辑与基础资源的解耦
以数据模型为中心的设计模式，业务逻辑会对数据库、缓存或文件系统等基础资源产生严重依赖。正是因为它们之间这种强依赖的关系，导致我们很难进行技术升级。
所以我们在微服务设计时，需要解耦业务逻辑和基础资源逻辑。
核心业务逻辑与基础层的解耦可以通过仓储模式，采用依赖倒置设计方法来实现，从而切断业务逻辑对基础资源的依赖。当基础设施资源出现变更（比如更换数据库）时，就可以屏蔽资源变更对业务逻辑代码的影响，降低基础资源变更对应用业务逻辑的影响，以利于未来的技术升级。