domain-glossary

ユビキタス言語用語集

このスキルは、進行中の会話をDDDスタイルのユビキタス言語ドキュメントにまとめます。ドメイン用語を抽出し、曖昧さを解消して標準名を提案し、作業ディレクトリにある DOMAIN_GLOSSARY.md に継続的に更新される用語集を書き込みます。

使用するタイミング

次の場合にこのスキルを使用します。

• ドメイン、機能、製品、システムについて話していて、共通の言葉を使いたいとき。
• 「ユビキタス言語」、「ドメインモデル」、「DDD」に言及したとき。
• 「アカウント」、「ユーザー」、「顧客」など、複数の意味を持つ用語に何度もつまずき、意味を明確に定めたいとき。

会話の進展に合わせてこのスキルを再実行し、用語集を最新の状態に保つことができます。

プロセス

1. 会話とコンテキストを確認する

   • 現在の会話と、添付されているドキュメントやPRDを読み、ドメインに関連する名詞、動詞、概念を探します。
   • この場でドメイン上の意味を持たない一般的な技術用語（配列、関数、エンドポイントなど）は無視します。

2. 言語上の問題を検出する

   次の点を特定して記録します。

   • 同じ単語が異なる概念に使われている（曖昧さ）。
   • 異なる単語が同じ概念に使われている（同義語）。
   • 用語が曖昧、多義的、または一貫性なく使われている。

3. 標準用語集を提案する

   • 概念ごとに標準用語を1つ選び、名称について明確な判断を示します。
   • 各用語には、それがどのように実装されているかではなく、何であるかを説明する簡潔な1文の定義を書きます。
   • この文脈では使わない用語を誰もが把握できるよう、「避ける別名」を列挙します。

4. 用語をセクションに分類する

   • 関連する用語を見出しの下にまとめます（例：「注文のライフサイクル」、「人物」、「請求」、「コンテンツモデル」）。
   • 各グループに、Term、Definition、Aliases to avoid の列を持つ独自のMarkdownテーブルを設けます。
   • すべての用語がひとつのまとまりに属する場合は、テーブルをひとつにまとめてもかまいません。無理に分類を作らないでください。

5. 関係性を説明する

   • 主要な用語がどのように関連するかを、平易な言葉で説明する「Relationships」セクションを追加します。
   • 用語名を太字にし、明らかな場合は簡単な多重度も記載します（例：「注文には複数の明細項目があります」）。

6. 会話例を書く

   • 開発者とドメインエキスパートによる、短い会話例（3～5往復）を追加します。
   • 標準用語を一貫して使用し、現実的なシナリオで用語同士の関係を示します。
   • 混同しやすい用語の境界を明確にするために、この会話例を活用します。

7. DOMAIN_GLOSSARY.md を作成または更新する

   • ファイルが存在しない場合は、上記の構成で作成します。
   • 既存のファイルがある場合は、まず読み込み、新たに得た理解を統合してファイルを直接更新します。

再実行

同じリポジトリまたは会話で再度呼び出された場合：

1. 既存の DOMAIN_GLOSSARY.md を読みます。
2. 前回の実行以降に導入された新しい用語を統合します。
3. 理解が明らかに進展した定義を更新します。
4. 変更した項目には「(updated)」、新しい項目には「(new)」を付けます。
5. 新たに確認した曖昧さを「Flagged ambiguities」に追加します。
6. 最新の用語と関係性を反映するよう、会話例を更新します。

出力形式

DOMAIN_GLOSSARY.md は、おおむね次のパターンに沿ってください（必要に応じて調整してください）。

# Ubiquitous Language

## <Domain cluster 1>

| 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 |

## <Domain cluster 2>

| 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 generated only once a **Shipment** is fulfilled."
> ...

## Flagged ambiguities

- "account" is being used to mean both **Customer** and **User**. Prefer **Customer** for the business entity and **User** for authentication.

（これらのプレースホルダーではなく、現在のドメインに実際に存在する用語を使ってください。）

動作とルール

1. 明確な判断を示してください。同じ概念に複数の用語がある場合は標準用語を1つ選び、それ以外は「避ける別名」に移します。
2. 定義は簡潔にしてください。手順（「何をするか」）ではなく、同一性（「何であるか」）に焦点を当てた1文にします。
3. ドメイン用語だけを含めてください。この文脈で特別な意味を持たない限り、一般的なインフラ関連の語彙は省きます。
4. 競合を明示してください。曖昧または多義的な用語は、明確な推奨事項とともに「Flagged ambiguities」に記載します。
5. 以降の会話でも用語集を使ってください。ファイルを作成または更新した後は、その後の会話で標準用語を使い続けます。