DDD实践指南：角色、命令与事件映射方法详解

引言

在领域驱动设计(DDD)实践中，理解业务场景中的角色、命令和事件关系至关重要。本文将以咖啡店业务场景为例，深入讲解如何通过事件风暴(Event Storming)方法进行领域建模，帮助开发者掌握DDD的核心建模技术。

业务事件识别

事件发现的基本原则

1. 使用通用语言：与领域专家沟通时，应采用业务人员能理解的术语，而非技术术语
2. 关注核心价值：只识别对业务有实质影响的事件
3. 明确触发与结果：每个事件都应明确其触发条件和产生的结果

咖啡店典型事件示例

在咖啡店场景中，我们可以识别出以下关键业务事件：

• 菜单展示
• 顾客点单（2杯美式咖啡）
• 支付完成
• 收据接收
• 座位占用
• 订单接收
• 咖啡制作完成
• 顾客离店
• 餐桌清理

这些事件应按时间顺序排列，形成完整的业务流程时间线。

命令与事件映射

命令的定义与特征

命令(Command)是触发事件的动作或意图，具有以下特点：

• 使用现在时态表示
• 通常由特定角色发起
• 可能导致一个或多个事件

在咖啡店场景中，典型的命令包括：

• 顾客点单
• 收银员处理支付
• 咖啡师开始制作
• 服务员清理餐桌

映射关系可视化

通过建立命令与事件的映射关系，可以清晰地看到业务流程中的因果关系。例如：

• "顾客点单"命令 → 触发"订单接收"事件
• "处理支付"命令 → 触发"支付完成"事件

角色识别与分析

角色的定义

角色(Role)是业务流程中的关键参与者，可以是：

• 人员（如顾客、员工）
• 系统（如支付系统、库存系统）

咖啡店核心角色

在咖啡店场景中，主要角色包括：

1. 顾客：发起点单、支付等行为
2. 收银员：处理订单和支付
3. 咖啡师：负责饮品制作
4. 服务员：处理餐桌服务

异常事件处理

风险事件识别

在业务流程中，需要考虑可能出现的异常情况，例如：

• 顾客未提供桌号就点单
• 咖啡师制作错误订单
• 支付失败
• 座位冲突

异常处理策略

对于识别出的风险事件，应采取相应措施：

1. 使用红色标签标记风险事件
2. 分析事件对客户体验的影响
3. 设计预防或补救方案

聚合设计

聚合的概念

聚合(Aggregate)是DDD中的核心概念，具有以下特征：

• 是一组相关命令和事件的逻辑集合
• 负责接受或拒绝命令
• 保证业务规则的一致性

聚合设计方法

1. 初期聚焦：先收集事件和命令，暂不急于命名聚合
2. 逐步识别：随着场景分析的深入，聚合边界会自然显现
3. 命名规范：
   • 使用名词（如"订单"）
   • 使用动名词（如"订单处理"）

限界上下文划分

上下文形成原则

当多个聚合表现出高度内聚性时，可将其划入同一限界上下文(Bounded Context)。判断标准包括：

• 命令A触发事件A
• 事件A产生视图A
• 视图A是执行命令B的条件
• 命令A和B应属于同一模块

上下文映射关系

根据Eric Evans的理论，限界上下文之间存在9种核心关系类型，包括：

• 合作关系
• 客户-供应商关系
• 遵奉者关系
• 防腐层
• 开放主机服务
• 发布语言
• 共享内核
• 分离方式
• 大泥球

理解这些关系有助于设计清晰的系统边界和集成方式。

实践建议

1. 可视化工具：使用便利贴等工具直观展示事件、命令和角色关系
2. 迭代优化：多次演练业务场景，逐步完善模型
3. 团队协作：鼓励领域专家和开发人员共同参与建模
4. 关注异常：特别关注高风险路径和异常情况

通过以上方法，团队可以建立起清晰的领域模型，为后续的系统设计和开发奠定坚实基础。