本篇要搞懂的 3 件事：平台 vs 中台到底差在哪、中台的本质是什么、传统企业的中台该共享什么（业务中台 / 数据中台 + 前中后台怎么协同）。
⚠️ 本讲偏业务战略/组织视角，几乎不涉及代码。它解决的是"为什么要建中台、中台里放什么"，为 10 讲"DDD 怎么落地中台"和 11 讲的实战案例做铺垫。
承接前文：08 讲说三种架构都指向"前台灵活、中台稳固"，并点出中台是领域的子域。09 讲把"中台"这个词单独拎出来讲透——它和大家做了多年的"平台"到底不是一回事。
平台 ≠ 中台
很多企业十多年前就把"公共能力"独立成了共享平台，于是质疑：“中台不就是平台换个名？”
关键差别在"是否整体融合"：
| 传统平台 | 中台 | |
|---|---|---|
| 做什么 | 把部分通用公共能力独立出来，靠 API/数据对外共享 | 把核心服务链路整体当一个产品做 |
| 解决什么 | 公共模块的重复建设问题 | 公共能力复用 + 页面/流程/数据从前到后的全面融合 |
| 对前台 | 提供的是彼此独立的系统 | 提供的是整体业务解决方案 |
| 各部分关系 | 仍然分离、独立 | 联通、融合成一体 |
一句话：平台解决了"复用"，但没解决"融合"；中台是平台 + 联通 + 融合。 中台源于平台，但战略高度高得多。
中台的本质
业界定义五花八门（“一千个读者一千个哈姆雷特”），但能提炼出 4 个关键词：
共享、联通、融合、创新 ——以共享方式，联通前台与中台、融合前台的流程和数据，支撑前端业务创新。
作者的落点：中台首先是一种企业级能力，提供企业级整体解决方案。它最关键的两个能力是：
- 对前台的快速响应能力
- 企业级的无缝联通和融合能力（从前台→中台→后台，设计/研发/页面/流程/数据全打通）
传统企业的中台该共享什么？
传统企业的渠道比互联网公司更杂（门店、电商、APP、开放给第三方……），功能却高度类似。过去为不同渠道各做一个独立 APP，结果融合差、体验烂、用户也不想装一堆 APP。于是趋势是：用一个 APP 联通所有核心业务链路。
因为商业模式和 IT 历程不同，传统企业要共享的内容和阿里也不同：
| 共享什么 | 对应 DDD | 为什么 |
|---|---|---|
| 通用能力中台化（业务中台的一部分） | 通用域 / 支撑域 | 沉淀、共享、复用通用能力 |
| 核心能力中台化（业务中台的一部分） | 核心域 | 不同渠道共享核心业务能力，避免"后端双核心、前端两张皮" |
| 数据中台 | — | 解决微服务拆分后的数据孤岛、数据融合、业务创新 |
💡 “后端双核心、前端两张皮”：传统核心系统一套、互联网渠道又自建一套，两边各有一份核心逻辑（双核心），前端体验割裂（两张皮）。核心能力中台化就是为了消灭这个。
前中后台怎么协同？（军队比喻）
🪞 辅助理解（作者的军队类比）：
- 前台 = 作战部队：直面战场（客户），调度中台能力打仗
- 业务中台 = 陆军/空军/火箭军等专业军种：提供战术专业能力
- 数据中台 = 情报中心 + 联合作战指挥部：汇集数据、分析、定战略战术
- 后台 = 后勤部队：采购、人力、财务、OA 等技术与管理支撑
前台：从"竖井"到"一个前台"
早期系统按业务/组织各建一套，每套有自己的前端和数据库 → 用户得登录好几个系统、竖井式操作：
中台后要让用户感觉只有一个前台——把各中台的操作、流程、界面联通融合成一条完整核心业务链路：
实现手段可借鉴微前端：前端页面解耦复用，再按核心链路动态组合、流程编排，融进不同终端和渠道。
中台：用 DDD + 微服务建设，并向外提供 API
业务中台用领域驱动设计建模，把可复用能力从各单体剥离、沉淀重组，用微服务架构建成共享中台，对前台、第三方、其它中台提供 API 服务：
⚠️ 拆微服务的副作用：单体拆成大量独立微服务后，物理隔离让"原来进程内的调用"变成"跨微服务调用"，加上前后端分离，数据被进一步切碎——若处理不好前中后台关系，反而加剧数据孤岛、碎片化。这正是数据中台要登场的原因。
数据中台的三大职能 / 三步走：
| 职能 | 建设步骤 |
|---|---|
| 全域数据采集与存储（汇总各中台数据） | 第一步：汇集各中台数据，解决数据孤岛、初级共享 |
| 按主题/场景加工（客户视图、渠道视图等） | 第二步：全维度数据的深度融合、加工、共享 |
| 需求驱动萃取数据价值，支撑创新 | 第三步：萃取价值，加速"数据→业务价值" |
数据中台不只服务分析型场景，靠**数据库日志捕获（CDC）**提升时效后，也能支撑交易型场景。
后台：把"管理需求"从核心链路剥离
后台面向后台管理人员（流程审核、采购、人力、财务、OA）。常见错误是把内控管理需求硬塞进核心业务流程——这类需求对权限/管控/流程要求高，但管理员往往只参与某个局部审核，硬塞进去会凭空增加前台界面和核心流程的融合难度。
解法：按角色/岗位聚合功能，把复杂管理需求从核心链路剥离，参考小程序模式，用特定入口嵌入前台 APP。
好处：前台应用更通用，一个 APP 能无差别同时面向外部互联网用户和内部业务人员，促进传统渠道与互联网渠道融合。
总结
中台转型不是"中台一个人的事"，要整体考虑前中后台的协同、共享、联通、融合：
- 平台 ≠ 中台：平台只解决公共能力复用，中台还要做前到后的页面/流程/数据全面融合。
- 中台本质 = 企业级能力，关键词共享/联通/融合/创新，核心价值是"快速响应前台 + 企业级无缝融合"。
- 传统企业共享什么：通用能力 + 核心能力都要中台化（业务中台），再加数据中台打通孤岛——目标是消灭"后端双核心、前端两张皮"。
- 前台靠页面/流程共享融合成"一个前台"（微前端）；中台用 DDD+微服务建设并对外提供 API；数据中台三步走打通数据；后台把管理需求从核心链路剥离。
一句话速记
平台管复用，中台管复用 + 融合；业务中台共享能力（含核心域）、数据中台打通孤岛、前台合成一个脸、后台把管理需求剥出去——一切为了"前台灵活、中台稳固、体验一致"。
思考题
你公司是怎么做前后端设计和融合的？
- 是否存在"一个业务要登录好几个系统"的竖井式体验？
- 核心能力是否在传统系统和互联网渠道各建了一套（双核心）？
- 微服务拆分后，数据孤岛问题是怎么处理的，有没有数据中台的角色？
