ddd-review

DDDレビュー

コードの変更差分・PR・指定ファイルを DDD 観点でレビューするワークフローを実行する。

位置づけ: 本スキルは差分中心の軽量なレビューワークフローである。コードベース全体の網羅的な分析が必要な場合は、専門エージェント（ddd-reviewer / anti-pattern-detector / architecture-checker / evolvability-assessor）へ委譲する。

ワークフロー

1. レビュー範囲の決定

引数と作業状態から対象を決める:

レビュー対象は何か？
├─ 引数でファイル・ディレクトリが指定されている → そのファイル群
├─ 引数でPR番号・ブランチが指定されている       → gh pr diff / git diff <branch>
├─ 引数なし・未コミットの変更がある             → git diff（staged + unstaged）
├─ 引数なし・作業ツリーがクリーン               → 直近コミット（git show HEAD）
└─ 「全体をレビュー」と明示された               → エージェントへ委譲（後述）

差分だけでは文脈が不足するため、変更されたクラスの全体と、その呼び出し元・呼び出し先を必ず読んでから判定する。

2. 観点別チェック

差分に対して以下の5観点を順に検証する。各観点の詳細な判断基準は対応するスキルにある。

観点A: ユビキタス言語（ubiquitous-language）

• 新しい名前（クラス・メソッド・変数）はドメイン用語と一致しているか
• 用語集（glossary）があるプロジェクトでは、用語集との整合が取れているか
• CRUD 語彙（create/update/set/get/data/info）でビジネス操作を命名していないか
• 同じ概念に複数の名前、別の概念に同じ名前を使っていないか

観点B: レイヤー責務（domain-classifier）

• 追加されたロジックは正しい層に配置されているか（判定ツリーを適用する）
• ドメイン層に ORM・フレームワーク・外部クライアントの import が増えていないか
• コントローラ/ハンドラがリポジトリを直接呼んでいないか
• ビジネスルールがユースケース層に書かれていないか

観点C: 戦術パターン（entity-design / value-object / domain-service / repository-design / exception-design）

• エンティティ: 公開セッター追加・貧血化の兆候はないか。状態変更はビジネスメソッド経由か
• Value Object: プリミティブ型のままのドメイン値はないか。不変性・自己検証は保たれているか
• ドメインサービス: エンティティに置けるロジックを吸い上げていないか（最後の手段の原則）
• リポジトリ: 集約ルート単位か。クエリの肥大化はないか
• 例外: ドメイン例外として表現すべきエラーを汎用例外で投げていないか

観点D: 集約と整合性（aggregate-design / domain-event）

• 1トランザクションで複数の集約を更新していないか
• 集約間の参照が ID ではなくオブジェクト参照になっていないか
• 不変条件の検証を迂回する経路が増えていないか
• ドメインイベントの命名は過去形でビジネス的に意味があるか

観点E: アンチパターンの兆候

差分に anti-pattern-detector の8パターン（Anemic Domain Model、Repository per Entity、Leaking Infrastructure、God Aggregate、Skipping Ports、CRUD Thinking、Premature CQRS、Cross-Aggregate Transaction）の兆候がないかを確認する。兆候があれば該当箇所のみ精査し、広がりが疑われる場合はエージェント起動を提案する。

3. エージェントへの委譲

以下の場合は差分レビューに留めず、専門エージェントを起動する:

状況	起動するエージェント
コードベース全体の DDD 準拠度を評価したい	ddd-reviewer
アンチパターンの全体スキャンが必要	anti-pattern-detector
レイヤー構造・依存方向の検証が必要	architecture-checker
変更容易性・テスタビリティの評価が必要	evolvability-assessor

差分レビューで重大な問題（Critical）を複数検出した場合も、影響範囲の特定のためにエージェントの起動を提案する。

出力フォーマット

所見（問題ごと）

[CRITICAL|WARNING|INFO] {file_path}:{line_number}
  観点: {A-Eのいずれか}
  問題: {何が問題か}
  原則: {違反しているDDD原則}
  修正案: {具体的な修正方法。可能なら修正前/修正後のコードを添える}

重大度の基準:

• CRITICAL: 不変条件の破壊、集約をまたぐトランザクション、インフラの漏れなど、放置するとドメインモデルの信頼性が崩れるもの
• WARNING: 貧血化の兆候、CRUD 命名、配置の誤りなど、蓄積すると設計が劣化するもの
• INFO: 改善提案、より DDD らしい表現の提示

サマリー

## DDDレビュー結果

対象: {差分の範囲}

| 観点 | 結果 | 所見数 |
|------|------|--------|
| A. ユビキタス言語 | ✅ / ⚠️ / ❌ | N |
| B. レイヤー責務 | ✅ / ⚠️ / ❌ | N |
| C. 戦術パターン | ✅ / ⚠️ / ❌ | N |
| D. 集約と整合性 | ✅ / ⚠️ / ❌ | N |
| E. アンチパターン | ✅ / ⚠️ / ❌ | N |

### 必ず修正（Critical）
### 修正を推奨（Warning）
### 良い変更（維持すべき点）
### 次のアクション
{修正に使える関連スキル（例: 貧血化 → ddd-refactoring）を案内する}

レビューの品質基準

• 証拠（ファイルパス・行番号・コード）なしに指摘しない
• 差分に含まれない既存コードの問題は、変更と関係する場合のみ言及する
• 意図的なトレードオフ（コメントや ADR で説明されているもの）は違反と区別する
• 問題の指摘には必ず修正案を添え、修正に使える関連スキルを案内する
• 良いプラクティスも明示的に評価する