3. 识别业务模块：从业务需求出发、事件风暴工作坊、初步划分限界上下文
业务模块的识别是领域驱动设计的核心起点，它决定了后续代码模型、服务拆分和团队协作的边界。本章将围绕“从业务需求出发 → 事件风暴工作坊 → 初步划分限界上下文”这一主线，系统讲解如何将模糊的业务诉求转化为清晰的模块边界。
3.1 从业务需求出发：识别核心域与支撑域
在启动任何技术设计之前，必须首先理解业务的全景图。业务需求通常以用户故事、功能列表或产品愿景的形式呈现。我们需要从中提炼出三个关键层次：
| 层次 | 定义 | 示例（电商系统） |
|---|---|---|
| 核心域 | 系统最核心、最具竞争力的业务逻辑，是系统存在的根本原因。 | 订单处理、支付结算、库存扣减 |
| 支撑域 | 为核心域提供必要支持，但本身不构成核心竞争力。 | 用户管理、商品信息管理、物流对接 |
| 通用域 | 行业通用、可复用的能力，通常可引入现成解决方案。 | 短信通知、邮件发送、权限认证 |
实践建议：在项目初期，优先投入资源到核心域的建模与实现。支撑域和通用域可以适当简化或引入第三方服务，避免过早陷入非核心细节。
3.2 事件风暴工作坊：从事件中挖掘聚合与边界
事件风暴（Event Storming）是一种协作建模技术，通过“领域事件”作为主线，将业务专家、产品经理和开发团队聚集在一起，快速发现业务全貌。以下是标准工作坊的五个步骤：
- 定义领域事件：用橙色便签记录业务中发生的“已经完成”的事实，例如“订单已创建”、“支付已成功”。
- 识别命令：用蓝色便签记录触发事件的动作，例如“提交订单”、“确认支付”。
- 引入聚合：将相关的事件和命令分组，形成高内聚的聚合（Aggregate），例如“订单聚合”包含“创建订单”、“取消订单”、“订单已发货”等。
- 标记限界上下文：根据聚合之间的耦合度和业务语义，将聚合归入不同的限界上下文（Bounded Context）。
- 绘制上下文映射：用箭头和关系线描述上下文之间的协作方式（如合作关系、客户/供应商关系）。
关键产出物：事件风暴工作坊结束后，团队应得到一张包含领域事件、命令、聚合和限界上下文的完整全景图。这张图是后续代码模型和微服务拆分的基础。
3.3 初步划分限界上下文：从聚合到模块边界
限界上下文（Bounded Context）是 DDD 中最重要的战术模式之一。它定义了模型的应用边界，每个上下文内部拥有独立的领域模型、数据库和团队。划分限界上下文时，应遵循以下原则：
- 业务语义完整性：一个上下文内的聚合应围绕同一个业务概念（如“订单”、“支付”、“库存”）。
- 高内聚低耦合：上下文内部聚合之间频繁交互，上下文之间通过事件或 API 进行松耦合通信。
- 团队自治：每个上下文最好由一个团队独立负责，减少跨团队协调成本。
- 数据所有权：每个上下文拥有自己的数据存储，避免跨上下文直接访问数据库。
常见误区：不要将限界上下文等同于微服务。一个限界上下文可以拆分为多个微服务，但一个微服务不应跨越多个限界上下文。初期建议一个上下文对应一个服务，后续根据性能或团队规模再拆分。
3.4 实战案例：从事件风暴到限界上下文
假设我们正在设计一个在线教育平台。通过事件风暴工作坊，我们识别出以下关键领域事件：
| 领域事件 | 所属聚合 | 建议限界上下文 |
|---|---|---|
| 课程已创建 | 课程聚合 | 课程上下文 |
| 章节已发布 | 章节聚合 | 课程上下文 |
| 用户已报名 | 报名聚合 | 学习上下文 |
| 学习进度已更新 | 进度聚合 | 学习上下文 |
| 订单已支付 | 支付聚合 | 支付上下文 |
| 优惠券已发放 | 营销聚合 | 营销上下文 |
划分结果：在线教育平台初步划分为四个限界上下文：课程上下文（课程管理、章节管理）、学习上下文（报名、进度、测评）、支付上下文（订单、支付、退款）、营销上下文（优惠券、活动、推荐）。每个上下文独立演进，通过事件驱动协作。
3.5 本章小结
识别业务模块是 DDD 落地的第一步，也是最重要的一步。通过“业务需求分析 → 事件风暴工作坊 → 限界上下文划分”这一流程，团队能够快速建立对业务全景的共识，并形成清晰的模块边界。在 Go 语言项目中，这些边界将直接映射为 module 目录结构、package 划分和 interface 定义，为后续的代码实现奠定坚实基础。