事件风暴工作坊：用贴纸搞定领域建模

可视化演示

展示事件风暴工作坊从Big Picture到Design Level再到微服务边界划分的完整流程，切换模式查看各阶段核心方法。

认识事件风暴

小区要办美食节，大家在微信群里聊得热火朝天，却越聊越乱：有人说报名，有人说采购，有人说场地，信息全堵在聊天记录里。王阿姨提议：「别在手机里吵了，去活动室，把整件事贴到墙上。」于是大家拿不同颜色的便签，从第一件发生的事开始，一张张往回推：报名截止、摊位开张、菜品售罄……不到半天，整场美食节从头到尾的流程清清楚楚摆在了墙上。

这个「在墙上一起重演业务」的方法，就是事件风暴。它由 Alberto Brandolini 提出，本质上不是画图考试，而是一场把领域知识从每个人脑子里搬到墙上的协作仪式。它有两种粒度：Big Picture 像看整张活动安排表，帮团队建立全局视野；Design Level 像专门设计某个摊位怎么运转，用于深入建模。无论哪种粒度，核心动作都是「贴便签、排顺序、讲理由」。

工作坊里的便签颜色不是装饰，而是共同语言：橙色写「已经发生的事」——领域事件；蓝色写「想做的事」——命令；紫色写参与者；绿色写业务规则；黄色圈出聚合；粉色标出痛点。颜色让人群不用开口解释，就能读懂彼此的意图。

就像美食节最后赢得的不是墙上那张时间线，而是大家终于敢说「原来整件事是这样的」——事件风暴的收获，正是这份共识。

工作坊准备

办美食节前，王阿姨会先做三件事：定场地、叫人、想清楚「这次到底解决什么问题」。事件风暴也一样，准备工作决定成败。

首先是场地。你需要一面足够长的白墙，至少能铺开一两个小时演进出来的事件流。用美纹纸贴出时间线，准备好大号便签和粗头马克笔。空间最好大到能让 8 到 15 人同时站着围观，而不是挤在会议室里轮流看投影。

其次是人员。业务专家、产品经理、开发、测试、架构师、运维，甚至财务和客服都可以来。不要只叫技术团队，否则你贴出来的是技术团队脑补的业务。引导师只负责提问题、控节奏，不负责给答案。

最后是聚焦问题。今天要回答的是什么？「新业务怎么上线」「遗留系统哪里最痛」「AI 客服为什么总答非所问」都可以。问题越具体，贴纸风暴的落点越准。

准备阶段就像选锅具和买食材：锅不够大，再好的菜谱也施展不开；人没到齐，最后端上桌的菜一定不是大家想吃的。

领域事件收集

美食节正式开始前，最怕的就是「我们不知道从哪一步开始」。事件风暴的解法很简单：先别管流程和系统，只收集「已经发生的事」。

领域事件是一个发生在过去的事实，比如「报名截止」「摊位开张」「菜品售罄」。它用过去时态写，因为它是业务世界里的完成态，不是待办，也不是猜想。写「报名截止」，不写「要截止报名」；写「菜品售罄」，不写「准备补货」。一旦写错时态，讨论就会从事实滑向幻想。

在这个阶段，大家做的是 Big Picture：把脑子里所有相关事件都扔到墙上，再按时间顺序从左到右排好。遇到不确定的地方就贴一张「热点」标记，红色或粉色便签都可以。这部分不是为了得到正确答案，而是为了把业务地图铺满整面墙，让所有人都看见全局。

贴完所有事件，王阿姨看着满墙的橙色便签笑了：「原来从报名到收摊，一共就这么多节点。」这个「原来如此」的时刻，就是 Big Picture 的价值。

命令与角色

事件墙铺好了，接下来要问一个关键的「为什么」：这件事是谁干的？什么动作触发了它？

命令就是「想要做的事」，它表达的是业务意图，比如「提交报名表」「打开摊棚」「通知补货」。命令通常由某个角色发起：摊主、志愿者、管理员。没有角色，命令就像没有主人的便利贴；没有命令，事件就像凭空掉下来的巧合。

事件风暴里最有趣的环节是沿着时间线来回追问。看到一个事件，往左问：「什么命令导致了它？」看到一个命令，往右问：「它会生成什么事件？」当一个事件成为下一轮业务的导火索，比如「菜品售罄」触发「通知补货」，事件和命令就形成了接力链。业务规则这时候也会冒出来：谁有权限发起命令？什么条件下命令被允许？这些规则用绿色便签贴在命令和事件之间。

在美食节现场，售罄的摊位一声吆喝，志愿者就去仓库补货。这个“吆喝”和“补货”之间的线，就是事件与命令之间最鲜活的业务链路。

聚合设计

现在把镜头推近，进入 Design Level。只见满墙便签已经排成几条故事线，但还不够：哪些便签应该被圈在一起，作为一个整体来修改？

「摊位」就是一个很好的例子。一个摊位的报名、开张、售罄都是围绕同一个身份发生的，它们必须一起被维护，不能只改一半。这个被圈出来的整体就是聚合（Aggregate）。聚合是一个一致性边界：边界内的事物要么一起成功，要么一起失败。边界外的事物通过聚合根引用，而不是直接改内部细节。

识别聚合时，可以问三个问题：哪些业务不变量必须同时满足？哪些便签共享同一个实体标识？哪组事件只要发生一次，就会带来一连串状态变化？回答完，用黄色便签或线圈把这些事件圈起来，聚合就出现了。聚合不是越大越好，也不是越小越好，而是刚好能装下一次业务操作所依赖的完整性。

