第3章 领域设计：事件风暴与 27 个限界上下文

用"事件发生的时间线"还原系统该有的样子

3.1 本章导读

第2章给了你模块地图，但 domain 模块内部还有 27 个一级子包（限界上下文）。为什么是 27 个？边界画在哪？本章不罗列结论，而是带你重走一遍设计过程——用事件风暴（Event Storming）的方法，从业务事件出发推导领域边界。读完你会理解：DDD 不是"分包美学"，而是让代码结构映射业务结构。

3.2 事件风暴：从事件倒推设计

事件风暴的核心动作：先不管代码，只问"这个系统里会发生哪些事？"把每件事写成橙色便签（领域事件），再往前找触发它的命令（蓝色），往后找做出反应的读模型（绿色），中间是聚合（黄色）和策略（紫色）。

以"用户发一条消息"为例，沿着时间线问下去：

注意：我们全程没提任何类名，只描述了"发生什么"。事件风暴的价值就是延迟技术决策——先把业务流想清楚，再决定代码怎么写。

3.3 27 个限界上下文的全景

把所有事件便签摆在一起，按"哪些事件天然围绕同一个核心对象变化"聚类，就得到了限界上下文。本项目的 27 个可归为六个能力面：

3.4 深入解剖：task 域的五子域

不是所有上下文都同样复杂。以治理最关键的 task 域为例，它内部又按职责拆成了五个子域：

这个拆分让"权限规则变化"只影响 permission，"审批流程变化"只影响 approval——第11章会完整走通这条链路。

3.5 深入解剖：plugin 域的三边界

插件域按"生命周期阶段"拆成三条边界：

3.6 核心聚合：领域的锚点

每个限界上下文都有一个"锚点"——聚合根，它是外部访问该上下文的唯一入口：

聚合根的价值在于保护不变量。比如任务状态机，任何地方想把任务从 PENDING_APPROVAL 直接改成 RUNNING，都必须经过聚合根的方法——而聚合根会拒绝（执行入口对 PENDING_APPROVAL 直接抛异常兜底）。这就是 DDD 的防御性设计。

3.7 两条业务主线的交汇

回看整个领域设计，所有上下文最终服务于两条主线：

3.8 课程补充：从 6 组到 37 个能力点的逐模块地图

3.3 节的六能力面把 27 个一级包"收拢"了，但工程接手时真正要回答的问题往往是点状的："审批的评估逻辑在哪个包？""MCP 工具的名字前缀怎么生成？""ask_user_question 归哪个域管？"本节给出一张 37 个能力点（一级包 + 带点号子包）的逐模块地图，作为后续各章的"总索引"——每个能力点标注它所属章节，便于按需跳读。

3.8.1 Agent 执行核心（4 个能力点）

3.8.2 任务、目标与规划（7 个能力点）

3.8.3 LLM 与工具运行时（6 个能力点）

3.8.4 插件体系（4 个能力点）

3.8.5 治理与平台能力（16 个能力点）

3.9 小结与下一章预告