DDD 这个缩写我早年最怕听到。代码写了几年我当然知道领域模型重要可真到会议室里让大家说清楚“领域”到底是什么多半会冷场。后来接触事件风暴才第一次感觉业务分析和代码设计之间终于有了一台能用的“翻译机”先把业务里“发生过的事”一件件铺开再顺着时间线把模型边界划出来。这一系列我们借古代商帮做场景是因为现代系统的词太抽象而商帮的生意流程却被一单货、一艘船、一本账逼得很真实。上一集我们聊了战略设计怎么给商帮划边界这一集是第 2 集标题叫“第一次事件风暴”。我们要把时间轴拉开从商帮掌柜决定进一批茶叶到最终结完账完整走一遍风暴的过程。你会看到“业务即代码”不是一句口号而是从一场便签工作坊里长出来的。1. 为什么把事件风暴搬进“古代商帮”1.1 商帮的生意是现代业务的“慢镜头”很多人觉得“ddd搞不懂”通常不是概念难而是例子太抽象。书上动不动就是“CRM 系统”“订单状态机”你听过太多次已经免疫了。古代商帮不一样掌柜要对一批货负责伙计要点货记账船老大要应付汛期和路卡。每一步都有实物、有单据、有后果少任何一环买卖就做不成。把现代互联网产品“翻译”回古代场景本身就是一种建模训练。比如“订单”对应“发运单”“库存”对应“库房台账”“支付”对应“银票结账”“风控”对应“对长期主顾的信用评估”。一旦建立起这套映射你会发现业务的核心始终是同一件事保证货物和银钱按约定流转同时把账算清楚。商帮的好处是节奏慢。现代系统里一个请求可能几十毫秒就完成而在商帮里从决定买茶到货款两清要横跨很多天。时间被拉长事件的先后顺序、状态变化、谁负责什么全都暴露在明面上。这正是事件风暴最适合的场景它需要你以“时间”为线索把事件按发生的先后摆出来。1.2 事件风暴是“业务即代码”的第一个翻译器事件风暴最早是 Alberto Brandolini 提出的一种工作坊方法。玩法不复杂一群人围着一面足够长的墙把手边听到的“业务事实”写成便签按时间顺序贴出来。每个便签是一个领域事件比如“茶叶已入仓”“路引已签发”“船队已启程”。这些事件就是业务的“原子事实”。很多人第一次参加事件风暴会愣住我们不是在讨论业务吗怎么全是“已经发生的事”这恰恰是“业务即代码”的起点。代码本质上也是事件和状态的产物用户点击是事件接口收到请求是事件数据落库是状态变更。如果我们能先把业务里所有“已经发生的事”找全后面建模就会顺很多。我也理解为什么有人看完《领域驱动设计》依然头疼因为书里一上来就是实体、值对象、聚合这些是“答案”而事件风暴是“题干”。你先把题读懂了答案自然浮现。所以第二集我坚持从“第一次事件风暴”讲起而不是直接讲聚合怎么切就是要让大家感受从业务事实倒推模型的过程。2. 第一场事件风暴的准备工作2.1 材料、人选和边界名单第一次参加工作坊最容易忽略的是物理材料。我吃过亏白板不够长便签太黏马克笔没水最后大家蹲在地上贴现场一度很狼狈。现在我会让组织者提前确认四样东西一面足够长的墙或玻璃窗至少能贴下七八十张便签三种颜色的便签纸黄色或橙色代表事件蓝色代表命令红色代表痛点或风险绿色代表角色或系统细头马克笔每人一支用来写关键词而不是长句子两块电子表或手机投屏倒计时提醒大家不要在一个环节里恋战。人选比材料更关键。理论上应该有业务人员和开发人员各一半但现实中往往来的是几个后端开发和一个产品经理。我的底线是必须有一个真正做过“商帮生意”的人。在真实项目里这个人可能是运营、财务、客服甚至仓库管理员总之必须是离业务事实最近的人。如果只有技术同学闭门造车事件风暴很容易变成“自以为是的头脑风暴”。边界名单也是必须提前说的。所谓边界就是这一场风暴只讨论哪个阶段。商帮生意如果从头讲到尾可以讲三天从寻货、议价、签约、采购、运输、验收、记账、回款直到算利润。第一次做千万不要覆盖这么长通常只画一个“核心生长段”就好比如此次只讨论“从茶叶入库到货款结清”。2.2 时间轴怎么定从“开始”到“结束”而不是“永远”我见过很多团队把时间轴贴成一条没有尽头的事件流水线这是新手最常见的失控原因。一条好的时间轴必须有明确的“最左”和“最右”两个锚点。回到商帮场景最左可以定为“掌柜确定采购意向”最右定为“账房完成总账核销”。这样中间所有事件都落在这两个锚点之间发散有边界也方便区域划分。如果把“商帮发展史”也算进来时间轴长到无从下手最后信息密度太低什么都讨论不了。时间颗粒度也要统一。不要在墙角贴一张“茶叶长途运输中”的事件回头又在旁边贴“启运第二日船体轻微渗水”。颗粒度不一致会导致后面建模的人分不清哪些事件是同一层级的。我们可以在开场约法三章主角是业务性命攸关的转折点比如“货物受损”“货款拒付”“路引被扣”至于“喝茶休息”“船工吃饭”这种流程细节不要出现在主时间轴上。提示如果一张便签上写的内容超过一行通常说明颗粒度太大或者你把两件事粘在一起了。事件风暴要求每张便签只写一件事动词用过去时例如“茶叶已入库”“验收已完成”。3. 商帮第一场风暴完整的实操拆解3.1 发散阶段先把“已经发生的事”铺满一整面墙假设我们这场风暴的成员包括掌柜业务负责人、账房财务、码头主事运输负责人、两个后端开发、一个前端开发。掌柜现场摆了开场白“我们这次的场景是茶叶从苏州运到长安中间要经过水路和陆路最后把钱收回来。”第一轮我们要做发散规则很简单不问“应该怎么设计”只问“一件一件说出来发生了哪些事”。大家七嘴八舌墙上很快铺满了便签。为了方便复盘我通常会把它们整理成一张表编号领域事件简单说明E1茶叶采购清单已确定掌柜拍板采买哪些等级的茶叶E2茶叶已从茶庄收购伙计完成收购茶庄交货E3茶叶已入库登记库房清点数量记入台账E4采购货单已签发账房开具发运所需单证E5船队已启程货船载货离开苏州码头E6途中遇到汛期停航船队在镇江一带等待水位回落E7部分茶叶已受潮中途渗水造成损失E8船队已抵达长安码头货物上岸等待验收E9茶叶已逐箱验收收货方清点数量并抽样验货E10货款已结清收货方付款账房销账这个阶段最忌讳的是技术词汇。如果某个程序员脱口而出“数据库里的订单状态改为已发货”我会立刻打断请他翻译成业务语言“船队已启程”。就像代码命名一样事件名称一旦使用了技术内行才能懂的话后面所有讨论都会被带偏。有个很容易忽略的细节E6“途中遇到汛期停航”并不是直接发生在主流程上的“正常转折”但它非常重要。因为它制造了时间延迟导致后面的“受潮”和“验收短少”有了上下文。事件风暴的价值就在于此敢于把正常流程之外的“麻烦事”也贴出来后面分析异常分支时才会有素材。3.2 收束阶段命令、角色、热点怎么填进去第一轮发散完墙上已经有一串事件了。这时候进入第二轮给每个事件找出“是什么触发的”以及“是谁做的”。商帮里的触发超级好理解。E1“茶叶采购清单已确定”触发它的是“掌柜决定采购茶叶”。这是一个命令放在事件左边用蓝色便签写清楚往往不写“用户点击按钮”而是直接写业务动作“掌柜下达采购指令”。E4“采购货单已签发”是命令“账房签发采购货单”的结果。E9“茶叶已逐箱验收”是命令“收货方逐箱验收”的结果。命令和事件是一枚硬币的两面命令表达意图事件表达结果。代码里也是这样接口收到一个请求是意图领域层处理完产生一个事件是结果。如果你在建模时只知道写“保存订单”却说不清这个操作会引发哪些事件那后面 Testability 和可追踪性都会很头疼。角色和系统用绿色便签。凡是产生命令或消费事件的人/系统都标出来。商帮里角色包括掌柜、伙计、账房、码头主事、收货方如果用户说“驿站送来了通关文书”这就是一个外部系统同样用绿色标在事件旁边。红色便签代表热点也就是业务上谁最痛、最怕什么。这场风暴中大家在 E6 旁边贴了一张“汛期不可控”在 E10 旁边贴了一张“货款拖欠风险”还在 E9 旁边贴了“货损责任扯不清”。这些热点不需要立刻解决但它们是未来领域服务优先级的重要参考哪个模块最值得写高质量代码先解决哪个痛点答案已经摆在墙上了。3.3 第一版“商帮事件拓扑”是怎么拼出来的三轮便签贴完墙上已经不只是一串事件了而是一张拓扑图最左是命令中间是事件旁边标着角色或系统红色的是热点。我们会沿着时间线从头到尾讲一遍“商帮故事”掌柜确定采购清单伙计收茶入库账房签发单证船队启程中途受汛期影响停航部分茶叶受潮最终收货方验收货款结清。这一步一定要“讲出来”而不是“看”。因为讲的时候会发现逻辑漏洞比如 E7 茶叶受潮之后下一步应该是“货损数量已记录”而不是直接跳到“船队已抵达”。这种漏掉的事件往往藏着关键的聚合逻辑谁负责记录损失什么单证会更新账房如何据此少收钱。第一次拼出的拓扑通常会比较乱没关系。我们要的是“完整性”不是“美观”。只要故事能够顺着时间轴讲通每一个转折都有触发命令每一个事件都有明确的负责人那么这套事件流已经足够作为后续需求沟通的共同语言。注意不要在第一轮就动用太多架构话术。如果有人在墙上指着一串事件说“这里应该做成一个微服务”请把话题拉回来。此时讨论的是业务事实不是部署拓扑。4. 从事件风暴到代码聚合、边界与六边形4.1 聚合边界不是靠感觉而是靠事务一致性事件风暴结束墙上摆满了领域事件。下一步要做的不是急着写代码而是找到“哪些事件必须同时成立或者必须同生共死”这就是聚合。商帮里最典型的聚合是“发运单”。E4 签发了采购货单E5 船队启程E9 验收E10 货款结清这些事件都围绕同一张单据发生。如果船队在中途受潮E7 发生后我们必须马上更新单据上的货损数量并生成“货损已确认”的事件。此时“发运单”这个聚合负责保证一件事货物数量 货损数量 原始发运数量不管中间发生多少次意外这个等式不能破。你可能会问聚合边界到底是“经验”还是“推导”我的体会是它更像从事件流里推导出来的。事件风暴一开始确实靠直觉把 E5 到 E10 圈在一起但真正的坚定感来自“不变量”的约束哪些事件之间存在强一致性哪些事件允许异步延迟在商帮例子里“验收完成”和“货款结清”之间可能有几天账期所以它们是两个聚合之间的最终一致性但“验收完成”和“发运单状态变更”必须是同一事务否则账房就会看到“货已验收但单据还是未交付”的荒谬状态。代码里的聚合边界如果和事件流不匹配通常表现为一个“订单”类里拖着几百行库存逻辑或者一个聚合被拆成了十几个微服务每次修改跨库操作都胆战心惊。回看事件风暴墙聚合的个数应该和“事务一致性上下文”的个数大体一致。4.2 有界上下文与六边形架构事件就是端口的电文在战略层面商帮可以分出好几个有界上下文采购上下文、仓储上下文、运输上下文、财款上下文。它们之间的边界在哪里事件风暴给你的答案是看“同一个人”还是“同一张单据”。运输上下文关心的是路引、船队、汛期财款上下文关心的是计价、银票、核销。它们共享“发运单”这个事件但对它的理解不一样。这一点落到代码上就会连接到你常听到的“六边形架构和ddd”。六边形架构的核心思想是领域模型在正中间外侧通过端口和适配器与外部分交通。事件风暴产出的“领域事件”恰好就是这个六边形的电文格式。入站端口接收命令比如“掌柜下达采购指令”入站适配器把 HTTP 请求、MQ 消息转成领域命令领域层处理命令产生一个或多个领域事件出站适配器把领域事件投递给外部系统如通知仓储系统“茶叶已入库”。你看事件风暴没有直接给你画六边形但当你沿着事件流把每个事件的来源和去向标清楚六边形的形状自己就出来了。我们能说“业务即代码”是因为这些领域事件的名字不需要翻译它们既是业务人员在会上说出来的词也是程序员在代码里定义的事件类名。事件成了共享语言里最实实在在的载体。我在真实项目里见过团队被“要不要用微服务”卡住解法很朴素先一起做事件风暴画出事件流再根据事件流的交互频率和一致性要求决定哪些上下文可以独立部署。事件抽屉里有哪几张便签代码里就对应哪个六边形边界。如果你还在纠结“六边形架构和ddd”到底怎么结合我建议不要先读更多书回来看看你的事件图。4.3 第一次做事件风暴的四个落地建议第一时间盒定在 90 分钟以内。视业务复杂度选择区域不要试图一次风暴覆盖整条业务长链路。宁可分三段各开一场也不要一场贴到眼睛酸。第二所有事件统一用“过去时”。写“茶叶已入库”不写“入库”写“货款已结清”不写“打款”。这个习惯逼着大家先想事实再想操作。事实是不可争辩的命令却容易变成需求争论。第三一定要留出五分钟“沉默阅读”。发散结束后每个人都先安静看一遍整面墙再看有没有缺漏事件。不聊技术只聊时间线上有没有讲不通的地方。沉默阅读常常能弥补最重要的盲区。第四及时拍照并把事件编号转录到文档里。墙上的便签很容易被保洁阿姨清理掉。我通常要求每人离场前拍一张全景然后由组织者把事件表、命令表、红色热点表整理成共享文档作为后续 DDD 建模的输入。5. 现场事故与复盘我当年是怎么搞砸的5.1 三个典型“现场事故”和修复手册不是所有事件风暴都能顺利跑到聚合边界那一步。我见过甚至自己踩过的坑大致可以整理成三类型现象背后原因修法墙上贴满了“创建订单”“更新状态”之类的技术动词参与者习惯用代码术语复述业务统一改用“已创建订单”“状态已更新”并要求动词来源是业务人员真实用语所有人枯坐 20 分钟没人贴便签领域太大、无从下手大家怕贴错现场指定一个“主持人兼第一个便签人”先贴出第一张“掌柜已确认采购意向”打破僵局事件序列出现巨大跳跃从“启程”直接跳到“到货”大家只描述了理想 happy path看不到异常用红色便签逐一追问“中间最怕发生什么”强制补充受潮、扣货、拒付事件其中第二条我印象特别深。第一次带团队做风暴时我以为大家会踊跃发言结果前十分钟冷场。后来我才明白不是没有人懂业务而是没有人敢做“第一张便签”。从那以后我作为主持人永远提前备好三张“种子事件”贴在墙上给全屋子的人一个起点。这也是为什么商帮例子里我特意先贴出 E1“茶叶采购清单已确定”它不是影响范围最大的事件但它最容易引发更多想象。5.2 命名规范和后续串联最后一道工序事件风暴不是一次性的活动它产出的不是一张图而是一份需要持续维护的词汇表。因此第二次复盘时我们做的最重要的事是“统一命名”。团队里每个人写出来的便签风格可能完全不同。有人写“茶叶运出苏州”有人写“船从苏州出发”。业务上两件可能是同一件事到了代码里就会裂成两个事件类给后续维护带来很大麻烦。我的做法是在每次风暴结束后用一个共享术语表把所有等价表达收敛成一个标准事件名例如统一为“船队已从苏州启程”并在表里登记别名“茶叶已运出苏州”。命名还有一条铁律避免在事件名里夹带技术实现。不要写“库存表已更新”要写“茶叶库存数量已调整”。“已更新”可以指任何一张表而“数量已调整”才是有业务含义的事实。代码架构可以随时重构领域事件一旦命名错后面所有业务沟通都会受牵连。串事件这一点也容易忽略。事件风暴散场后很多团队会把这面墙忘掉过两周直接进入写代码阶段等于把前期的共同语言丢回垃圾桶。我习惯做一次“故事线串联”找一位最会讲业务的同事沿着时间轴把整个事件流从头到尾讲一遍录下来然后整理成文字。将来需求变更、新人入职、跨组沟通都拿这份“事件流故事线”作为起点。一个能从头讲通的故事才配得上“业务即代码”这四个字。如果你只记住一条经验我希望是下次遇到复杂业务不要急着画用例图先找一堵墙把所有“已经发生的事”按时间贴出来。那片墙就是你第一次事件风暴的起点。