ユビキタス言語

現在の会話からドメイン用語を抽出・形式化し、一貫した用語集をローカルファイルに保存します。

プロセス

1. 会話をスキャン してドメイン関連の名詞、動詞、概念を抽出
2. 問題を特定:
   • 同じ単語が異なる概念に使用されている(曖昧性)
   • 同じ概念に異なる単語が使用されている(同義語)
   • 曖昧または過負荷な用語
3. 正規用語集を提案 — 見解を持った用語選択で
4. UBIQUITOUS_LANGUAGE.mdに書き込み — 作業ディレクトリに以下の形式で保存
5. サマリーを出力 — 会話内でインラインで表示

出力形式

以下の構造で UBIQUITOUS_LANGUAGE.md ファイルを作成します:

# ユビキタス言語

## 注文のライフサイクル

| 用語        | 定義                                              | 避けるべき別名      |
| ----------- | ------------------------------------------------------- | --------------------- |
| **注文**   | 顧客が1つ以上の商品を購入するためのリクエスト      | 購入、トランザクション |
| **請求書** | 配送後に顧客に送付される支払いリクエスト | 請求、支払いリクエスト |

## 人

| 用語         | 定義                                  | 避けるべき別名       |
| ------------ | ------------------------------------------- | ---------------------- |
| **顧客** | 注文を発注する個人または組織    | クライアント、買い手、アカウント |
| **ユーザー**     | システム内の認証アイデンティティ    | ログイン、アカウント         |

## 関係性

- **請求書** は正確に1つの **顧客** に属する
- **注文** は1つ以上の **請求書** を生成する

## 会話例

> **開発者:** 「**顧客** が **注文** を発注するとき、すぐに **請求書** を作成しますか?」
> **ドメインエキスパート:** 「いいえ — **請求書** は **フルフィルメント** が確認された場合にのみ生成されます。単一の **注文** が複数の **配送** に分かれる場合、複数の **請求書** を生成することができます。」
> **開発者:** 「では **配送** が発送前にキャンセルされた場合、その **請求書** は存在しないということですか?」
> **ドメインエキスパート:** 「その通りです。**請求書** のライフサイクルは **注文** ではなく **フルフィルメント** に関連付けられています。」

## 指摘された曖昧性

- 「アカウント」は **顧客** と **ユーザー** の両方を意味するために使用されていました — これらは異なる概念です: **顧客** は注文を発注し、**ユーザー** は **顧客** を表す場合もあればそうでない場合もある認証アイデンティティです。

ルール

• 見解を持つこと。 同じ概念に複数の単語が存在する場合、最適な単語を選択し、その他を避けるべき別名として列挙します。
• 競合を明示的に指摘する。 用語が会話で曖昧に使用されている場合、「指摘された曖昧性」セクションで明確な推奨とともに呼び出します。
• ドメインエキスパートに関連する用語のみを含める。 モジュールやクラスの名前はドメイン言語での意味がない限りスキップします。
• 定義は簡潔に。 最大1文。それが何であるかを定義し、何をするかではありません。
• 関係性を示す。 太字の用語名を使用し、明白な場合は基数を表現します。
• ドメイン用語のみを含める。 ドメイン固有の意味を持たない限り、汎用プログラミング概念(配列、関数、エンドポイント)はスキップします。
• 自然なクラスタが現れるときは複数のテーブルに用語をグループ化します(例:サブドメイン、ライフサイクル、アクターごと)。各グループは独自の見出しとテーブルを取得します。すべての用語が単一の統一されたドメインに属する場合、1つのテーブルで十分です — グループ化を無理に行わないでください。
• 会話例を作成する。 開発者とドメインエキスパート間の短い会話(3〜5交換)で、用語がどのように自然に相互作用するかを示します。会話は関連する概念間の境界を明確にし、用語が正確に使用される様子を示すべきです。

<example>

会話例

開発者: 「Docker なしで 同期サービス をテストするにはどうすればいいですか?」

ドメインエキスパート: 「Docker レイヤー の代わりに ファイルシステムレイヤー を提供してください。これは同じ サンドボックスサービス インターフェースを実装していますが、ローカルディレクトリを サンドボックス として使用します。」

開発者: 「では 同期イン は依然として バンドル を作成して解凍しますか?」

ドメインエキスパート: 「その通りです。同期サービス はどのレイヤーと通信しているかわかりません。exec と copyIn を呼び出すだけです — ファイルシステムレイヤー はそれらをローカルシェルコマンドとして実行するだけです。」

</example>

再実行

同じ会話で再度呼び出された場合:

1. 既存の UBIQUITOUS_LANGUAGE.md を読む
2. 後続の議論から新しい用語を組み込む
3. 理解が進化した場合、定義を更新する
4. 新しい曖昧性がないか再度指摘する
5. 会話例を書き直して新しい用語を組み込む