0:00 0:00
記事
Claude Codeでドメイン設計とDDDの相談をするときの注意点
ドメイン駆動設計（DDD）の検討をClaude Codeと進めるときの注意点を整理します。ユビキタス言語の固定、境界づけられたコンテキストの切り出し、AIが陥りやすい抽象論の落とし穴、設計判断を人間が持つための進め方までを具体例とともにまとめた、ドメイン設計をAIと進めたい上級者向けの実務ガイドです。
Claude Codeにドメイン駆動設計（DDD）の相談をすると、それらしい用語を並べた一般論が返ってきがちです。本記事は、DDDの検討をAIと進めるときに「抽象論で終わらせない」ための注意点と、ユビキタス言語や境界づけられたコンテキストを具体的に詰める進め方を整理します。
結論：DDDの相談はAIに「決めさせず」具体例で詰める
ドメイン駆動設計（DDD）は、ソフトウェアの構造を「事業のドメイン（業務領域）」に合わせて設計する考え方です。Claude Codeは用語の説明や案出しは得意ですが、ドメインの正解を知っているのは事業を理解している人間です。
Anthropic公式のbest practicesは、設計のような領域でAIにインタビューさせ、要件を文書化してから実装する進め方を推奨しています。DDDの相談も同じで、要点は3つです。
- AIに決めさせない：境界やモデルの最終判断は人間が持つ
- 抽象論を許さない：必ず自分のドメインの具体例で答えさせる
- 用語を先に固定する：ユビキタス言語が曖昧なまま進めない
DDDは設計相談の一種なので、全体の進め方は「Claude Codeで大規模開発の設計相談をするときの進め方」が土台になります。本記事はDDD特有の注意点に絞ります。
まずユビキタス言語を固定する
DDDの出発点は「ユビキタス言語」、つまりドメインの用語を、コードと会話と設計で同じ意味に揃えることです。ここが曖昧なまま実装に進むと、同じ「注文」という言葉が画面・API・DBで別の意味になり、バグの温床になります。
Claude Codeにいきなりモデルを設計させる前に、用語集を作らせます。Plan Modeで実装させずに進めるのが安全です。
目的: ドメインの用語集（ユビキタス言語）の下書きを作る
背景: ECサイトの注文まわりを整理したい
依頼:
1. @src/ と @docs/ を読み、注文・カート・配送に関わる
用語を抽出する
2. 各用語について「コード上の名前」「実際に指しているもの」
「曖昧な点・表記ゆれ」を表にする
3. 用語の正しい定義はまだ決めない。事実の列挙だけ
禁止事項:
- 一般的なEC用語の教科書的な定義で埋めること
- 用語の意味を勝手に確定させること抽出された表を見ながら、各用語の定義は人間が確定させます。AIが作った用語集をそのまま採用しないことが重要です。
境界づけられたコンテキストを切り出す
「境界づけられたコンテキスト（bounded context）」は、1つのモデルが一貫した意味を持つ範囲のことです。たとえば「商品」は、カタログ文脈では説明や画像を持つ存在ですが、在庫文脈では数量だけを持つ存在になります。同じ「商品」でも文脈が違えばモデルが違う、という切り分けです。
Claude Codeに境界を提案させるときは、必ず判断材料も一緒に出させます。
依頼:
1. 用語集（@docs/glossary.md）をもとに、境界づけられた
コンテキストの候補を3案出す
2. 各案について次を書く
- どの用語がどのコンテキストに属するか
- コンテキスト間で意味が変わる用語（例：商品）
- コンテキストをまたぐ依存と、その方向
3. 1案に絞らない。トレードオフを表で比較する
禁止事項:
- 「在庫・注文・配送」のような教科書的な分割を
検討せず採用すること境界の最終決定は人間が行います。複数案のトレードオフを比べる進め方は、設計相談の基本どおりです。
AIが陥りやすい抽象論の落とし穴
DDDはもともと抽象度の高い概念が多く、AIは「エンティティ」「値オブジェクト」「集約」といった用語を、中身のないまま並べがちです。次のような兆候が出たら、抽象論に流れているサインです。
| 兆候 | 危ない理由 |
|---|---|
| 自分のドメインの固有名詞が出てこない | 教科書の例をなぞっているだけ |
| すべてを「集約」にしようとする | 境界が大きすぎてトランザクションが重くなる |
| 1エンティティ1リポジトリを機械的に作る | 集約単位を無視している |
| 例が「注文」「ユーザー」だけ | 自分の業務の難所を避けている |
対策はシンプルで、「この説明を、うちの『○○』という具体的なケースで書き直して」と必ず差し戻すことです。抽象的な正しさではなく、自分のドメインで成立するかで判断します。
集約とトランザクション境界を具体で詰める
DDDで実装に最も影響するのが「集約（aggregate）」の単位です。集約は、まとめて整合性を保つべきオブジェクトのかたまりで、そのままトランザクションの境界になりやすい部分です。
ここを抽象論で決めると、巨大な集約ができてロック競合や性能問題を招きます。Claude Codeには、具体的な操作シナリオで検証させます。
依頼:
注文集約の候補について、次のシナリオで問題が出ないか検証する
- 同じ注文に2人が同時に明細を追加する
- 注文確定と在庫引き当てが別トランザクションになる場合
- 注文に明細が1000件ついた場合の読み込みコスト
各シナリオで「整合性が壊れるか」「性能問題が出るか」を書く非同期や同時更新が絡む検証は、「Claude Codeでレースコンディションを疑うときの調査プロンプト」の考え方も役立ちます。
既存コードからドメインを抽出する場合
ゼロからではなく、既存の大規模コードからドメイン構造を整理したい場合もあります。そのときは、いきなり全体を読ませず「入口→外周→深掘り」の順で進めます。詳しい手順は「大きなコードベースをClaude Codeに理解させる手順」にまとめています。
既存コードからの抽出では、「現状こうなっている」と「こうあるべき」を必ず分けて書かせます。両者を混ぜると、現状把握なのか提案なのか分からないドキュメントになります。
設計判断を記録する
DDDの検討で決めた「なぜこの境界にしたか」「なぜこの集約単位にしたか」は、ADR（アーキテクチャ決定記録）として残します。決定理由と却下案を残しておくと、後からモデルを見直すときに判断の前提をたどれます。
CLAUDE.mdには、確定した用語の定義やコンテキストの一覧のうち「毎回必要な短い事実」だけを置きます。検討の経緯や長い議論はADRやdocs/に分け、CLAUDE.mdを膨らませないのが原則です。
チェックリスト
- ユビキタス言語の用語集を、AIに事実抽出させてから人間が定義した
- 境界づけられたコンテキストは複数案のトレードオフで比較した
- 説明を自分のドメインの具体例で書き直させた
- 集約単位を、同時更新・性能の具体シナリオで検証した
- 「現状」と「あるべき」を分けて書かせた
- 境界・集約の最終判断は人間が行った
- 決定理由と却下案をADRに記録した
-
CLAUDE.mdには短い確定事実だけを置いた
次に読むおすすめ記事：
- 「Claude Codeで大規模開発の設計相談をするときの進め方」：設計相談全体の6ステップとADR記録
- 「大きなコードベースをClaude Codeに理解させる手順」：既存コードからドメインを抽出する前提
- 「Claude Codeに『計画してから実装』させるプロンプト例」：Plan Modeで検討フェーズを回す依頼の型
