ubiquitous-language

ユビキタス言語

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

プロセス

1. 会話をスキャンして、ドメインに関連する名詞、動詞、概念を探します
2. 問題を特定します：
   • 同じ単語が異なる概念に使われている（曖昧さ）
   • 異なる単語が同じ概念に使われている（同義語）
   • 曖昧な用語、または複数の意味で使われる用語
3. 標準用語集を提案し、用語の選択について明確な見解を示します
4. 下記の形式を使用して、作業ディレクトリ内の UBIQUITOUS_LANGUAGE.md に書き込みます
5. 概要を出力し、会話内にまとめます

出力形式

UBIQUITOUS_LANGUAGE.md ファイルを、次の構造で作成します：

# Ubiquitous Language

## Order lifecycle

| Term        | Definition                                              | Aliases to avoid      |
| ----------- | ------------------------------------------------------- | --------------------- |
| **Order**   | A customer's request to purchase one or more items      | Purchase, transaction |
| **Invoice** | A request for payment sent to a customer after delivery | Bill, payment request |

## People

| Term         | Definition                                  | Aliases to avoid       |
| ------------ | ------------------------------------------- | ---------------------- |
| **Customer** | A person or organization that places orders | Client, buyer, account |
| **User**     | An authentication identity in the system    | Login, account         |

## Relationships

- An **Invoice** belongs to exactly one **Customer**
- An **Order** produces one or more **Invoices**

## Example dialogue

> **Dev:** "When a **Customer** places an **Order**, do we create the **Invoice** immediately?"
> **Domain expert:** "No — an **Invoice** is only generated once a **Fulfillment** is confirmed. A single **Order** can produce multiple **Invoices** if items ship in separate **Shipments**."
> **Dev:** "So if a **Shipment** is cancelled before dispatch, no **Invoice** exists for it?"
> **Domain expert:** "Exactly. The **Invoice** lifecycle is tied to the **Fulfillment**, not the **Order**."

## Flagged ambiguities

- "account" was used to mean both **Customer** and **User** — these are distinct concepts: a **Customer** places orders, while a **User** is an authentication identity that may or may not represent a **Customer**.

ルール

• 明確な見解を示してください。 同じ概念に複数の用語がある場合は最適な用語を選び、その他の用語は避けるべき別名として記載します。
• 競合を明示してください。 会話内で用語が曖昧に使われている場合は、「曖昧さとして指摘された項目」セクションでその点を指摘し、明確な推奨事項を提示します。
• ドメインの専門家に関係する用語だけを含めてください。 モジュール名やクラス名がドメイン言語として意味を持たない限り、それらは省略します。
• 定義は簡潔にしてください。 最長でも一文とします。何であるかを定義し、何をするかは定義しません。
• 関係性を示してください。 用語名は太字にし、明らかな場合は多重度も示します。
• ドメイン用語だけを含めてください。 配列、関数、エンドポイントなどの一般的なプログラミング概念は、ドメイン固有の意味がない限り省略します。
• 用語は複数の表に分けてグループ化してください。自然なまとまりがある場合（サブドメイン、ライフサイクル、アクターなど）は、グループごとに見出しと表を設けます。すべての用語が一貫した単一のドメインに属する場合は、無理に分割せず表を一つにします。
• 会話の例を作成してください。 開発者とドメイン専門家の短いやりとり（3～5往復）を記述し、用語が自然に使われる様子を示します。会話では関連する概念の境界を明確にし、用語を正確に使ってください。

会話の例

開発者：「Docker を使わずに同期サービスをテストするにはどうすればよいですか？」

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

開発者：「つまり、sync-inは引き続きバンドルを作成して展開するのですね？」

ドメイン専門家：「そのとおりです。同期サービスは、どのレイヤーとやりとりしているかを認識しません。exec と copyIn を呼び出し、ファイルシステムレイヤーはそれらをローカルのシェルコマンドとして実行するだけです。」

再実行

同じ会話内で再度呼び出す場合：

1. 既存の UBIQUITOUS_LANGUAGE.md を読み込みます
2. その後の議論で出てきた新しい用語を統合します
3. 理解が進展した場合は、定義を更新します
4. 新たな曖昧さがあれば、改めて明示します
5. 新しい用語を取り入れるよう、会話の例を書き直します