ドメインモデリング
設計中にプロジェクトのドメインモデルを能動的に構築・洗練します。これは能動的な訓練です。用語に挑戦し、エッジケースとなるシナリオを考案し、用語集と決定を結晶化した瞬間に書き留めます。（単に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/ ← システム全体の決定
├── src/
│ ├── ordering/
│ │ ├── GLOSSARY.md
│ │ └── docs/adr/ ← コンテキスト固有の決定
│ └── billing/
│ ├── GLOSSARY.md
│ └── docs/adr/
ファイルは遅延作成します：書き込む内容がある場合のみ作成します。GLOSSARY.mdが存在しない場合、最初の用語が確定したときに作成します。docs/adr/が存在しない場合、最初のADRが必要になったときに作成します。
セッション中
用語集に対する挑戦
ユーザーがGLOSSARY.mdの既存の言語と矛盾する用語を使用した場合、すぐに指摘します。「用語集では'キャンセル'をXと定義していますが、あなたはYを意味しているようです。どちらですか？」
曖昧な言語の明確化
ユーザーが曖昧または過負荷な用語を使用した場合、正確な正規用語を提案します。「'アカウント'と言っていますが、Customerのことですか、それともUserのことですか？それらは異なるものです。」
具体的なシナリオの議論
ドメインの関係性について議論している場合、具体的なシナリオでストレステストします。エッジケースを探り、概念間の境界についてユーザーに正確に考えさせるシナリオを考案します。
コードとの相互参照
ユーザーが何かの動作を述べた場合、コードが一致しているか確認します。矛盾を見つけたら、表面化します：「コードは注文全体をキャンセルしていますが、先ほど部分キャンセルが可能だと言いました。どちらが正しいですか？」
GLOSSARY.mdのインライン更新
用語が確定したら、その場でGLOSSARY.mdを更新します。一括更新はせず、発生したときに記録します。GLOSSARY-FORMAT.mdの形式を使用します。
GLOSSARY.mdは実装の詳細を完全に排除します。GLOSSARY.mdを仕様、スクラッチパッド、または実装上の決定の保管場所として扱わないでください。それは用語集であり、それ以外ではありません。
ADRの控えめな提供
以下の3つすべてが真の場合にのみ、ADRの作成を提案します：
- 変更が困難：後で考えを変えるコストが有意義である
- 文脈なしでは驚く：将来の読者が「なぜこの方法でやったのか？」と疑問に思う
- 真のトレードオフの結果：真の代替案が存在し、特定の理由で1つを選んだ
上記のいずれかが欠けている場合、ADRはスキップします。ADR-FORMAT.mdの形式を使用します。