🎯 战术设计 vs 战略设计

在领域驱动设计（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 项目应从战略设计入手，逐步深入到战术建模，才能实现从架构到代码的一致性表达。