领域驱动设计

概念介绍

领域驱动设计(Domain-driven Design, DDD)是一种软件设计方法。软件设计方法涵盖了:范式、模型、框架、方法论。主要活动包括建模、测试、工程、开发、部署、维护。

领域驱动设计中,主要有三个主要概念:

  • 战略:建模。领域划分、界限上下文、核心领域。
  • 战术:架构。工程结构、领域对象、领域服务、领域事件。
  • 战役:编码。设计原则、设计模式。

DDD 的战略、战术和战役设计相辅相成,战略提供系统的建模作为宏观指导,战术下面有N个战役


产品需求

产品诉求

以一个营销平台为例,涵盖:

  • 活动配置
  • 签到、奖励
  • 活动账户
  • 抽奖策略(责任链+规则树)
  • 库存扣减
  • 抽奖满N次后阶梯抽奖

营销抽奖场景

分析需求:

  1. 抽奖为免费抽奖次数+用户消耗个人积分抽奖
  2. 抽奖活动可给用户分配可抽奖次数,通过点击签到发放。

业务流程

产品经理提供的产品需求文档PRD,Product Requirements Document)通常应包含一个粗略的产品流程图供研发后期做具体的设计。产品经理会详细地介绍整个系统的功能流程需要对接的接口文档

抽奖流程


系统架构

如果首次承接的是一个新的系统,还需要对系统进行架构设计(单体/分布式、技术栈)。最好能提供相关的落地案例和DDD脚手架。

资料:


分布式架构

roadmap-ddd-stc-05.png (1732×922)


分布式技术

roadmap-ddd-stc-06.png (1782×1028)


战略设计

用例图

  • 用例图是以用户与系统交互最简洁的表示形式,展现了用户与其相关用例之间的关系。
  • 用例图也等同于用户故事(常用术语),提倡用日常或商务用语,简单表述功能代表客户的需求与方向,是搭建系统的蓝图根据产品需求文档进行绘制
roadmap-ddd-stc-07.png (1344×1126)

建模方法论 —— 事件风暴

事件风暴的核心概念是让领域开发者和领域专家一起讨论学习,专注挖掘领域事件,避免错失流程节点

建模会在宽阔的墙面以及墙面上的大张白纸上进行,便利贴会贴在白纸上。至少会需要5种不同颜色的便利贴


术语

  • 黄色 - 领域事件 Domain Event:在业务流程中发生的事件,都是完成时(下单完成、支付完成、发货完成)。
  • 蓝色 - 决策命令 Command引发领域事件的命令(申请下单)。
  • 紫色 - 业务流程 Business Process:决策命令和领域事件之间的流程(Service模块),过程比较复杂的话需要存在。
  • 角色 Actor:提出决策命令的人。
  • 黄色 - 领域对象 Entity、Aggregate:角色让领域对象通过决策命令,完成领域事件
  • 玫红色 - 外部系统 External System第三方服务提供者,例如货运公司、收款平台。
  • 绿色 - 只读模型 Read Model:读取数据的动作,没有写库操作。

1个用户通过1个策略命令,使用领域对象,通过业务流程,完成2个领域事件,调用1次外部接口个过程:

image-20250428164147482

步骤

  1. 寻找领域事件
  2. 为领域事件添加决策命令,并对复杂的流程提供业务流程
  3. 为决策命令添加领域对象
  4. 圈出领域后,划分领域边界
  5. 研发详细设计
    1. 实体对象:对每一个领域对象进行字段的详细设计,并划分上下文关系。提供类图。
    2. 流程设计:每一步调用的系统、接口、需要执行的动作。例如提供时序图。

工程实现

战略设计昨做完,就需要执行战术和战役了。也就是在工程中做编码实现。