ddd-code-reviewer

DDD コードレビュー

DDD コードレビュー＋アンチパターン検出＋5 つの観点による適合度スコアリング。コードが DDD のベストプラクティスに従っているかを検証し、構造化されたレビュー報告書を出力します。

ワークフロー

DDD コードレビューは次の 3 ステップで行います。

Step 1: 代码扫描 — 反模式检测清单逐项检查 + 源代码扫描
Step 2: 评分计算 — 5 维度逐项评分（分层/领域/命名/结构/测试）
Step 3: 报告输出 — 结构化审查报告（评分 + 反模式列表 + 修复建议）

レビューでは必ず 3 ステップすべてを実施し、完全な報告書を出力してください。問題を口頭で伝えるだけで文書を出力しないと、チームは改善状況を追跡できません。

使用するタイミング

トリガーワード（該当したら使用）

代码审查 DDD review 反模式检测 anti-pattern 贫血模型 充血模型检查 架构审查 分层合规 代码质量评分 layering compliance rich domain check review my DDD code

適用条件

条件	説明
プロジェクトに DDD の考え方が導入されている	DDD を採用していないプロジェクトにはレビューの基盤がありません
レビュー可能なソースコードがある	コードのパスまたはスニペットを提供する必要があります
アンチパターンの検出を期待している	単なる書式チェックではなく、ドメインモデルの健全性を重視します

適用しない場面

スキップする条件	代わりに使用
DDD を採用していないプロジェクト（純粋な CRUD）	標準的なコードレビュー（SonarQube / Checkstyle）
プロジェクトにまだ DDD を導入していない	ddd-architecture-awesome（まず DDD の概念を学習します）
最初の DDD コードを書き終えたばかり	まず書き終えてからレビューします
アーキテクチャの選定が必要	ddd-architecture-selector
アーキテクチャの健全性評価が必要	ddd-architecture-evaluator

対象者

このスキルは、バックエンド開発者（DDD アーキテクチャの実装）、ソフトウェアアーキテクト（パターンの評価と選定）、テックリード（チームの実装のレビュー）、および DDD 初心者（ドメイン駆動設計の基本を学習）を対象としています。

ルール

1. すべてのコードレビューに、5 つの観点によるスコアリング報告書を含める必要があります。
2. P0 アンチパターン（貧血モデル、レイヤー違反、集約をまたぐ直接参照）はマージをブロックします。
3. ドメイン層にはフレームワークへの依存が一切あってはなりません。ArchUnit で検証します。
4. レビュー報告書には、優先度順（P0→P1→P2）の修正案を含める必要があります。

アンチパターンチェックリスト

DDD のアンチパターン 12 種類を、P0（マージをブロック）／P1（次のバージョンまでに修正）／P2（継続的に改善）に分類します。

• P0 — 必ず修正：貧血モデル、ゴッドサービス、集約をまたぐ直接参照、ドメイン層のフレームワーク依存、循環依存、リポジトリが集約ルート以外を返す
• P1 — 修正すべき：コントローラーにビジネスロジックがある、アプリケーションサービスに SQL がある、値オブジェクトが可変
• P2 — 継続的に改善：集約が大きすぎる、ドメインイベントがない、集約をまたぐトランザクション

アンチパターンの完全なクイックリファレンスは references/checklist.md を参照してください。Java コード例と修正方法も記載されています。

レイヤー適合性マトリクス

レイヤー間の依存関係チェックルール（ArchUnit に基づく）：

    ┌─────────────────┬─────┬─────┬─────┬─────┐
    │ 层 / 可依赖     │ Infra│ Dom │ App │ Adap│
    ├─────────────────┼─────┼─────┼─────┼─────┤
    │ Infrastructure  │  ✓  │  ✗  │  ✗  │  ✗  │
    │ Domain          │  ✗  │  ✓  │  ✗  │  ✗  │
    │ Application     │  ✓  │  ✓  │  ✓  │  ✗  │
    │ Adapter         │  ✓  │  ✓  │  ✓  │  ✓  │
    └─────────────────┴─────┴─────┴─────┴─────┘

ドメイン層の依存ゼロルール（P0）：

• ✗ import org.springframework.stereotype.Service
• ✗ import javax.persistence.Entity
• ✗ import org.apache.ibatis.annotations.Mapper
• ✓ import java.util.Optional
• ✓ import java.math.BigDecimal

ArchUnit の完全な設定は references/archunit-config.md を参照してください。

リッチドメインモデルの検証

リッチモデルではエンティティに振る舞いをカプセル化します（合格）。貧血モデルではゲッター／セッターを通じて状態を公開します（不合格）。要点は、振る舞いをエンティティとサービスのどちらに持たせるかです。

コードの完全な例とリファクタリング前後の比較は examples/rich-model-refactoring.md を参照してください。実践的な例を 3 件掲載しています。

スコアリングシステム

5 つの観点によるスコアリング

観点	重み	チェック項目	満点
1. レイヤー適合性	30%	Domain の依存ゼロ、依存方向、App に SQL がない、Controller にビジネスロジックがない	30
2. ドメインモデルの品質	30%	リッチモデルの適用率、値オブジェクトの使用率、集約設計、ドメインイベント	30
3. 命名規則	15%	集約ルート＝ビジネス上の名称、Repository＝標準的な命名、イベント＝過去形	15
4. コード構造	15%	集約単位のパッケージ構成、クラスのサイズ、循環的複雑度	15
5. テストカバレッジ	10%	Domain 層のテストカバレッジ、集約ルートの振る舞いテスト、イベントの検証	10

