本篇要搞懂的 3 件事：整洁架构（洋葱）和六边形架构长什么样、这三种架构（含 07 的 DDD 分层）其实是同一个思想的不同画法、从它们的共性能看出中台和微服务该怎么设计。
承接前文：07 讲学了 DDD 分层架构。但作者说了——微服务架构模型不止这一种。08 讲把整洁架构、六边形架构也拉过来，和 DDD 分层三图并看，你会发现它们换汤不换药，背后是同一句话：把核心业务逻辑圈起来，和外部应用 / 基础资源隔离、解耦。
07：DDD 分层架构（横着画的四层）
08：整洁架构（同心圆画法）+ 六边形架构（端口适配器画法）
↓ 三者对齐
同一个思想：领域模型在最核心，依赖由外向里，外可依赖内、内不知道外
整洁架构（洋葱架构）
为什么叫洋葱：一圈套一圈的同心圆，从里到外：领域模型 → 领域服务 → 应用服务 → 最外层（UI、基础设施等易变的东西）。
最重要的原则——依赖原则：
外圈只能依赖内圈，内圈完全不知道外圈的存在。 越往里，依赖越少、层级越高、越是核心能力。
各层职能：
| 圈层 | 职能 |
|---|---|
| 领域模型（最内核） | 核心业务逻辑，封装企业级业务规则；主体是实体 |
| 领域服务 | 实现涉及多个实体的复杂业务逻辑 |
| 应用服务 | 用户操作相关的服务组合与编排，封装系统所有用例（应用特有的流程规则） |
| 最外层（适配） | 主动适配：外部用户/网页/批处理/测试访问内层；被动适配：核心逻辑访问数据库/缓存/文件/MQ 等基础资源 |
红圈内的「领域模型 + 领域服务 + 应用服务」一起构成软件核心业务能力。
六边形架构（端口适配器架构）
核心理念一句话：应用只通过"端口"与外部交互，外部都靠"适配器"接进来。（这也是微服务里 API 网关盛行的渊源。）
分内外两层：
| 层 | 职能 |
|---|---|
| 内六边形（红圈内） | 应用的核心业务逻辑（应用程序 + 领域模型） |
| 外六边形 | 和外部交互：对前端用 API 主动适配提供服务；对基础资源用依赖倒置被动适配访问 |
一个端口可对应多个外部系统，不同外部系统用不同适配器做协议转换——于是同一套核心逻辑能被人、程序、自动化测试、批处理脚本以一致方式使用。依赖方向和整洁架构一样：由外向内。
三种架构其实是一回事
别被三种画法迷惑——DDD 分层（横条）、整洁（同心圆）、六边形（端口适配器），设计思想完全一致：以领域模型为中心、分层、核心逻辑与外部隔离解耦。
看图的钥匙就是那条红线：三张图里都有一条红框，作用都一样——把核心业务逻辑 ↔ 外部应用/基础资源隔开。红框里再细分两层：
| 领域层 | 应用层 | |
|---|---|---|
| 管什么 | 面向领域模型的核心业务逻辑（原子能力） | 面向用户的用例和流程编排 |
| 粒度 | 细粒度、稳定的领域服务 | 粗粒度的 API 服务 |
| 位置/角色 | 架构核心，要保持稳定 | 像配速齿轮，夹在前台应用和领域层之间做适配 |
| 变化频率 | 稳定（业务本质，企业不大变它就不大变） | 多变（随前端体验、操作习惯、市场、流程而调整） |
🪞 辅助理解（变与不变）：这三种架构都在解决同一个矛盾——前端需求多变 vs 领域模型要稳定。
设计思路就是用分层"层层挡变化"：前端随便变 → 应用层用编排把变化消化掉 → 尽量不把变化传导到领域层 → 领域层长期稳定。
这就是"前台灵活、中台稳固"，也是中台/微服务设计的关键：领域模型和微服务的合理分层。
从三种架构看中台和微服务设计
中台是什么：本质上是领域的子域（可能是核心域/通用域/支撑域）。一般认为阿里中台≈ DDD 的通用域，把通用公共能力沉淀成中台对外共享。中台（子域）可继续分解，分到合适大小、用事件风暴划出限界上下文后，就能定义微服务来实现中台能力。
→ DDD、中台、微服务是一套连贯的体系：DDD 建模 → 划子域/限界上下文 → 落地为微服务。
要点 1：中台建设聚焦领域模型
站在全企业高度考虑能力的共享复用。先建好中台内所有限界上下文的领域模型，把领域模型放在核心位置——它会一路影响系统模型、架构模型、代码模型，最终决定微服务怎么拆、项目怎么落地。
要点 2：微服务要有合理的分层
各层各司其职、层间松耦合。两条红线：
- ❌ 别把与领域无关的逻辑塞进领域层 → 污染领域模型、破坏稳定。
- ❌ 别把领域业务逻辑塞进应用层 → 应用层臃肿、领域模型失焦（退化回三层）。
- 🔧 实在没法避免（比如新老系统对接），引入**防腐层（ACL）**做适配转换，过渡期一过就把它丢弃。
微服务之间怎么集成？ 分两种，复杂度不同、集成方式也不同：
① 项目级微服务——内部遵循分层架构即可，跨微服务调用发生在应用层：
看图：微服务 B 的应用服务 B（红框）除了编排自己的领域服务 b、c，还能调用外部微服务 A、C 发布在 API 网关上的应用服务，编排好后统一发到 API 网关供前端调用。集成点在应用层，不下沉到领域层。
② 企业级中台微服务——跨多个中台微服务的流程，不能塞进某一个微服务里编排，于是在上面加一层 BFF：
BFF（Backend for Frontends，服务于前端的后端）：专门处理跨中台微服务的组合编排 + 协调 + 多渠道前端适配。它最大的特点是——没有领域模型，所以没有领域层，只承担应用层和用户接口层的职能。
要点 3：应用和资源解耦适配
传统"以数据为中心"的设计，应用强依赖数据库/缓存/文件——换个基础资源就伤筋动骨。微服务里靠仓储模式 + 依赖倒置让应用层/领域层/基础层解耦：换数据库时只动基础层的适配代码，屏蔽资源变更对业务代码的影响（这点和 07 讲依赖倒置一脉相承）。
总结
整洁架构（洋葱）、六边形架构、DDD 分层架构是同一设计思想的三种画法：以领域模型为核心、分层、核心业务逻辑与外部应用和资源隔离解耦，依赖方向由外向内。看任何一张图，先找那条隔离核心与外部的红线。
红线内部再分领域层（稳定的核心业务规则，细粒度原子服务）和应用层（多变的用例流程编排，粗粒度 API，当配速齿轮挡住前端变化）——核心就是平衡"前端善变 vs 领域要稳"，做到"前台灵活、中台稳固"。
从共性出发看中台/微服务设计三要点：① 聚焦领域模型（中台是子域，模型定一切）；② 合理分层（别污染领域层、别臃肿应用层，必要时上防腐层；项目级微服务在应用层集成，企业级靠无领域层的 BFF 微服务做跨中台编排）；③ 用仓储 + 依赖倒置做应用与资源的解耦。
一句话速记
三种架构同一个魂——红线圈住核心、依赖一律向内；领域层求稳、应用层挡变；中台是子域、微服务来落地、BFF 管跨域编排。
思考题
系统设计时，你是怎么避免外部需求冲击核心业务逻辑的？
- 你的应用层是否真的在"挡变化"，还是变成了又一层透传？
- 有没有业务规则偷偷写进了应用层 / 控制器？（这是领域层被架空的信号）
- 跨服务/跨域的编排，你是放在某个微服务的应用层，还是有没有考虑过抽一层 BFF？
