# 🎯 战术设计 vs 战略设计

URL: https://caijiao.org/ddd/chapter1/tactical-vs-strategic
Source: docs/ddd/chapter1/tactical-vs-strategic.md
Description: 理解领域驱动设计中战术设计与战略设计的区别与联系，以及它们在系统架构中的角色。

在领域驱动设计（DDD）中，“战术设计”与“战略设计”是两个核心维度，它们分别关注不同层级的问题，并共同支撑起领域建模的整体实践。

## 🛠 战术设计（Tactical Design）

战术设计是 DDD 中最为人熟知的部分，专注于在**限界上下文内建模和实现领域逻辑**。

### 常见构建块包括：

- **实体（Entity）**：具有唯一标识、生命周期的业务对象。
- **值对象（Value Object）**：无身份、不变的轻量业务对象。
- **聚合（Aggregate）**与聚合根：业务一致性边界和事务管理的核心。
- **领域服务（Domain Service）**：不适合放在实体或值对象中的核心逻辑。
- **工厂（Factory）**：封装对象创建逻辑。
- **领域事件（Domain Event）**：描述领域中的重要状态变化，用于解耦流程与逻辑。

### 应用目标：

- 清晰表达业务模型
- 强化代码的可读性与可维护性
- 保持领域逻辑的高内聚、低耦合

## 🧭 战略设计（Strategic Design）

战略设计处理的是**系统的宏观建模与边界划分问题**，关注不同子系统（上下文）之间的协作与集成方式。

### 核心概念包括：

- **限界上下文（Bounded Context）**：统一语言的适用范围，是设计、开发、测试、部署的边界单位。
- **上下文映射（Context Map）**：定义多个上下文之间的关系，例如：
  - Shared Kernel（共享内核）
  - Customer/Supplier（客户/供应商）
  - Conformist（顺从者）
  - Anticorruption Layer（防腐层）等
- **子域（Subdomain）**：将业务领域划分为核心域、支撑域与通用域，为上下文提供战略依据。

### 应用目标：

- 划清团队责任与业务边界
- 构建可演进、模块化的架构
- 指导微服务或模块系统的拆分策略

## 🔁 二者的关系

| 对比维度 | 战术设计                   | 战略设计                                 |
| -------- | -------------------------- | ---------------------------------------- |
| 关注层级 | 领域内部建模               | 系统架构与上下文划分                     |
| 影响范围 | 单个限界上下文             | 多个限界上下文之间的关系                 |
| 输出成果 | 实体、值对象、聚合、服务等 | 限界上下文图、上下文关系模型、子域划分等 |
| 适用对象 | 开发人员（建模实现）       | 架构师、技术经理、领域专家、团队协作     |

两者密不可分：**战略设计确定上下文的边界，战术设计在每个上下文内实现高质量模型。**

## ✅ 实践建议

- 战术设计更贴近代码实现，是开发人员日常建模的重点；
- 战略设计指导系统宏观结构，适合在系统启动、重构、拆分阶段重点投入；
- DDD 项目应**从战略设计入手，逐步深入到战术建模**，才能实现从架构到代码的一致性表达。