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>

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