domain-modeling

ドメインモデリング

設計を進めながら、プロジェクトのドメインモデルを積極的に構築し、磨き上げます。これが積極的な取り組みです。用語に疑問を投げかけ、エッジケースのシナリオを考案し、用語集や決定事項が固まった時点で書き留めます。CONTEXT.md を読んで語彙を確認するだけでは、このスキルに該当しません。それはどのスキルでもできる、ひと手間の習慣にすぎません。このスキルは、モデルを利用するだけでなく、モデルを変更するときに使うものです。

ファイル構成

ほとんどのリポジトリでは、コンテキストは1つです。

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

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

/
├── CONTEXT-MAP.md
├── docs/
│   └── adr/                          ← decisões de sistema
├── src/
│   ├── ordering/
│   │   ├── CONTEXT.md
│   │   └── docs/adr/                 ← decisões específicas do contexto
│   └── billing/
│       ├── CONTEXT.md
│       └── docs/adr/

ファイルは必要になったときにだけ作成します。書き込む内容ができてから作成してください。CONTEXT.md が存在しない場合は、最初の用語が確定したときに作成します。docs/adr/ が存在しない場合は、最初の ADR が必要になったときに作成します。

セッション中

用語集と照らし合わせて確認する

ユーザーが CONTEXT.md にある既存の用語と矛盾する用語を使ったら、すぐに指摘します。「用語集では『cancellation』を X と定義していますが、ここでは Y の意味で使っているようです。どちらでしょうか？」

曖昧な表現を明確にする

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

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

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

コードと照合する

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

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

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

CONTEXT.md には、実装の詳細を一切含めないでください。CONTEXT.md を仕様書や下書き、実装上の決定事項を記録する場所として扱ってはいけません。用語集以外のものではありません。

ADR の提案は慎重に行う

次の3つの条件をすべて満たす場合に限り、ADR の作成を提案します。

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

3つのうち1つでも欠けていれば、ADR は作成しません。ADR-FORMAT.md の形式を使用してください。