domain-modeling

ドメインモデリング

設計を進める中で、プロジェクトのドメインモデルを積極的に構築し、磨き上げてください。これは能動的な取り組みです。用語に異議を唱え、エッジケースのシナリオを考案し、用語集や決定事項が固まった時点で記録します。語彙を確認するために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. 実際のトレードオフの結果である：現実的な選択肢が複数あり、明確な理由からそのうちの1つを選んだ

いずれか1つでも当てはまらない場合は、ADRを作成しません。ADR-FORMAT.mdの形式を使用します。