领域驱动设计
概念介绍
领域驱动设计(Domain-driven Design, DDD)是一种软件设计方法。软件设计方法涵盖了:范式、模型、框架、方法论。主要活动包括建模、测试、工程、开发、部署、维护。
领域驱动设计中,主要有三个主要概念:
- 战略:建模。领域划分、界限上下文、核心领域。
- 战术:架构。工程结构、领域对象、领域服务、领域事件。
- 战役:编码。设计原则、设计模式。
DDD 的战略、战术和战役设计相辅相成,战略提供系统的建模作为宏观指导,战术下面有N个战役。
产品需求
产品诉求
以一个营销平台为例,涵盖:
- 活动配置
- 签到、奖励
- 活动账户
- 抽奖策略(责任链+规则树)
- 库存扣减
- 抽奖满N次后阶梯抽奖
- …
分析需求:
- 抽奖为免费抽奖次数+用户消耗个人积分抽奖
- 抽奖活动可给用户分配可抽奖次数,通过点击签到发放。
- …
业务流程
产品经理提供的产品需求文档(PRD,Product Requirements Document)通常应包含一个粗略的产品流程图,供研发后期做具体的设计。产品经理会详细地介绍整个系统的功能流程和需要对接的接口文档。
系统架构
如果首次承接的是一个新的系统,还需要对系统进行架构设计(单体/分布式、技术栈)。最好能提供相关的落地案例和DDD脚手架。
资料:
分布式架构
分布式技术
战略设计
用例图
- 用例图是以用户与系统交互最简洁的表示形式,展现了用户与其相关用例之间的关系。
- 用例图也等同于用户故事(常用术语),提倡用日常或商务用语,简单表述功能。代表客户的需求与方向,是搭建系统的蓝图,根据产品需求文档进行绘制。

建模方法论 —— 事件风暴
事件风暴的核心概念是让领域开发者和领域专家一起讨论学习,专注挖掘领域事件,避免错失流程节点。
建模会在宽阔的墙面以及墙面上的大张白纸上进行,便利贴会贴在白纸上。至少会需要5种不同颜色的便利贴。
术语
- 黄色 - 领域事件 Domain Event:在业务流程中发生的事件,都是完成时(下单完成、支付完成、发货完成)。
- 蓝色 - 决策命令 Command:引发领域事件的命令(申请下单)。
- 紫色 - 业务流程 Business Process:决策命令和领域事件之间的流程(Service模块),过程比较复杂的话需要存在。
- 角色 Actor:提出决策命令的人。
- 黄色 - 领域对象 Entity、Aggregate:角色让领域对象通过决策命令,完成领域事件。
- 玫红色 - 外部系统 External System:第三方服务提供者,例如货运公司、收款平台。
- 绿色 - 只读模型 Read Model:读取数据的动作,没有写库操作。
1个用户通过1个策略命令,使用领域对象,通过业务流程,完成2个领域事件,调用1次外部接口个过程:

步骤
- 寻找领域事件。
- 为领域事件添加决策命令,并对复杂的流程提供业务流程。
- 为决策命令添加领域对象。
- 圈出领域后,划分领域边界。
- 研发详细设计。
- 实体对象:对每一个领域对象进行字段的详细设计,并划分上下文关系。提供类图。
- 流程设计:每一步调用的系统、接口、需要执行的动作。例如提供时序图。
工程实现
战略设计昨做完,就需要执行战术和战役了。也就是在工程中做编码实现。