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の既存の用語と食い違う用語を使ったら、すぐに指摘してください。「用語集では『cancellation』をXと定義していますが、Yを指しているようです。どちらでしょうか？」

曖昧な表現を明確にする

ユーザーが曖昧な用語や複数の意味に取れる用語を使ったら、正確で標準的な用語を提案してください。「『account』と言っていますが、CustomerとUserのどちらを指していますか？この2つは異なるものです。」

具体的なシナリオについて話し合う

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

コードと照らし合わせる

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

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

用語が確定したら、その場でCONTEXT.mdを更新してください。後回しにしてまとめてはいけません。確定した内容をすぐに記録します。CONTEXT-FORMAT.mdの形式を使用してください。

CONTEXT.mdには実装の詳細を一切含めないでください。CONTEXT.mdを仕様書、作業メモ、実装上の決定事項を記録する場所として扱ってはいけません。ここに記すのは用語集だけです。

ADRの提案は必要最小限にする

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

1. 覆すのが難しい：後から判断を変えるコストが大きい
2. 背景がなければ意外に思われる：将来の読者が「なぜこの方法にしたのか」と疑問に思う
3. 実際のトレードオフの結果である：現実的な選択肢が複数あり、具体的な理由に基づいてそのうちの1つを選んだ

どれか1つでも当てはまらなければ、ADRは作成しません。ADR-FORMAT.mdの形式を使用してください。