DDD分层架构与微服务架构模型
# DDD 分层架构与微服务架构模型
这篇合并整理分层架构和三种主流架构模型（DDD 分层、整洁架构、六边形架构）的对比，它们表面长得不一样，内核其实是同一个思想。
# 一、DDD 四层架构
从上到下：用户接口层 → 应用层 → 领域层 → 基础层。
| 层 | 职责 | 关键点 |
|---|---|---|
| 用户接口层 | 面向用户/前端展示信息、解释指令 | 引入 DTO，前端要什么拼什么 |
| 应用层 | 服务组合与编排，面向用例和流程 | 很薄，理论上不含业务规则；还负责认证、权限、事务控制、事件发布订阅 |
| 领域层 | 核心业务逻辑 | 聚合根、实体、值对象、领域服务都住这里 |
| 基础层 | 数据库、缓存、MQ 等技术资源 | 通过依赖倒置被上层解耦 |
最容易踩的坑就一条：业务逻辑放错层。
- 领域逻辑漏到应用层 → 应用层越来越胖，领域模型失焦，慢慢退化回三层架构
- 与领域无关的逻辑塞进领域层 → 污染领域模型
业务逻辑的归属口诀（延续上一篇聚合的划分）：
单实体逻辑 → 实体方法（充血模型）
跨实体逻辑 → 领域服务
跨聚合编排 → 应用服务
2
3
# 二、严格分层：每层只调用它紧邻的下层
DDD 分层有个重要原则：只依赖自己正下方的层（严格分层架构）。领域服务只能被应用服务调用，应用服务只能被接口层调用，逐层封装。
好处很直接：下层服务变更时，只需要逐层通知上层，依赖关系清晰可控。松散分层（允许跨层调用）短期省事，长期服务依赖网会乱成麻，还容易把核心业务逻辑泄漏出去。
# 三、依赖倒置：换数据库不再要命
传统三层架构里，业务代码直接依赖 DAO、依赖具体数据库，换库等于重写。DDD 用仓储模式（Repository）+ 依赖倒置解决：
- 仓储接口放在领域层（领域层只认接口）
- 仓储实现放在基础层（换 MySQL/达梦/MongoDB 只动这里）
之前整理过的 MySQL 迁移达梦 那种项目，如果当初架构是仓储模式，迁移成本会小非常多——这就是依赖倒置的现实价值。
# 四、三层架构怎么演进到 DDD 分层
对照关系：
| 三层架构 | DDD 分层 | 变化点 |
|---|---|---|
| 表示层 | 用户接口层 | 引入 DTO |
| 业务逻辑层 | 拆成应用层 + 领域层 | 编排归应用层，领域逻辑归领域层 |
| 数据访问层 | 基础层 | DAO → 仓储模式（接口在领域层，实现在基础层） |
| 公共工具类 | 基础层 | Utility/Config 统一归置 |
# 五、整洁架构与六边形架构
# 整洁架构（洋葱架构）
同心圆结构，从内到外：领域模型 → 领域服务 → 应用服务 → 外围易变内容（UI、基础设施）。
唯一铁律是依赖原则：外层只能依赖内层，内层完全不知道外层的存在。越靠里越核心越稳定。
# 六边形架构（端口适配器架构）
核心理念：应用通过端口与外部交互（API 网关流行的思想源头）。
- 内六边形：核心业务逻辑（应用 + 领域模型）
- 外六边形：各种适配器——前端访问走主动适配（API），访问数据库/MQ 走被动适配（依赖倒置）
一个端口可以接多个外部系统，各自用不同的适配器做协议转换。
# 三者对比：形不同，神相同
把三张架构图摆一起，都能画出同一条"红线"——把核心业务逻辑和外部世界（前端、基础资源）隔离开：
- 领域层在最核心：原子能力，细粒度服务，追求稳定
- 应用层是"变速齿轮"：对接前端多变的需求，做编排适配，尽量不让需求变化传导到领域层
- 外部依赖全部通过适配/倒置解耦
背后的洞察是：需求天天变的是界面和流程，不怎么变的是核心领域逻辑。分层就是按"变化频率"给系统做隔离——外面越灵活，里面越稳固。
# 六、架构演进：聚合是搬家的最小单位
领域模型不是画完就完了，它跟着业务演进，微服务也要跟着变。演进的抓手是聚合：
- 微服务 1 里的聚合 a 被高频访问、拖累整体性能 → 把聚合 a 整体剥离成独立的微服务 2
- 业务发展后发现聚合 d 更适合放微服务 1 → 整体搬迁过去
前提是设计时就守住聚合的代码边界（不跨聚合调用领域服务、不跨聚合联表），搬家才能低成本。
服务也会演进：领域层先只提供原子服务，当发现多个应用服务总是以相同顺序组合领域服务 b、c 时，就可以把 b+c 下沉合并成新的领域服务——领域模型会越用越精炼。
# 七、项目级微服务 vs 企业级中台微服务
两类微服务的集成方式不一样：
- 项目级微服务：内部走分层架构，跨服务调用发生在应用层——应用服务除了编排自己的领域服务，也可以编排其它微服务发布在 API 网关上的服务
- 企业级中台微服务：跨多个中台微服务的流程，不该塞进任何一个微服务里，而是在中台微服务之上加一层 BFF（Backend for Frontends）——它没有领域模型、没有领域层，专门做跨中台的服务组合编排和多渠道适配
# 八、小结
- DDD 四层：接口层薄、应用层薄、领域层厚、基础层被倒置
- 三种架构模型殊途同归：以领域模型为核心，核心逻辑与外部隔离
- 应用层挡住需求的变，领域层沉淀业务的不变
- 聚合边界守得好，架构演进就是"搬积木"