domain-modeling

mattpocock/skills の skills/engineering/domain-modeling/SKILL.md（4ae2317）にある workflow-axa に同梱されています。MIT（LICENSE）。以下の上流テキストに変更はありません。矛盾する場合は、末尾の workflow-axa の調整が優先されます。

ドメインモデリング

設計を進めながら、プロジェクトのドメインモデルを積極的に構築し、磨き上げます。これは能動的な取り組みです。用語に異議を唱え、エッジケースのシナリオを考案し、用語集や決定事項がまとまった瞬間に書き留めます。（語彙を確認するために GLOSSARY.md を読むだけでは、このスキルに該当しません。それはどのスキルでもできる一行の習慣です。このスキルは、モデルを利用するだけでなく、変更するときのものです。）

ファイル構成

ほとんどのリポジトリには、単一のコンテキストがあります。

/
├── GLOSSARY.md
├── docs/
│   └── adr/
│       ├── 0001-event-sourced-orders.md
│       └── 0002-postgres-for-write-model.md
└── src/

ルートに GLOSSARY-MAP.md がある場合、そのリポジトリには複数のコンテキストがあります。このマップには、それぞれのコンテキストの場所が記載されています。

/
├── GLOSSARY-MAP.md
├── docs/
│   └── adr/                          ← system-wide decisions
├── src/
│   ├── ordering/
│   │   ├── GLOSSARY.md
│   │   └── docs/adr/                 ← context-specific decisions
│   └── billing/
│       ├── GLOSSARY.md
│       └── docs/adr/

ファイルは必要になったときに作成します。書く内容ができてから作成してください。GLOSSARY.md がない場合は、最初の用語が確定したときに作成します。docs/adr/ がない場合は、最初の ADR が必要になったときに作成します。

セッション中

用語集と照らし合わせる

ユーザーが GLOSSARY.md の既存の表現と矛盾する用語を使った場合は、すぐに指摘します。「用語集では『キャンセル』を X と定義していますが、今おっしゃっているのは Y のようです。どちらでしょうか？」

曖昧な表現を明確にする

ユーザーが曖昧な用語や複数の意味を持つ用語を使った場合は、正確で標準的な用語を提案します。「『アカウント』とおっしゃっていますが、Customer と User のどちらを指していますか？この2つは別のものです。」

具体的なシナリオを検討する

ドメイン間の関係について話し合う際は、具体的なシナリオで徹底的に検証します。エッジケースを探り、概念間の境界を明確にせざるを得ないシナリオを考案します。

コードと照合する

ユーザーが何かの仕組みを説明したら、コードと一致しているか確認します。矛盾が見つかった場合は指摘します。「コードでは Order 全体をキャンセルしていますが、先ほど部分キャンセルが可能だとおっしゃいました。どちらが正しいでしょうか？」

GLOSSARY.md をその場で更新する

用語が確定したら、その場で GLOSSARY.md を更新します。後でまとめて処理せず、決まり次第記録してください。GLOSSARY-FORMAT.md の形式を使用します。

GLOSSARY.md には実装の詳細を一切含めないでください。GLOSSARY.md を仕様書やメモ帳、実装上の決定事項を記録する場所として扱ってはいけません。これは用語集であり、それ以外のものではありません。

ADR の提案は慎重に行う

次の3つの条件をすべて満たす場合に限り、ADR の作成を提案します。

1. 変更を元に戻しにくい：後から考えを変える場合のコストが大きい
2. 背景情報がないと意外に感じる：将来の読者が「なぜこの方法にしたのだろう？」と疑問に思う
3. 実際のトレードオフの結果である：現実的な選択肢が複数あり、具体的な理由から一つを選んだ

3つのうち1つでも満たさない場合は、ADR を作成しません。ADR-FORMAT.md の形式を使用します。

---

workflow-axa の調整

• 発動条件：用語、オーナー、またはドメイン境界が不明確な場合、あるいは変更される場合です。用語集を読むだけでは発動しません。
• プロジェクトで確立されているファイル（CONTEXT.md、docs/adr/、または既存の用語集のパス）を使用し、並行するドキュメント体系を作成しないでください。提案する変更は、まずタスクの DECISIONS に記載します。新しいポリシードキュメントの作成には、引き続きユーザーの承認が必要です。
• 作業を妨げない用語に関する質問は、まとめて確認します。