摊位上所有东西都围在同一个棚子里：锅、灶、菜单、收款码。如果有人把菜单改成另一家摊位的，这个摊位就不再完整。聚合的边界，就像摊棚的边界一样，必须清晰且稳定。

限界上下文

美食节办到一半，王阿姨发现一个有意思的现象：同样叫「摊位」，在报名组眼里是一个编号，在餐饮检查组眼里是一个卫生责任人，在财务组眼里是一个收入主体。同一个词，在不同场景下含义不同。

这就是限界上下文（Bounded Context）。它把一个大型业务划分成多个语义边界，每个边界内使用自己的统一语言。在「报名上下文」里，一个摊位是候选摊主；在「经营上下文」里，一个摊位是正在营业的单元。强行让所有人共用同一个「摊位」概念，模型会变得臃肿且充满歧义。

事件风暴的 Big Picture 阶段会把不同的业务区域区分出来，并用上下文地图画出它们的关系：上游还是下游？共享内核还是客户-供应商？上下文之间的关系，决定了团队之间如何同步模型、如何协作，也决定了 API 和数据所有权。

美食节的报名组和财务组不需要共用同一本台账：报名组关心有没有人，财务组关心收了多少钱。各管各的语义，只在交界处对账，这就是限界上下文的智慧。

划分微服务

墙面上的上下文画好了，最后一个问题水到渠成：微服务从哪里切？

答案是：优先对齐限界上下文，而不是对齐每一个聚合或每一条命令。一个限界上下文往往对应一个完整业务能力，比如「报名管理」「现场经营」「资金结算」。一个服务内部可以包含多个聚合，只要它们都属于同一个业务上下文、共享同一套领域语言，并且需要一起演化。

事件风暴帮团队避免了两个极端：一是把所有东西塞进一个「大泥球」单体；二是把每个聚合都拆成微服务，结果服务数量爆炸、数据散落、改一个流程要跨十个系统。正确姿势是让服务拥有自己的数据，对外只暴露契约；上下文之间的交互通过事件或 API，而不是直接访问对方数据库。

把整个美食节切成「报名」「经营」「结算」三个岛，每个岛自己管自己的摊位数据，岛与岛之间只传轻量消息。这样既不会过度碎片化，也不会让一个岛包揽所有事。

实操与落地

知道方法还不够，关键是把工作坊开好。引导师是整个活动的节奏掌控者：他要不断提问「这个事件再往左一步是什么？」「这个规则谁定的？」同时还要保护参与者，避免争论变成人身攻击。

时间盒（Timebox）是引导师最趁手的工具。Big Picture 可以设置 90 分钟：前 20 分钟收集事件，30 分钟排时间线，20 分钟标热点，20 分钟暂停回顾。到点就停下，不要沉浸在细节里。Big Picture 结束并不代表模型完成，而是给下一轮 Design Level 留下待办清单：哪个上下文值得深入，哪个热点需要业务专家补充。

事件风暴鼓励多轮迭代。第一轮贴出骨架，散会后大家消化；第二轮补充命令、角色和规则；第三轮尝试圈聚合、画上下文。远程团队也不用担心，用在线白板代替墙面，用虚拟便签代替实体便签，照样能开。

美食节筹备不是一次会议就能定稿的：先出大纲，大家回去想一晚上，第二天再补细节。事件风暴也是如此，贴纸不是答案，对话和迭代才是。

AI 应用场景

Python 演示

from dataclasses import dataclass  @dataclassclass DomainEvent:    name: str    aggregate_id: str    position: int  @dataclassclass Command:    name: str  class EventStormingBoard:    def __init__(self, title):        self.title = title        self.event_list = []        self.command_list = []        self.policy_list = []     def add_event(self, name, aggregate_id):        event = DomainEvent(name, aggregate_id, len(self.event_list))        self.event_list.append(event)        return event     def add_command(self, name):        command = Command(name)        self.command_list.append(command)        return command     def add_policy(self, rule):        self.policy_list.append(rule)     def aggregate_map(self):        mapping = {}        for event in self.event_list:            mapping.setdefault(event.aggregate_id, []).append(event.name)        return mapping     def show_timeline(self):        for event in sorted(self.event_list, key=lambda e: e.position):            print(f"[event] {event.name} -> {event.aggregate_id}")        for command in self.command_list:            print(f"[command] {command.name}")        for policy in self.policy_list:            print(f"[policy] {policy}")  def main():    board = EventStormingBoard("Community Food Festival")    board.add_event("EnrollmentClosed", "Stall")    board.add_event("StallOpened", "Stall")    board.add_event("FoodSoldOut", "Stall")    board.add_event("TrashCleared", "Venue")    board.add_command("SubmitEnrollmentForm")    board.add_command("OpenStall")    board.add_command("NotifyRestock")    board.add_policy("Max three people per stall")    board.show_timeline()    for agg, evs in board.aggregate_map().items():        print(f"aggregate[{agg}]: {', '.join(evs)}")  if __name__ == "__main__":    main()

1. board.add_event("EnrollmentClosed", "Stall")像在工作坊中贴一张橙色便签，记录「报名截止」这个已经发生的事实。
2. board.show_timeline()把便签按加入顺序输出，模拟事件墙上的时间线。
3. board.aggregate_map()按 aggregate_id 把事件归组，模拟用线圈圈出聚合边界。
4. mapping.setdefault(event.aggregate_id, []).append(event.name)用聚合 ID 做分组键，把属于同一个聚合的事件收集到同一列表。

常见误区

面试题