tactical-ddd

战术 DDD — 丰富的领域建模

工作流

首先确定用户的意图：

意图	要执行的阶段
“验证 / 审查 / 检查 / 这样对吗？”	仅执行阶段 1 + 2 → 报告发现的问题，并在重构前征求同意
“修复 / 重构 / 改进 / 清理”	执行阶段 1 + 2 + 3
“我应该如何设计 / 建模？”	直接加载 reference.md

阶段 1 — 检测

加载 detection.md，扫描目标代码中的贫血信号。给出严重程度评分，并列出受影响的类。

阶段 2 — 评估

针对每个受影响的类，确定合适的构件：

是否具有随时间跟踪的唯一标识？	是否具有约束多个对象的不变量？	→ 构件
是	—	实体
否	—	值对象
是（根）+ 子对象共享不变量	是	聚合
操作跨越多个聚合 / 不属于任何聚合	—	领域服务

优先使用值对象而非实体。优先使用小型聚合而非大型聚合。

如果意图是验证 / 审查：到此为止。使用下方的输出格式报告发现的问题。继续之前先询问：“您希望我应用这些修复吗？”

阶段 3 — 重构

加载 refactoring.md，按步骤进行修改。按以下顺序执行：

1. 将一连串 setter 替换为单个表达力清晰的方法
2. 将服务逻辑移入所属的聚合
3. 在每个方法开头添加业务守卫
4. 每次成功改变状态后发布领域事件
5. 将原始类型替换为值对象

对于深入的模式问题（边界设计、事件建模、服务与实体的取舍），加载 reference.md。

---

快速识别贫血信号（先扫描）

public setX() / public setY()        → behaviour should be encapsulated
service.doX(entity, ...)              → logic likely belongs in entity
entity.setA(); entity.setB(); ...     → setter chain = missing intent method
no domain methods beyond getters      → pure data bag

---

黄金法则

1. 行为与数据并存 — 对象同时拥有状态以及改变状态的操作
2. 统一语言 — 方法名应源自领域，而非 CRUD（使用 commitTo，而不是 setStatus）
3. 小型聚合 — 默认使用根 + 值对象；只有存在真实不变量时才添加子实体
4. 一个事务 = 一个聚合 — 跨聚合规则通过领域事件实现最终一致性
5. 通过 ID 引用 — 绝不持有对其他聚合的对象引用
6. 优先使用值对象 — 仅在个体身份至关重要时使用实体
7. 谨慎使用领域服务 — 服务过多 → 贫血模型
8. 保护不变量 — 聚合是最后一道防线；绝不信任调用方

---

输出格式

审查代码时，报告：

## Anemia Diagnosis: <ClassName>

Severity: [None | Mild | Moderate | Severe]

Issues:
- <description of problem>

Recommended refactoring:
- <specific move from refactoring.md>

重构时，为每个改动过的类展示修改前 / 修改后的差异。