战术建模（Tactical Modeling）

战术建模 = 在 BC 内部，把业务概念映射为代码模型——通过 Aggregate、Entity、Value Object、Repository、Factory、Domain Service、Domain Event 等模式，实现不变量与业务规则。

本 group 包含

文档	核心问题	V2 节点
Aggregate	一致性边界是什么？	B3 + B4
Aggregate 4 Rules	聚合的实战规则？	B6 权衡
Entity & Value Object	对象身份 vs 对象值？	B4 抽象
Factory & Invariants	如何保证创建时的不变量？	控制论 Ch 4 §4.6
Repository vs DAO	仓储与 DAO 的区别？	B4 抽象
Repository Factory	加载与创建如何协作？	B4 抽象
Domain Service Event	跨聚合逻辑如何处理？	B3 分解
Tell Don't Ask / Demeter	如何降低耦合？	B4 抽象

核心概念对位

战术建模 = 在 BC 内部落地业务
  1. 边界（Aggregate）       → V2 B3 分解
  2. 抽象（Entity / VO）    → V2 B4 抽象
  3. 不变量（Factory）       → 控制论 Ch 4 §4.6
  4. 持久化（Repository）   → V2 B4 抽象（隔离技术）
  5. 跨聚合（Domain Service）→ V2 B3 分解
  6. 协作（Domain Event）   → V2 B3 + B7
  7. 表达（TDA / Demeter）  → V2 B4 抽象

阅读顺序

entity-vo (基础抽象)
    ↓
aggregate (一致性边界)
    ↓
aggregate-rules-of-thumb (实战规则)
    ↓
factory-invariants (创建时的不变量)
    ↓
repository-vs-dao (持久化抽象)
    ↓
repository-factory (加载 + 创建)
    ↓
domain-service-event (跨聚合协作)
    ↓
tell-dont-ask-demeter (代码风格)

与其他 group 的关系

• 上游：02-strategic（BC 边界 → 聚合）
• 下游：03-cross-context（聚合事件 → Saga）

关键洞察

战术建模的核心不是"设计模式"——是"不变量保证"—— 谁负责保证业务规则永远成立？

答案是：聚合根。 聚合根是 BC 内业务不变量的责任中心——任何修改都必须经过它。 Repository / Factory / Domain Service 都是围绕聚合根的辅助机制。

相关链接

• L1 Strategic——战略层
• L1 Cross-Context——跨 BC 协作
• V2 B3 分解——聚合是分解的产物
• V2 B4 抽象——Entity / VO 是抽象的结果
• 源典 IDDD Ch 5-12——Vernon 原书精读