ドメインモデリング
プロジェクトにおける「もの」の意味に関する、共有された簡潔な情報源を維持し、コード、ドキュメント、チケット、会話が同じものに対して同じ言葉を使用するようにします。
焦点: $ARGUMENTS（空の場合は、このセッションで議論中の内容をモデリングします）
暗黙の前提は絶対に禁止。 用語の意味はユーザーが決定します。コード、ドキュメント、または会話からあなたが推測した定義、正規名、同義語、関係性、カーディナリティ、または不変条件は、ユーザーが確認するまでは単なる仮定です。それらを ✅ 確認済み · ❓ 未確認 · ❌ 却下 として追跡し、確認済みのものだけをドメインドキュメントに事実として書き込みます。
モデルの保存場所
GLOSSARY.mdまたはdocs/domain.mdが既に存在する場合は、それを使用します（既存のファイルを優先し、両方を作成しないでください）。- それ以外の場合は、以下の構造を使用して
docs/domain.mdを作成します。
プロセス
- 読み取り: 現在のドメインドキュメントと、焦点となっている概念を実装するコード（型、スキーマ、DBモデル、APIコントラクト）を読み取ります。コードは実際のモデルの証拠であり、ドキュメントは意図されたモデルです。両者の間に乖離があれば注意してください。どちらも、ユーザーの意図を直接教えてくれるわけではありません。矛盾がある場合は、いずれかを選択するのではなく、ユーザーに質問して解決します。
- 用語候補の抽出: 会話、仕様書、またはチケットから用語の候補を抽出します。それぞれについて、新しい用語か、既存の用語か、既存の用語の同義語かを提案し、ユーザーに確認を求めます。見た目が似ている二つの単語が異なる概念である可能性があります。
- 曖昧性の解消: ユーザーに具体的で簡潔な質問をします。
- 「Workspace は Organisation と同じものですか？それとも、一つの組織が複数のワークスペースを持つことはできますか？」
- 「Order は Customer なしで存在できますか？注文について常に真でなければならないことは何ですか？」 概念ごとに一つの正規名をユーザーと合意します（あなたが推奨しても構いません）。却下された同義語は Avoid としてリストします。
- 境界の定義: 同一性（エンティティ vs 値オブジェクト）、所有権/集約ルート、カーディナリティ、ライフサイクル/状態、不変条件を定義します。プロジェクトに複数の境界付けられたコンテキストがある場合は、用語がどのコンテキストに属するかを明記します。これらは、役立つ場合はコードから提案しますが、それぞれをユーザーに確認します。
- ドキュメントの更新: 確認済みの項目のみをドキュメントに追加します。差分は最小限に抑え、セクション内はアルファベット順に並べ、エッセイは書きません。定義の意味が変わった場合は、コミット/PRでその旨を伝え、誤った用語を使用しているコードにフラグを立てます。未解決の項目がある状態でユーザーが停止したい場合は、それらを
## Open Questionsの下に ❓ マークを付けて追加し、用語集には決して入れません。 - 報告: 追加/変更した内容、発見したコードとモデルの乖離（
ファイル:行で示す）、およびまだ未解決の ❓ 項目を報告します。
ドキュメント構造（簡潔に保つ）
# ドメインモデル
## 用語集
| 用語 | 定義 | 避けるべき用語 |
|------|------------|-------|
| Order | 顧客が一つ以上のProductを購入するための確認済みリクエスト。 | purchase, cart |
## エンティティと集約
### Order（集約ルート）
- 同一性: `OrderId`
- 含む: OrderLine（1..n）
- 状態: draft → placed → paid → shipped | cancelled
- 不変条件: total ≥ 0; 支払い済みでなければ出荷不可
## リレーションシップ
- Customer 1 — n Order
## 境界付けられたコンテキスト（オプション）
- Billing: Invoice, Payment
ルール: 定義は可能な限り一文で記述します。他の用語集の用語を使用して定義します。実装の詳細は、それがドメインそのものである場合（例えば、顧客が目にするID形式など）を除き、含めないでください。