domain

name	domain
description	Use when helping define, review, refine, or normalize DDD ubiquitous language, domain terminology, bounded-context vocabulary, glossary entries, business concepts, domain models, or requirements wording. Guides the user to define terms by actor, purpose, context, and rules instead of treating words as context-free labels.

Domain Ubiquitous Language

ユビキタス言語を定義・レビュー・改善するときに使う。目的は「用語集を作ること」ではなく、利害関係者が同じ文脈で同じ意味を扱えるようにし、要求・モデル・実装の認識ズレを減らすこと。

基盤となる考え方

• 言語ゲーム: 言葉の意味は単独では決まらず、用法・文脈・ルールによって決まる。
• スキーマ理論: 人は自分の知識や経験の枠組みで相手の言葉を解釈しやすい。

このため、ユーザーの言葉を自分の文脈で即断しない。一般的な辞書定義や技術者側の既知概念に寄せる前に、相手の業務文脈で意味を確認する。

必ず確認する観点

用語ごとに、少なくとも次を確認する。

• アクター: その言葉を使う、またはその言葉で表されるシステム利用者・利害関係者は誰か。
• 目的: アクターは何を達成したいのか。なぜその概念が必要なのか。
• 文脈: どの業務・画面・操作・状態・タイミング・組織・制度の中で使われる言葉か。
• ルール: その文脈で成立する制約、判定条件、例外、状態遷移、権限、金額、期限、数量、法務・運用方針は何か。

進め方

1. 候補用語を抽出する ユーザーの要求、仕様、会話、既存コードから、曖昧・多義的・業務判断を含む言葉を拾う。例: ユーザー、顧客、注文、購入、キャンセル、類似、関連、完了、有効、権限、ロール。

2. 文脈境界を疑う 同じ単語でも文脈が違えば別の意味になり得る。営業、決済、配送、サポート、管理者、ゲーム、認証などで意味やルールが変わるなら、同じ定義にまとめない。境界付けられたコンテキストごとに分ける。

3. アクター・目的・文脈・ルールを質問する 定義が足りない場合は、用語の定義案を作る前に短く質問する。質問は相手の業務判断を引き出す形にする。

4. 用語を定義する 定義は「名前」「意味」「アクター」「目的」「文脈」「ルール」「含まないもの」「例」「未決事項」を含める。必要なら、同義語・禁止語・旧名称も明記する。

5. モデル・要件への影響を確認する 用語定義がエンティティ、値オブジェクト、集約、状態、API、DB項目、UI表示、テスト観点にどう影響するかを示す。言葉の整理だけで終わらせない。

質問テンプレート

曖昧な用語を見つけたら、必要なものだけ聞く。

• 「ここでいう <用語> は、誰から見た言葉ですか？」
• 「<用語> を扱うアクターは何を達成したいですか？」
• 「その言葉は、どの業務・画面・状態・タイミングで使われますか？」
• 「<用語> と判定する条件、逆に含めない条件は何ですか？」
• 「同じ <用語> が別部署・別画面・別プロセスで違う意味になる場面はありますか？」
• 「例を3つ、反例を3つ挙げると何ですか？」
• 「この定義が間違っていた場合、どんな業務事故や実装ミスが起きますか？」

定義フォーマット

ユーザーがユビキタス言語を定義したい場合は、次の形式で出す。

### <用語>

- 定義:
- アクター:
- 目的:
- 文脈:
- ルール:
- 含まないもの:
- 例:
- 反例:
- 関連語:
- 所属する境界付けられたコンテキスト:
- 実装・テストへの影響:
- 未決事項:

レビュー観点

既存のユビキタス言語や用語集をレビューするときは、次を指摘する。

• 文脈が書かれておらず、一般定義だけになっている。
• アクターと目的が不明で、誰のための概念か分からない。
• 同じ単語に複数の意味が混ざっている。
• 別概念なのに同じモデルや同じDB項目に押し込めている。
• ルール、例外、反例がなく、実装判断に使えない。
• 業務用語と技術用語が混ざり、利害関係者と会話できない。
• 「ユーザー」「管理者」「状態」「完了」「有効」などの便利すぎる言葉で曖昧さを隠している。

出力方針

• まず認識ズレのリスクが高い用語を優先する。
• 断定できない定義は仮説として明示する。
• 不足情報は「未決事項」に残し、次に聞くべき質問を添える。
• ユーザーのドメイン理解が必要な箇所は、実装前に確認する。
• DDDの用語を振り回さず、業務の言葉で説明する。