事件风暴与中台业务建模实战
# 事件风暴与中台业务建模实战
前面的概念铺垫都是为了这一步：真正动手建模。这篇合并整理"如何用 DDD 重构中台业务模型"和"事件风暴"两讲，是整个课程里最偏实操的部分。
# 一、传统企业的通病：重复造轮子
很多企业同时养着传统核心系统和互联网电商/APP 平台，卖的是同样的产品，功能高度同质，典型的四类问题：
- 核心能力重复建设：报价、投保、核保这些功能，核心系统一套，电商平台又一套
- 通用能力重复建设：核心系统的用户、客户模块大而全，电商平台为了敏捷又自建缩小版
- 业务职能分离建设：同一个业务被拆在两边，各做一半——比如缴费，电商走支付宝/微信，柜台走 POS 机，合起来才是完整的缴费能力
- 两边完全独立的部分：电商特有的购物车、订单 vs 核心特有的再保、佣金
解决思路就是中台化：重复的沉淀共享，分离的重组完整，前端个性归前端，后端管理归后台。
# 二、两种建模策略
| 策略 | 做法 | 适用场景 |
|---|---|---|
| 自顶向下 | 先顶层设计，领域逐级分解建模，不受现有系统束缚 | 全新系统 / 推倒重建 |
| 自底向上 | 基于现有系统分别建模，再对齐、比对、重组 | 遗留系统演进式重构（更常见） |
# 自底向上三步走（以客户域为例）
第一步：各系统分别建模。 对电商平台和传统核心分别做事件风暴，各自建出领域模型清单。这时会发现大量名字相似的模型——它们就是重复建设的"案发现场"。
第二步：对齐业务域，比对重组。 找出能覆盖两边的基准业务域（用户、客户、承保、收付、订单），逐域比对聚合差异：
- 电商客户域：个人、积分 两个聚合
- 核心客户域：个人、视图、评级、归并 四个聚合（还有独立的团体模型）
打散重组后的客户中台：
- 个人领域模型 = 个人 + 归并 + 视图
- 评级积分领域模型 = 评级 + 积分
- 团体领域模型 = 直接沿用核心系统的（电商没有这块）
口诀：分域建模型，找准基准域，划定上下文，聚合重归类。
第三步：中台归类，映射微服务。 所有域重构完后，哪些是核心中台、哪些是通用中台、每个中台下有哪些领域模型，一张图理清楚，然后按领域模型设计微服务。
注意重组不只是搬箱子——聚合带着自己的领域对象加入新模型后，部分实体、领域服务还要按新业务场景做代码重构。
# 三、事件风暴：领域建模的核心方法
# 是什么
事件风暴（Event Storming）是一场团队工作坊：领域专家 + 项目团队用头脑风暴的方式，罗列领域中所有的领域事件，给每个事件标注引发它的命令、发起的角色，再归类整理出实体、聚合和限界上下文。
# 要准备什么
- 人：领域专家是灵魂人物。公司没这个岗位？从业务骨干、资深产品、干了多年的老开发里找——标准是"既知道业务怎么做的，也知道为什么这么设计"
- 物：几种颜色的便利贴 + 水笔 + 一面大墙。约定俗成的配色：蓝色=命令，橙色=领域事件，绿色=实体，黄色=补充说明（颜色不重要，团队统一就行）
- 场地：不要会议桌不要椅子，就要一面长墙和能走动的空间。站着刷墙比坐着开会高效得多
# 完整流程（以用户中台为例）
1. 产品愿景（可选）
对齐"这个产品到底做什么、给谁用、核心价值是什么"。团队方向已经清晰的可以跳过。
2. 业务场景分析
从用户视角走查业务流程，把每个环节的命令和事件挖出来。比如"创建用户"场景：
命令：从 HR 系统获取员工信息 → 命令：创建用户 → 事件：用户已创建 → （可能触发）通知邮件
要点是穷尽业务细节，所有人充分发言，别遗漏。
3. 领域建模（三小步）
- 提实体：从命令和事件反推"谁干的"→ 用户、账户、认证票据、系统、菜单、岗位、用户日志 7 个实体
- 组聚合：找出有管理能力的聚合根（用户、系统…），把关联的实体值对象挂上去 → 系统功能、岗位、用户信息、用户日志、账户、认证票据 6 个聚合
- 划上下文：按语义边界把聚合归堆 → 用户信息（用户+日志）、认证（账户+票据）、权限（系统功能+岗位）3 个限界上下文
领域对象太多记不住？用表格记录：对象名、类型、所属聚合、对应代码对象，一一登记。
4. 微服务拆分
理论上 3 个限界上下文 = 3 个微服务（用户、认证、权限）。但落地还要叠加非业务因素：
- 技术异构：用户日志量太大要上大数据技术？那就把日志聚合单独拆出去
- 敏态/稳态分离、弹性伸缩要求、安全等级、团队结构、包大小……
所以领域模型是拆分的重要依据，不是唯一标准。
# 四、小结
- 中台建模两条路：新系统自顶向下，老系统自底向上
- 自底向上的精髓是"比对重组"：找基准域 → 拆开聚合 → 重新归类
- 事件风暴的产出链：场景 → 命令/事件 → 实体 → 聚合 → 限界上下文 → 微服务
- 建模只管业务，拆分还得考虑技术异构、团队、运维这些现实因素