tracer-domain-modeling

ドメインモデリング

設計を進めながら、プロジェクトのドメインモデルを積極的に構築し、洗練させてください。これは能動的な取り組みです。用語に疑問を投げかけ、エッジケースのシナリオを考案し、用語や判断が固まったらすぐに書き留めます。語彙を確認するためにCONTEXT.mdを読むだけでは、このスキルに当たりません。それはどのスキルでもできる、一行で済む習慣です。このスキルは、モデルを利用するだけでなく、変更するときのものです。

ファイル構成

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

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

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

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

ファイルは必要になったときに作成してください。書き留める内容ができるまでは作成しません。CONTEXT.mdが存在しない場合は、最初の用語が確定した時点で作成してください。docs/adr/が存在しない場合は、最初のADRが必要になった時点で作成してください。

セッション中

用語集との食い違いを指摘する

ユーザーがCONTEXT.mdの既存の用語と食い違う用語を使ったら、すぐに指摘してください。「用語集では『キャンセル』をXと定義していますが、Yの意味で使っているようです。どちらでしょうか？」

曖昧な表現を明確にする

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

具体的なシナリオについて議論する

ドメインの関係性について議論するときは、具体的なシナリオで検証してください。エッジケースを探り、概念間の境界を明確にする必要があるシナリオを考案してください。

コードと照らし合わせる

ユーザーが何かの動作を説明したら、コードと一致しているか確認してください。矛盾が見つかったら指摘してください。「コードでは注文全体をキャンセルしていますが、先ほど一部キャンセルが可能だと言っていました。どちらが正しいでしょうか？」

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

用語が確定したら、その場でCONTEXT.mdを更新してください。後回しにせず、確定した時点で記録します。CONTEXT-FORMAT.mdの形式を使用してください。

CONTEXT.mdには、実装の詳細を一切含めないでください。CONTEXT.mdを仕様書、メモ帳、実装上の判断の保管場所として扱ってはいけません。これは用語集であり、それ以外のものではありません。

ADRの提案は慎重に行う

次の3つすべてに当てはまる場合に限り、ADRの作成を提案してください。

1. 変更が難しい — 後から考えを変えるコストが大きい
2. 背景がないと意外に感じる — 将来の読者が「なぜこの方法にしたのだろう？」と思う
3. 実際のトレードオフの結果である — 現実的な選択肢が複数あり、特定の理由からそのうちの1つを選んだ

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