战略建模三板斧：四色建模、用例分析、领域故事
战略设计 · 第 6/15 篇
上一篇：《微服务拆分原则：领域驱动而非数据驱动》 · 下一篇：《通用语言与事件风暴落地》
开头：战略设计到底要交付什么？
DDD 分战略设计与战术设计：前者在宏观上划分子域、限界上下文与上下文关系；后者用实体、聚合、仓储等工具细化模型。官方并未规定统一过程，但实践中战略阶段有几项「标准动作」反复出现——领域分解、领域对象建模、微服务映射、详细设计，以及三种常用的战略建模方法：四色建模、用例分析、领域故事讲述。
本篇在概述两阶段衔接的基础上，重点讲清三板斧的步骤与产出，便于在 workshop 或需求阶段快速对齐边界。
一、战略与战术：两阶段在做什么？
1.1 战略阶段
关注子域、限界上下文、上下文映射（上下游关系）。更偏软件架构视角：从宏观观察系统、决定「拆几块、怎么协作」。
标准动作 1：领域分解
- 需求调研、收集领域知识、用例梳理
- 引入限界上下文与上下文映射分解问题域
- 识别核心域与子域，维持模型完整性
- 架构上：分层隔离、六边形表达领域与技术边界、CQRS 分离读写等
标准动作 2：领域对象建模（战略视角）
梳理实体、值对象、聚合/聚合根、领域事件、仓储、工厂、领域服务与应用服务等要素——为战术阶段打底。
1.2 战术阶段
在限界上下文内部细化模型，并与代码结构映射。战略与战术需要领域专家与开发持续共创，而非一次性交接。
标准动作 3：微服务设计（HLD）
领域模型与代码分层映射；订单等场景常用流程图、时序图、状态机表达命令与状态流转。
标准动作 4：详细设计（LLD）
库表、ER、接口、OOD 对象关系等——在战略边界清晰后再下沉。
二、领域与子域：分治是核心
领域即「要解决的业务问题」的范围；DDD 通过不断细分降低理解与实现复杂度，细分结果称为子域。
子域划分策略（可组合）：
| 策略 | 说明 |
|---|---|
| 业务职能 | 按企业职能部门映射（康威定律） |
| 业务产品 | 按对外产品/产品线划分 |
| 业务环节 | 按核心流程阶段划分（最常用） |
| 业务概念 | 抓住一眼能识别的业务概念 |
示例：保险域可拆为承保、收付、再保、理赔；承保再拆投保、保全、批改等。
2.1 核心域、通用域、支撑域
| 类型 | 含义 | 资源投入 |
|---|---|---|
| 核心域 | 决定竞争力的子域 | 最高 |
| 通用域 | 多子域共用的通用能力 | 可采购/复用 |
| 支撑域 | 必需但非核心、非通用 | 适度 |
同一「电商」标签下，淘宝 C2C、天猫/京东 B2C、苏宁线下转型等，核心域划分会完全不同——须结合商业模式与战略，而非套模板。
三、限界上下文与上下文映射
限界上下文 = 限界（领域边界）+ 上下文（语义环境）。同一词在不同上下文可有不同含义；边界内术语无二义性。
价值：
- 自然语言有歧义 → 需边界消歧
- 同一事物在不同场景模型不同
- 分解模型以控制复杂性
- 上下文是分工单元，高内聚、低耦合
实现上，一个限界上下文常对应一个微服务（在无团队/技术异构等特殊因素时）。
电商示例上下文：商品、订单、用户、营销、仓储物流、支付、售后等——各有模型、聚合与团队边界。
上下文之间必须协作（下单 → 支付），需上下文映射描述关系，常见模式包括：
| 模式 | 要点 |
|---|---|
| 合作关系 | 两团队紧密联动，一荣俱荣 |
| 共享内核 | 共享小规模通用模型/代码 |
| 客户-供应商 | 上下游，供应商主导接口 |
| 跟随者 | 下游无法改造上游模型，只能顺应 |
| 防腐层（ACL） | 翻译外部模型，隔离污染（最防御） |
| 开放主机服务（OHS） | 定义稳定公开协议/REST 契约 |
| 发布语言（PL） | 共享一套交换格式 |
| 各行其道 / 大泥球 | 后者应极力避免 |
映射落地可选 REST、RPC、MQ 等。绘制映射时关注：双向依赖、循环依赖、过长依赖链——往往是边界切错的信号。
四、战略建模方法一：四色建模
源于 Peter Coad《Java Modeling In Color With UML》，用四种「原型」给对象分类：
| 颜色 | 原型 | 含义 |
|---|---|---|
| 粉红 | Moment-Interval | 业务关键时刻/核心单据（下单、支付凭证） |
| 黄 | Role | 参与者在某时刻扮演的角色 |
| 绿 | Party / Place / Thing | 人、组织、地点、物 |
| 蓝 | Description | 分类或描述性信息 |
Moment-Interval 最重要：记录不可变事实与责任可追溯——浏览、加购、下单、支付、发货等都要留下单据。
建模步骤概要：
- 列出业务关键时刻与核心单据
- 识别参与方、地点、物品（绿）
- 识别角色（黄）：顾客、收货人等
- 补充描述类信息（蓝）
- 以核心单据收敛领域，划分子域与限界上下文
识别限界上下文时，自治单元宜满足：最小完备、自我履行、稳定空间、独立进化。
五、战略建模方法二：用例分析
用例回答：什么参与者，对系统做什么，期望什么结果。避免「盲人摸象」——只摸局部不知整体。
5.1 用例图要素
- 参与者（Actor）：系统外的人或外部系统
- 用例（Use Case）：动宾短语，相对独立、由参与者启动、有可观测结果
- 关系：关联、包含（include）、扩展（extend）、泛化
用例特征：自然语言叙述、强调做什么（what）而非怎么做（how）、系统对参与者是黑盒。
5.2 用例文档（示例骨架）
| 字段 | 示例 |
|---|---|
| 用例名称 | 提交订单 |
| 参与者 | 会员 |
| 前置条件 | 已登录 |
| 基本事件流 | 提交 → 校验 → 查库存 → 计价 → 扣款 → 生成订单 |
| 扩展流 | 库存不足、余额不足等 |
| 业务规则 | 商品信息确认无误后才支付 |
5.3 从用例到模型的六步
- 找参与者
- 收集用例（动词+名词，从流程与需求提取）
- 从名词提取实体
- 从形容词/名词提取属性
- 从动词建立关联与领域服务
- 完善聚合，用用例与流程验证迭代
六、战略建模方法三：领域故事讲述
Domain Storytelling 用象形符号让领域专家「讲工作流」，名称直接来自领域语言，是通用语言的早期形态。
五个要素：
| 要素 | 含义 |
|---|---|
| Domain | 故事所属领域 |
| Actors | 用户、系统、仓储、银行等 |
| Work Objects | 传递或展示的业务对象（商品列表、订单、支付结果） |
| Activities | 参与者与工作对象之间的活动 |
| Annotations | 流程注释 |
商城购物故事线（简化）：浏览 → 加购 → 下单 → 支付（对接银行）→ 扣款成功 → 通知仓库 → 物流 → 签收。
故事讲完后，可按 Work Objects 划分子域与 BC，例如：商品浏览、选购支付、银行交互、发货仓储、配送——与限界上下文一一呼应。
七、统一语言在战略中的位置
通用语言（Ubiquitous Language）是战略设计的第一步产出：统一术语 + 行为描述，且必须限定在某个限界上下文内。四色建模的名词、用例的动宾、故事里的 Work Object，都是在锤炼这门语言。
下一篇会专门展开通用语言与事件风暴——把战略阶段的边界与术语，推进到可执行的协作建模工作坊。
本篇小结
| 方法 | 适合场景 | 核心产出 |
|---|---|---|
| 四色建模 | 单据驱动、追溯业务流程 | 关键时刻、角色、领域边界 |
| 用例分析 | 明确用户与系统功能 | 用例图、用例规约、实体线索 |
| 领域故事 | 与业务专家快速对齐流程 | 端到端故事、Work Objects |
三板斧不互斥，常组合使用：故事/用例定范围，四色收敛单据与上下文，再进入事件风暴与战术建模。战略设计的目标不是画图漂亮，而是让团队对「拆哪几块、块之间怎么说话」形成共识。