关于 ddd-review
依据领域驱动设计反模式清单审查文件、差异或模块的技能，会按严重程度和位置报告问题，并给出修复方向。
主要功能
- 01检查六类 DDD 问题
- 02标注阻断、主要或次要严重度
- 03引用问题位置及相关模式
- 04提供修复方向
适用场景
- 01审查拉取请求中的 DDD 问题
- 02调查疑似领域模型退化
- 03加固匆忙编写的代码
- 04在团队入职时说明模型问题
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/ddd-review确认已加载。
详细介绍
一句话总结
使用 DDD 反模式清单检查目标文件、差异或模块，并报告违规项、严重程度、位置和修复方向。
何时使用此技能
- 以 DDD 为框架进行类似拉取请求的审查（“这符合 DDD 原则吗？”、“审查这个聚合”）。
- 用户怀疑存在模型腐化的特定模块。
- 赶工编写、现在需要加固的代码。
- 帮助队友熟悉领域模型——“我们当前的代码有什么问题？”
何时不使用此技能
- 用户想要编写新代码 → 转到
ddd-implement。 - 用户想要从头重新设计 → 转到
ddd-design。 - 用户已确定目标结构，只想知道如何实现 → 转到
ddd-refactor。
核心内容
对目标代码进行六项检查。对每个发现，报告严重程度（blocker / major / minor）、问题位置，以及说明修复方法的模式技能。
1. 是否使用通用语言？ 类名和方法名应采用业务领域中的名词和动词，而不是 CRUD 名称（createX、updateY）或技术术语（Manager、Helper）。读起来像数据库表的模型是一种异味。
2. 是否遵守聚合边界？ 聚合只能通过 ID 引用其他聚合，不能通过对象引用。class Order { val customer: Customer } 这样的字段几乎总是严重程度为 blocker 的问题。
3. 贫血模型检查。 行为放在哪里？如果行为全都位于 *Service 类中，而实体只有字段和 getter，那么这个实体就是贫血模型。应将行为下沉到实体／聚合根中。
4. 基本类型迷恋。 检查 String customerId、Long amount、String email。每一种都是遗漏的值对象。基本类型在方法签名中传递得越频繁，严重程度就越高。
5. 仓储泄漏。 领域代码不应导入 JPA、JDBC、HTTP 客户端或框架类型。如果领域层提到了 EntityManager、Predicate 或 ResultSet，就说明抽象已经泄漏。
6. 工厂还是构造函数。 如果构造函数接受九个参数或执行大量工作，就说明背后隐藏着一个工厂。反过来，如果 FooFactory 的唯一方法 create(...) 做的事构造函数也能做，那就是过度设计。
判断准则
- 报告问题，而非发表意见。每个问题都应指出行范围和模式技能。
- 严重程度：
blocker（模型有误，会误导其他代码）、major（确实存在异味，应尽快重构）、minor（风格或命名问题，可顺手修复）。 - 不要只给模式贴标签而不指出违规之处。“这是贫血模型”不算问题；“
Order实体有 14 个字段，却没有任何会修改这些字段的方法；所有状态变更都由OrderService.process()完成”才算。
反模式
- 对明显违反目录规范的代码敷衍认可（“看起来不错”）。
- 审查风格而非模型——括号的位置不属于 DDD 关注的范围。
- 引用模式却不提供代码依据。
- 把所有长文件都视为异味——仅仅长度较长不构成违规。
另请参阅
ddd-anti-patterns— 本技能所依据的目录。ddd-core中的每个模式技能 — 问题报告会引用相关技能。
参考资料
- Evans，Domain-Driven Design（2003），第 4 章（隔离领域）、第 5–6 章（构建块）、第 III 部分（促使我们深入洞察的异味）。