microwind 战略设计 (Strategic Design)
概述
战略设计是 DDD 的"上帝视角"—— 对整个领域进行全局分析和规划，确定业务中的概念、规则和边界等基础性问题。
核心特征：
- 面向业务，不面向技术 ——关注业务本质、规则、流程、未来演进
- 产出的是边界，不是类图 ——界定领域 → 子域 → 限界上下文
- 决定微服务拆分、团队分工 ——限界上下文是康威定律的落地单元
核心问题：
1. 业务整体是什么？ → 领域 (Domain)
2. 业务可以拆分成哪些独立的业务块？ → 子域 (Subdomain)
3. 哪些是核心价值？哪些是基础能力？ → 核心域 / 支撑域 / 通用域
4. 模型在哪些边界内保持一致？ → 限界上下文 (Bounded Context)
5. 这些边界之间如何协作？ → 上下文映射 (Context Mapping)
战略设计 vs 战术设计
┌────────────────────────────────────────────────────────────────┐
│ 战略设计（Macro） │
│ 决定"有哪些系统""怎么拆""谁负责哪块" │
│ │
│ [领域] → [子域] → [限界上下文] → [上下文映射] │
│ │ │
│ ▼ │
│ 微服务边界 + 团队分工边界 │
└────────────────────────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────────────┐
│ 战术设计（Micro） │
│ 在一个限界上下文内部"具体怎么建模""怎么写代码" │
│ │
│ [实体] [值对象] [聚合] [工厂] [仓储] [领域服务] [领域事件] │
└────────────────────────────────────────────────────────────────┘
| 维度 | 战略设计 | 战术设计 |
|---|---|---|
| 视角 | 整体 / 上帝视角 | 局部 / 工程视角 |
| 关注点 | 业务边界、分工 | 模型结构、代码组织 |
| 产出 | 子域图、上下文地图 | 类图、聚合、代码 |
| 参与者 | 架构师、CTO、业务专家 | 架构师、开发 |
| 决策影响 | 长期、跨团队 | 本地、可重构 |
战略设计的四大构件
1. 领域 (Domain)
领域 = 组织所要做的整个事情，以及这个事情下所包含的一切内容。
特征：
▸ 范围概念（不是类、不是数据库）
▸ 面向业务（不面向技术）
▸ 包含业务规则、流程、人员、知识
例：
RabbitTech 的 RabbitAdvisors → 知识付费领域
蚂蚁金服 → 金融科技领域
高德 → 地图与位置服务领域
2. 子域 (Subdomain)
子域 = 从复杂领域中划分出的独立业务子领域。
分类（按业务价值）：
▸ 核心域 (Core) 决定竞争力，持续投入
▸ 支撑域 (Supporting) 必须但非差异化，适度投入
▸ 通用域 (Generic) 行业通用，可买 / 可外包
详见 核心/支撑/通用域。
3. 限界上下文 (Bounded Context)
限界上下文 = 业务边界的划分，在该边界内领域模型保持一致性。
关键判据：
▸ 一个限界上下文必须支持一个完整的业务流程
▸ 同一术语在不同上下文可以有不同含义（"订单"在销售 vs 物流）
▸ 每个限界上下文对应一个微服务（常见实践）
限界上下文 = 模型边界 = 团队边界 = 代码库 / 模块边界
4. 上下文映射 (Context Mapping)
上下文映射 = 描述限界上下文之间的关系和集成方式，
同时刻画团队间的协作关系与权力结构。
DDD 共识的 9 种模式：
▸ Partnership（合作关系）
▸ Shared Kernel（共享内核）
▸ Customer/Supplier（客户-供应商）
▸ Conformist（追随者）
▸ Anticorruption Layer（防腐层）
▸ Open Host Service（开放主机服务）
▸ Published Language（发布语言）
▸ Separate Ways（各行其道）
▸ Big Ball of Mud（大泥球——遗留区域显式标记）
战略设计的典型流程
以 RabbitAdvisors 为例，完整流程：
Step 1 定义领域
└─ "知识付费 / 付费咨询"
Step 2 识别子域
├─ 订阅域、订单域（核心）
├─ 专栏域、报价域、金融域（支撑）
└─ 读者域、作者域、认证域（通用）
Step 3 分类子域（按业务价值）
└─ 核心 / 支撑 / 通用
Step 4 划分限界上下文
├─ 专栏订阅上下文（订阅 + 订单 + 读者）
├─ 专栏信息上下文（专栏 + 报价 + 评论）
├─ 签约分佣上下文（签约 + 佣金 + 作者）
├─ 金融上下文（支付）
└─ 用户信息上下文（认证 + 用户）
Step 5 绘制上下文映射
└─ 上下文之间通过 RPC / MQ / 防腐层通信
Step 6 落地为微服务和团队分工
└─ 5 个微服务 + 5 个小组
战略设计常见误区
❌ 误区 1：直接按数据库表划分模块
→ 实质退化为 MVC，丢失 DDD 的业务边界思想
❌ 误区 2：子域 = 微服务
→ 一个限界上下文可以包含多个子域；子域粒度过细
❌ 误区 3：追求"标准答案"
→ 战略设计是演进的，随着业务理解加深会重构上下文
❌ 误区 4：不做战略设计直接做战术设计
→ 没有明确边界，聚合、仓储都会失焦
❌ 误区 5：战略设计一次到位
→ 业务会演进，上下文也会演进；应定期重新评估
战略设计的交付物
1. 领域愿景文档 (Domain Vision Statement)
└─ 描述领域本质、关键业务规则、未来方向
2. 子域清单与分类
└─ 核心 / 支撑 / 通用
3. 上下文地图 (Context Map)
└─ 所有限界上下文 + 它们之间的关系
4. 通用语言术语表
└─ 每个限界上下文内的关键词汇
5. 微服务拆分方案
└─ 基于限界上下文的物理系统划分
6. 团队分工方案
└─ 基于限界上下文的康威定律落地
与其他 DDD 概念的关系
| 概念 | 关系 |
|---|---|
| 战术设计 | 战略定界，战术建模；二者缺一不可 |
| 领域划分 | 战略设计的第一步 |
| 核心/支撑/通用域 | 战略设计的分类工具 |
| 限界上下文 | 战略设计最重要的构件 |
| 上下文映射 | 描述战略设计的关系图 |
| 通用语言 | 在限界上下文内成立 |
| 领域建模 | 建模是战略 + 战术的桥梁 |
| 微服务中的 DDD | 战略设计直接指导微服务拆分 |
总结
核心：战略设计解决"系统如何拆""团队如何分"这些顶层问题。
关键构件：领域 → 子域（核心/支撑/通用）→ 限界上下文 → 上下文映射。
精髓：边界比模型更重要；先画对边界，后在边界内做战术设计。