# 战略设计

> DDD战略设计总览：从上帝视角规划系统，对领域进行分析、划分子域、确定限界上下文和上下文映射，回答'系统如何拆分'的顶层问题。

- Skill: `microwind/skill-83` (Agent Skill)
- Install (CLI): `npx skillmds@latest add microwind/skill-83`
- Raw SKILL.md: https://api.skillmd.com/api/skills/microwind/skill-83/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: microwind (https://skillmd.com/u/microwind)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/microwind/skill-83

---


# 战略设计 (Strategic Design)

## 概述

战略设计是 DDD 的"**上帝视角**"—— 对整个领域进行全局分析和规划，确定业务中的概念、规则和边界等**基础性问题**。

**核心特征**：

- **面向业务，不面向技术** ——关注业务本质、规则、流程、未来演进
- **产出的是边界，不是类图** ——界定领域 → 子域 → 限界上下文
- **决定微服务拆分、团队分工** ——限界上下文是康威定律的落地单元

**核心问题**：

```
1. 业务整体是什么？                    → 领域 (Domain)
2. 业务可以拆分成哪些独立的业务块？      → 子域 (Subdomain)
3. 哪些是核心价值？哪些是基础能力？      → 核心域 / 支撑域 / 通用域
4. 模型在哪些边界内保持一致？           → 限界上下文 (Bounded Context)
5. 这些边界之间如何协作？               → 上下文映射 (Context Mapping)
```

## 战略设计 vs [战术设计](../tactical-design/)

```
┌────────────────────────────────────────────────────────────────┐
│                      战略设计（Macro）                           │
│    决定"有哪些系统""怎么拆""谁负责哪块"                           │
│                                                                │
│   [领域] → [子域] → [限界上下文] → [上下文映射]                    │
│                         │                                      │
│                         ▼                                      │
│                    微服务边界 + 团队分工边界                       │
└────────────────────────────────────────────────────────────────┘
                         │
                         ▼
┌────────────────────────────────────────────────────────────────┐
│                      战术设计（Micro）                           │
│     在一个限界上下文内部"具体怎么建模""怎么写代码"                  │
│                                                                │
│   [实体] [值对象] [聚合] [工厂] [仓储] [领域服务] [领域事件]         │
└────────────────────────────────────────────────────────────────┘
```

| 维度 | 战略设计 | 战术设计 |
|------|---------|---------|
| 视角 | 整体 / 上帝视角 | 局部 / 工程视角 |
| 关注点 | 业务边界、分工 | 模型结构、代码组织 |
| 产出 | 子域图、上下文地图 | 类图、聚合、代码 |
| 参与者 | 架构师、CTO、业务专家 | 架构师、开发 |
| 决策影响 | 长期、跨团队 | 本地、可重构 |

## 战略设计的四大构件

### 1. [领域 (Domain)](../domain-partitioning/)

```
领域 = 组织所要做的整个事情，以及这个事情下所包含的一切内容。

特征：
  ▸ 范围概念（不是类、不是数据库）
  ▸ 面向业务（不面向技术）
  ▸ 包含业务规则、流程、人员、知识

例：
  RabbitTech 的 RabbitAdvisors → 知识付费领域
  蚂蚁金服                     → 金融科技领域
  高德                         → 地图与位置服务领域
```

### 2. [子域 (Subdomain)](../domain-partitioning/)

```
子域 = 从复杂领域中划分出的独立业务子领域。

分类（按业务价值）：
  ▸ 核心域 (Core)        决定竞争力，持续投入
  ▸ 支撑域 (Supporting)  必须但非差异化，适度投入
  ▸ 通用域 (Generic)     行业通用，可买 / 可外包
```

详见 [核心/支撑/通用域](../domain-types/)。

### 3. [限界上下文 (Bounded Context)](../bounded-context/)

```
限界上下文 = 业务边界的划分，在该边界内领域模型保持一致性。

关键判据：
  ▸ 一个限界上下文必须支持一个完整的业务流程
  ▸ 同一术语在不同上下文可以有不同含义（"订单"在销售 vs 物流）
  ▸ 每个限界上下文对应一个微服务（常见实践）

限界上下文 = 模型边界 = 团队边界 = 代码库 / 模块边界
```

### 4. [上下文映射 (Context Mapping)](../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 概念的关系

| 概念 | 关系 |
|------|------|
| [战术设计](../tactical-design/) | 战略定界，战术建模；二者缺一不可 |
| [领域划分](../domain-partitioning/) | 战略设计的第一步 |
| [核心/支撑/通用域](../domain-types/) | 战略设计的分类工具 |
| [限界上下文](../bounded-context/) | 战略设计最重要的构件 |
| [上下文映射](../context-mapping/) | 描述战略设计的关系图 |
| [通用语言](../ubiquitous-language/) | 在限界上下文内成立 |
| [领域建模](../domain-modeling/) | 建模是战略 + 战术的桥梁 |
| [微服务中的 DDD](../ddd-in-microservices/) | 战略设计直接指导微服务拆分 |

## 总结

**核心**：战略设计解决"系统如何拆""团队如何分"这些**顶层问题**。

**关键构件**：领域 → 子域（核心/支撑/通用）→ 限界上下文 → 上下文映射。

**精髓**：边界比模型更重要；先画对边界，后在边界内做战术设计。