DDD、中台与微服务的铁三角

# DDD、中台与微服务的铁三角

合并整理中台相关的三讲（含答疑）。一句话先总结三者关系：中台是业务模型，微服务是模型的系统落地，DDD 是同时指导两者的方法论。

很多公司说"我们十年前就做平台了，中台不就是换个名字？"——还真不是。

平台：把部分通用能力独立出来，通过 API 共享，解决重复建设问题。但各平台之间仍然是分离独立的，没有从页面、流程到数据的全面融合。

中台：站在企业级高度，把核心服务链路（会员、商品、交易、营销……）当作一个整体产品来做，给前台提供的是业务解决方案，不是一堆彼此独立的系统。

差异总结成三个关键能力：

平台解决了"复用"，但离"联通、融合"还有距离。

阿里的中台更多对应 DDD 的通用域（通用能力沉淀共享）。但传统企业渠道多（门店、电商、APP、开放给第三方的生态），历史上每个渠道各建一套系统，导致"后端双核心、前端两张皮"。

所以传统企业不仅要把通用能力中台化，还要把核心能力中台化，让不同渠道复用同一套核心业务能力。

有个很形象的比喻：

几个实践要点：

前台：不管后端有多少个中台，用户感受到的只有一个前台。可以借鉴微前端思想，页面动态组合 + 流程编排，实现前端复用和融合。

数据中台：三步走——先汇集各中台数据解决数据孤岛，再做全维度深度融合加工，最后萃取数据价值支持业务创新。注意它不只服务分析场景，配合 CDC 技术也能支撑交易型场景。

后台：管理类需求（审批、内控）别嵌进核心业务流程，按角色聚合功能后像小程序一样挂到前台入口。核心链路干净了，各渠道前台才容易融合。

把 DDD 领域建模和中台建设两个视角对到一起：

企业全部业务 = 领域
    ├── 核心域   → 核心中台
    ├── 通用域   → 通用中台
    ├── 支撑域   → 通用中台
    └── 限界上下文 → 微服务

1
2
3
4
5

子域和中台在功能范围上是一致的，所以干脆统一语言：子域 = 中台。以保险为例，核心中台是营销、承保、理赔，通用中台是订单、支付、客户、用户。

第 1~4 步是战略设计（业务建模），第 5 步是战术设计（系统落地）。

工厂模式：聚合内对象多时，聚合根、实体、值对象要同时实例化，全靠聚合根构造太复杂，交给工厂封装。构造简单就不用
仓储模式：应用逻辑通过仓储接口访问数据，仓储实现放基础层。换基础组件（比如换数据库）只换仓储实现，业务代码不动——这就是依赖倒置的现实收益
补充：统计、批处理这类找不到聚合根的场景（实体相互独立但业务内聚），可以当"非典型聚合"处理，不设聚合根，其它设计方法照用。不要为了 DDD 而 DDD

微服务内的事件总线不是必须的——进程内事务好控制，如果不存在聚合间数据不一致的风险，直接用应用服务协调即可，别为引入而引入。

上次更新: 2026/10/08, 03:22:29