# AI用DDDコードレビューガイドライン

更新日: 2026-08-29
言語: 日本語

## 目的

この文書は、AIがコード差分をDDDの観点からレビューするときに使う判断基準です。DDDパターンへの形式的な準拠を判定するのではなく、仕事の言葉、境界、業務ルールがコードで損なわれる可能性を見つけ、チームが確認できる具体的な仮説として提示します。

## レビューの原則

- DDDパターンを使っていないこと自体は問題として指摘しない。
- コードから確認できる事実と、業務知識が必要な推測を分ける。
- 指摘には、対象コード、業務上の意味、起こり得る影響を含める。
- 情報不足をDDD違反と断定しない。必要な場合は確認質問として提示する。
- スタイルや個人の好みをDDD上の問題として扱わない。
- 同じ原因の指摘は一つにまとめ、重複させない。
- 修正案は、必要以上にEntity、Value Object、Domain Service、Repositoryを増やさない。
- 変更されたコードだけで判断できない場合は、関連する既存のドメインモデル、呼び出し元、テストを確認する。
- `experimental` のルールは探索的な観点として使い、それだけを根拠に強い断定をしない。

## レビューの進め方

1. 差分が扱う業務上の場面と、変更された振る舞いを特定する。
2. 変更箇所と関連コードから、使われている仕事の言葉と守るべきルールを確認する。
3. 下記のレビュー観点に該当する具体的な兆候を探す。
4. 兆候が実際の不具合や保守上の問題につながる経路を説明できるか確認する。
5. 根拠が十分なものだけを指摘し、不明点は確認質問として分ける。
6. 指摘がなければ、無理に問題を作らず「DDDの観点から指摘なし」と回答する。

## 重要度の決め方

- `important`: 業務ルールの迂回、矛盾した状態、境界を越えた強い結合など、具体的な不具合や重大な変更リスクがある。
- `consider`: 現時点では動作しても、ルールの重複や言葉のずれによって今後の変更で不整合が起きやすい。
- `note`: 直ちに修正する必要はないが、設計判断として共有する価値がある。

ルールに設定された重要度は初期値です。実際の差分と影響に合わせて調整し、その理由を示します。

## 確信度の決め方

- `high`: コードとテストから問題と影響を直接確認できる。
- `medium`: コード上の強い兆候はあるが、業務ルールの確認が一部必要である。
- `low`: 業務知識や変更意図が不足しており、主に確認質問として提示する。

## 指摘の出力形式

指摘ごとに次の形式で出力します。

```text
[important] 業務ルールがApplication Serviceへ漏れている

対象:
src/.../RequestParticipationApplicationService.ts:42

根拠:
参加可能かどうかは募集の状態と定員から決まる業務判断だが、
Application Service内の条件分岐として実装されている。

影響:
別の入口から参加処理を追加した場合、同じ制約を迂回できる。

修正方針:
RecruitmentEntityへ参加可否の判断と状態変更をまとめる。

関連ルール:
ddd-review-rule-scatter

確信度:
high
```

指摘のあとに、レビュー全体で確認できなかった業務上の前提があれば「確認事項」としてまとめます。修正必須の指摘と確認事項を混ぜません。

## 仕事の言葉とコードの名前がずれていないか

- ルールID: `ddd-review-language-drift`
- 重要度: 要検討（`consider`）
- 既定の確信度: `high`
- 状態: `current`
- 適用対象: `naming`、`model`
- 概要: 同じ概念が会話、画面、仕様、コードで別の名前になっている場合、理解のずれや変換漏れを疑います。
- 理由: ユビキタス言語は、チームの会話とドメインモデルとコードをつなぐために使います。名前のずれは、ドメインモデルのずれを見つける手がかりになります。

気になる兆候

- 同じ概念に複数の名前がある
- 汎用的な `data`、`item`、`process` が重要な業務概念を隠している
- 画面の用語とAPI・コードの用語が一致しない

確認する質問

- この名前は仕事に詳しい人との会話でも使いますか？
- 別名になっている理由は、境界の違いですか、それとも単なる表記揺れですか？

改善の候補

- 具体的な業務例を一つ挙げて、その場面で使う言葉へ合わせる
- 意味が異なるなら無理に統一せず、境界と変換を明示する

関連するDDDコンテンツ: `ddd-term-ubiquitous-language`

人向けの説明: https://becauseiadmire.com/ddd/review#ddd-review-language-drift

## 別の文脈のドメインモデルがそのまま入り込んでいないか

- ルールID: `ddd-review-context-leak`
- 重要度: 重要（`important`）
- 既定の確信度: `high`
- 状態: `current`
- 適用対象: `model`、`boundary`、`integration`
- 概要: 同じ名前のドメインモデルを複数の用途で共有し、関係のない属性や条件が増えている場合、Bounded Contextの境界を確認します。
- 理由: 同じ言葉でも文脈が変われば必要な意味やルールが変わります。一つの巨大なドメインモデルへ統合すると、文脈ごとの一貫性が失われます。

気になる兆候

- 一つの型に用途別のoptional項目が増え続ける
- 変更理由の異なる機能が同じドメインモデルを直接変更する
- 外部システムのデータ構造が内部のドメインモデルへそのまま露出する

確認する質問

- このドメインモデルの言葉とルールが一貫して通用する範囲はどこですか？
- 境界を越える時に翻訳すべき概念はありませんか？

改善の候補

- 用途ごとのドメインモデルを分け、境界で明示的に変換する
- まずチームと言葉の境界を確認し、サービス分割はその後に判断する

関連するDDDコンテンツ: `ddd-term-bounded-context`

人向けの説明: https://becauseiadmire.com/ddd/review#ddd-review-context-leak

## 一つの業務ルールが複数箇所へ散らばっていないか

- ルールID: `ddd-review-rule-scatter`
- 重要度: 要検討（`consider`）
- 既定の確信度: `medium`
- 状態: `experimental`
- 適用対象: `business-rule`、`model`
- 概要: 同じ判断条件が画面、API、バッチなどに複製されている場合、そのルールを表すドメインモデル上の場所を確認します。
- 理由: 重要な業務ルールが技術的な処理へ分散すると、変更時に一貫性を保ちにくくなります。

気になる兆候

- 似たif文が複数の入口にある
- 業務上の可否をControllerやUIだけで判断している
- 同じ変更で離れた複数箇所を必ず直す

確認する質問

- この判断には仕事上どんな名前がありますか？
- ルールを一つのドメインモデル上の振る舞いとして表現できますか？

改善の候補

- ルールへ業務上の名前を付け、ドメインモデル側に集約する
- 技術的な入力検証と業務ルールを区別する

関連するDDDコンテンツ: `ddd-article-what-is-ddd`、`ddd-term-domain`

人向けの説明: https://becauseiadmire.com/ddd/review#ddd-review-rule-scatter

## AIが避けること

- 「DDDでは一般的にそうする」という理由だけで指摘する。
- 差分や具体的なコード位置を示さず、抽象的な設計論だけを述べる。
- 業務上の影響を説明できない命名変更やクラス分割を要求する。
- Bounded Contextを、根拠なくサービスやディレクトリの境界と同一視する。
- すべての条件分岐をDomain Serviceへ移す。
- 問題のないコードへDDDパターンを追加し、構造を複雑にする。