合計スコア = Σ（各観点の得点 × 重み）

スコアの評価

範囲	評価	意味	対応
≥ 85	🟢 A	優れた DDD の実践	本番環境にリリース可能
70-84	🟡 B	基本的に適合しており、改善の余地あり	P1 の問題を修正
50-69	🟠 C	明らかなアンチパターンが存在	リファクタリングスプリントを計画
< 50	🔴 D	大規模なリファクタリングが必要	マージをブロックし、先に必ずリファクタリング

スコアリング基準と計算例は references/scoring-criteria.md、examples/scoring-example.md を参照してください。

レビュー報告書のテンプレート

レビューのたびに、次の内容を含む構造化された報告書を出力します。

# DDD Code Review Report

## Overall Score: 78/100 (🟡 B)

### 分层合规 (24/30)
| 检查项 | 结果 | 说明 |
|--------|:----:|------|
| Domain 零依赖 | ✅ | 无框架依赖 |
| App 层无 SQL | ❌ | OrderAppService L45 直接调用 Mapper |
| 依赖方向 | ✅ | 无反向依赖 |

### 领域模型质量 (22/30)
| 检查项 | 结果 | 说明 |
|--------|:----:|------|
| 充血模型 | ⚠️ | User 实体仍为贫血模型 |
| 值对象 | ⚠️ | Money/Email 已用，Phone 仍为 String |

### 反模式清单
| 严重级别 | 反模式 | 位置 | 修复建议 |
|:------:|--------|------|---------|
| P0 | 上帝 Service | OrderService.java:45-320 | 拆分为 OrderPricingService + OrderFulfillmentService |

### 改进建议（按优先级）
1. [P0] 将 OrderAppService 中的 SQL 移到 Repository 实现
2. [P1] 将 User 实体改为充血模型
3. [P2] 为关键业务操作补充领域事件

完全なテンプレートは references/report-template.md、例は examples/review-report-example.md を参照してください。

注意点

レビューでよくある落とし穴は references/gotchas.md を参照してください。

FAQ

質問	回答
1 回のレビューにどのくらいかかりますか？	小規模プロジェクト（集約 1～2 個）で約 30～60 分です。大規模プロジェクトはモジュールごとに分けてレビューします
スコアリングは主観的ですか？	各チェック項目には明確な検出基準があります（references/scoring-criteria.md を参照）。再現性があり、検証可能です
ArchUnit のチェックは自分で書く必要がありますか？	references/archunit-config.md の設定をそのまま使用できます。プロジェクトにコピーするだけです
アンチパターンが見つかったものの、修正できない場合はどうすればよいですか？	P0 を優先して修正してください。P1／P2 は技術的負債として記録し、返済計画を立てます
推奨されるレビュー頻度は？	コードレビューは PR のマージ前に行うことを推奨します。アーキテクチャレベルのレビューは四半期に 1 回を推奨します
DDD 以外のアーキテクチャのレビューとは何が違いますか？	DDD のレビューではドメインモデルの健全性に注目し、DDD 以外のレビューではコーディング規約／パフォーマンス／セキュリティに注目します

セキュリティと安全性

このスキルはドキュメントのみで構成されています。実行可能なスクリプトは含まれておらず、ユーザーデータの収集、外部サービスやネットワークへのアクセスも行いません。

Keywords

DDD 代码审查、反模式检测、贫血模型、充血模型、上帝 Service、分层合规、依赖方向、ArchUnit、领域事件、值对象不可变、聚合设计、5 维度评分、代码质量门禁

References

文件	用途
references/checklist.md	反模式速查表 — P0/P1/P2 分级 + 修复路径
references/scoring-criteria.md	5 维度评分细则 — 每项检查的权重和检测方法
references/archunit-config.md	ArchUnit 完整配置 — Maven/Gradle 依赖 + 全套检查规则
references/report-template.md	审查报告模板 — Markdown + 快速摘要格式
references/clean-ddd-hexagonal-layers.md	四层架构结构详解 — Domain/App/Infra/Presentation
references/clean-ddd-hexagonal-tactical.md	DDD 战术模式参考 — Entity/VO/Aggregate/Repository
references/clean-ddd-hexagonal-testing.md	测试模式 — 单元测试/集成测试/架构测试
references/partme-15-boundaries.md	微服务边界理论 — 逻辑边界/物理边界/代码边界
references/gotchas.md	审查常见陷阱 — 跨聚合引用、PO/DTO 混用等

Examples

文件	用途
examples/review-report-example.md	完整审查报告示例（62/100 🟠 C 级）
examples/scoring-example.md	评分计算全过程 + 修复 ROI 分析
examples/rich-model-refactoring.md	贫血→充血模型重构：3 个实战案例
examples/anti-pattern-fix-guide.md	反模式修复路径速查
examples/archunit-compliance-test.md	ArchUnit 合规测试 — P0/P1/P2 门禁实现

Next Steps

审查完成后，根据结果进入后续步骤：

• 架构级别评估 → ddd-architecture-evaluator
• 修复架构目录结构 → 对应架构 Skill（ddd-architecture-layered / ddd-architecture-hexagonal / ddd-architecture-cola 等）
• 提升测试覆盖率 → ddd-testing-strategist
• 输出架构文档 → ddd-architecture-doc