⚠️ 时效性说明（2026 年补充）
本文写于 2020 年 5 月，正值”中台”概念的高峰期。此后行业实践发生重大变化：
- 2022 年起：中台概念显著降温，多家大厂公开反思中台建设的投入产出比
- 2023 年 3 月：阿里巴巴启动”1+6+N”组织变革，标志性的拆分了此前 6 年建设中台沉淀的业务能力，张勇在内部信中明确提到”快速决策、放下包袱、向前看”
- 当前共识：中台适合业务条线多、能力复用确实成立的场景；对中小公司、单一业务线，中台往往是过度设计
本文保留 2020 年的原始视角作为历史记录，请读者带着批判性视角阅读，把中台视为一个”可选项”而非”必选项”。DDD 本身的方法论价值（领域建模、限界上下文、聚合）与中台无关，依然有效。
前言
中台这个词被喊了很多年，但很多人没真正搞懂它。
有人说“中台就是大平台”，有人说“中台是微服务的另一种说法”，也有人说“中台是阿里的特有玩法，不适合其他公司”。
这一篇我们从 DDD 的视角，把中台讲清楚。
一、平台 ≠ 中台
很多企业在 10 多年前就做过“大平台”：把通用能力（用户、认证、日志）抽出来作为共享服务。
这是中台吗？
答案是：这是平台，不是中台。
平台的关键词是“公共能力复用”：
- 用户中心、认证中心、消息中心是平台。
- 解决了“重复造轮子”的问题。
- 但没有解决业务流程打通的问题。
中台的关键词是“业务能力共享 + 业务联通”：
- 不只是抽公共能力，还要打通核心业务链路。
- 前端用户感受到的是一个完整的业务流程，而不是“跳到另一个系统”。
- 核心业务能力也中台化（不只通用能力）。
平台解决“代码复用”，中台解决“业务复用 + 体验一致”。
二、中台的本质：企业级能力复用
我用一句话定义中台：
中台是企业级能力的复用平台，它提供一套企业级的整体解决方案，解决从企业、集团到生态圈的能力共享、联通和融合问题，支持业务和商业模式创新。
关键词：
- 企业级：不是部门级，是整个企业的能力复用。
- 能力复用：业务能力，不是技术能力。
- 联通、融合：打通业务链路，不是孤立的服务。
- 支撑创新：让新业务可以快速基于中台搭建。
三、在线教育平台应该共享什么？
我用一个在线教育 SaaS 公司的真实案例，讲清楚中台应该建什么。
业务背景
公司主营业务包括：
- K12 在线大班课
- 职业培训课程
- 企业内训（B2B）
- 直播课
4 个业务线，用户可能重叠（同一个家长可能给孩子买 K12，自己买职业课）。
如果每条业务线都自己建一套系统：
- 用户体系重复（每个业务一套用户）。
- 课程内容重复（不同业务都做课程管理）。
- 支付订单重复（每条业务一套订单）。
- 用户体验差（用户要注册 4 个账号）。
这就需要中台来解决。
应该共享的能力
我把这家公司的中台分为 3 类：
1. 业务中台（核心域中台 + 通用域中台）
| 中台 | 共享的能力 | 复用业务 |
|---|---|---|
| 课程中台 | 课程内容管理、章节、知识点 | K12/职业/企业内训都复用 |
| 学习中台 | 学习进度、笔记、答疑 | 所有在线学习业务 |
| 教学中台 | 老师管理、排课、作业批改 | K12/职业/直播课复用 |
| 证书中台 | 证书模板、发放 | K12/职业/企业内训都复用 |
| 用户中台 | 用户注册、登录、实名 | 所有业务复用 |
| 订单支付中台 | 订单、支付、退款 | 所有业务复用 |
| 营销中台 | 优惠券、活动、积分 | 所有业务复用 |
2. 数据中台
| 能力 | 价值 |
|---|---|
| 用户画像 | 同一个家长在 K12 和职业课的画像融合 |
| 学习数据 | 全平台学习行为分析 |
| 教学数据 | 老师授课效果分析 |
| 业务数据 | 全公司经营数据看板 |
3. 通用平台（技术中台）
| 能力 | 说明 |
|---|---|
| DevOps 平台 | 统一 CI/CD、监控告警 |
| API 网关 | 统一接入、限流、认证 |
| 数据计算平台 | 离线/实时计算 |
| AI 平台 | 智能推荐、智能批改 |
不应该共享什么？
不是所有能力都要进中台。中台是“被多个业务共同需要”的能力。
- 业务独有的能力不进中台：K12 的“家长督学”是 K12 独有的，不应该进中台。
- 变化频繁的能力不进中台：中台一旦上线，改动成本极高。如果一个能力还在快速试错阶段，先放在业务里。
- 小众能力不进中台：用得少的能力，沉淀成中台的成本不划算。
四、业务中台 vs 数据中台
| 维度 | 业务中台 | 数据中台 |
|---|---|---|
| 目标 | 业务能力复用 | 数据价值萃取 |
| 核心 | 业务逻辑、领域模型 | 数据采集、加工、应用 |
| 服务对象 | 前端业务应用 | 业务应用 + 决策者 |
| 技术栈 | 微服务、DDD | 大数据、ETL、数据仓库 |
| 衡量指标 | 业务调用量、复用率 | 数据应用数量、决策支持度 |
业务中台和数据中台是互补的：
- 业务中台产生数据（用户在学习中台产生学习行为）。
- 数据中台消费数据（基于学习行为做用户画像、智能推荐）。
- 数据中台的产出反过来支持业务中台（智能推荐结果回写到学习中台，提升学习效果）。
五、前中后台的协同
中台不能孤立存在，必须和前、后台协同。
前台
前台是直接面向用户的应用。包括：
- 移动 App
- 微信小程序
- PC 网站
- 智能硬件 App（如果做教育硬件的话）
前台的特征：
- 变化频繁（用户体验、运营活动经常改）。
- 高度定制（不同业务线的前台风格可能完全不同）。
- 轻业务（业务逻辑下沉到中台，前台只做展示和交互）。
前台怎么用中台？
通过 API 网关调用中台暴露的应用服务。前台不直接连数据库、不直接调其他业务的前台。
中台
中台是能力的供给方。前台要什么能力，从中台拿。
中台怎么避免被前台拖着改？
- 中台提供稳定的 API，版本化管理。
- 前台需求变化时，优先通过适配层（BFF/防腐层）适配，而不是改中台。
- 中台有自己的迭代节奏，不被单个前台的紧急需求绑架。
后台
后台是面向内部管理人员和后台系统：
- OA、财务、HR、采购
- 内容审核
- 风控、合规
后台的特征：
- 强权限管控
- 流程复杂
- 改造成本高
后台怎么对接中台？
- 后台通过中台 API 操作业务数据。
- 后台独立于业务中台，不污染中台的领域模型。
六、中台建设的常见误区
误区 1：中台越大越好
错。中台只承载被多个业务共同需要的能力。中台越大，耦合越严重。
原则：只把 3 个以上业务线都需要的能力进中台。否则就放在业务里。
误区 2：先建中台再发展业务
错。中台是业务发展到一定阶段的产物，不是“灵丹妙药”。
正确顺序：
业务发展 → 发现重复建设 → 抽象出中台 → 中台支撑更多业务业务还没发展起来就建中台，会建出一个“空中楼阁”。
误区 3：中台是技术活
错。中台首先是业务活，然后才是技术活。
关键动作：
- 业务梳理：哪些能力是通用的、哪些是核心的。
- 领域建模：用 DDD 做领域设计。
- 组织调整：康威定律——中台需要专门的中台团队。
误区 4：中台一旦建成不能改
错。中台也要演进。但中台改动影响面大，改动要谨慎。
- 每 6-12 个月回顾中台范围。
- 新能力评估是否进中台。
- 过时能力从中台剥离。
七、中台和 DDD 的关系
DDD 战略设计的产物，正好是中台建设的蓝图。
DDD 战略设计 中台建设
───────── ──────
领域划分 → 业务域识别
子域划分 → 中台范围确定
核心/通用/支撑域划分 → 核心中台/通用中台识别
通用语言 → 中台 API 契约
限界上下文 → 中台边界
领域模型 → 中台数据模型DDD 是中台建设的最佳方法论。
八、我们怎么做中台
我之前做的一个项目，分 3 步走：
第 1 步：业务抽象（3 个月）
- 全公司业务梳理。
- 识别通用能力、核心能力。
- 输出业务能力地图。
第 2 步：领域建模（2 个月）
- 用 DDD 战略设计，对每个中台做领域建模。
- 划分限界上下文，确定中台边界。
- 输出领域模型文档。
第 3 步：中台落地（6-12 个月）
- 按限界上下文拆微服务。
- 逐步迁移业务到中台。
- 老系统逐步退役。
节奏：业务不停、中台慢建。不要停下来做中台，要边跑边建。
总结
这一篇我们讲了：
- 中台是“企业级能力复用平台”，不只是技术能力复用，更是业务能力复用。
- 业务中台 + 数据中台 + 通用平台 构成完整中台体系。
- 不是所有能力都进中台，只进“3+ 业务复用”的能力。
- 中台建设要 DDD 战略设计做指导。
- 前中后台要协同，不能孤立建中台。
下一篇我们讲DDD+中台+微服务三者如何协作，从战略设计到微服务落地的完整流程。