首页
/ DDD实践指南:角色、命令与事件映射方法详解

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

2025-06-07 15:23:03作者:温艾琴Wonderful

引言

在领域驱动设计(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. 关注异常:特别关注高风险路径和异常情况

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

登录后查看全文
热门项目推荐