domain-modeling

ドメインモデリング

設計プロセスの中で、プロジェクトのドメインモデルを積極的に構築し、磨き上げます。これは active な取り組みです。用語に疑問を投げかけ、エッジケースのシナリオを考案し、概念が形になった時点で用語集と意思決定に記録します。

ファイル構成

ほとんどのリポジトリにはコンテキストが1つだけあります。

/
|- 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 に記載された既存の言葉と矛盾する場合は、すぐに指摘します。「用語集では『cancellation』をXと定義していますが、Yの意味で使っているようです。どちらでしょうか？」

曖昧な用語を明確にする

ユーザーが曖昧な用語や複数の意味を持つ用語を使った場合は、正確な標準用語を提案します。「『account』と言っていますが、CustomerとUserのどちらでしょうか？それぞれ別のものです。」

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

ドメインの関係について議論するときは、具体的なシナリオを使ってストレステストを行います。エッジケースを探り、概念間の境界を正確に定義せざるを得ないシナリオを考案します。

コードと照らし合わせる

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

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

用語が定義されたら、すぐに GLOSSARY.md を更新します。最後までまとめて保留せず、概念が生まれるたびに記録します。GLOSSARY-FORMAT.md の形式を使います。

GLOSSARY.md には実装の詳細を一切含めてはいけません。GLOSSARY.md を仕様書、メモ帳、実装上の意思決定の保管場所として使わないでください。これは用語集に限ります。

ADRの提案は慎重に行う

以下の3つすべてに当てはまる場合にのみ、ADRの作成を提案します。

1. 変更が難しい - 後から考えを変えるコストが大きい
2. 背景がないと意外に思われる - 将来の読者が「なぜこの方法にしたのか？」と疑問に思う
3. 実際のトレードオフの結果である - 代替案が実際に存在し、具体的な理由に基づいてそのうちの1つを選んでいる

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