analyzing-domain-model

name	analyzing-domain-model
description	DDD の戦術的設計パターンに基づくドメインモデル設計を支援。エンティティ、値オブジェクト、集約、ドメインサービスの設計。「ドメインモデルを設計したい」「DDD で設計したい」「集約を定義したい」「エンティティと値オブジェクトを識別したい」「ユビキタス言語を整理したい」といった場面で発動する。ドメインモデルを先に設計することで、業務ロジックが実装コードに正しく反映される。

ドメインモデル設計

DDD（ドメイン駆動設計）の戦術的設計パターンに基づき、エンティティ・値オブジェクト・集約・ドメインサービスを設計する。

ドメインモデルの価値は、業務の専門家と開発者が同じ言葉（ユビキタス言語）で会話できるようになること。モデルとコードが一致することで、「仕様と実装の乖離」という根本的な問題を解消する。

参照ドキュメントとテンプレート

種類	パス	備考
ガイド	@docs/reference/ドメインモデル設計ガイド.md	ドメインモデル設計の進め方詳細
テンプレート	@docs/template/設計.md	編集禁止。コピーして使用する
入力	@docs/requirements/requirements_definition.md	要件定義
入力	@docs/requirements/business_usecase.md	ビジネスユースケース
入力	@docs/requirements/system_usecase.md	システムユースケース
入力	@docs/requirements/user_story.md	ユーザーストーリー
入力	@docs/design/architecture_backend.md	バックエンドアーキテクチャ
入力	@docs/design/architecture_frontend.md	フロントエンドアーキテクチャ
成果物	docs/design/domain-model.md	ドメインモデル設計

エンティティ定義

ライフサイクルを持ち、識別子で区別されるドメインオブジェクトを識別する。「同じ属性値でも別のものとして扱う必要がある」ものがエンティティ。

• ライフサイクルを持つドメインオブジェクトの識別: ユースケースの動詞（作成・更新・削除）の対象がエンティティ候補
• 識別子の設計: 自然キーかサロゲートキーかを決定する。ドメイン的に意味のある識別子があれば自然キーを優先せよ

値オブジェクト定義

不変で識別子を持たないドメインオブジェクトを識別する。「属性値が同じなら同じもの」として扱えるものが値オブジェクト。プリミティブ型の代わりに値オブジェクトを使うことで、バリデーションとドメイン知識をカプセル化する。

• 不変オブジェクトの識別: 金額、メールアドレス、住所などの業務概念を値オブジェクト化する
• バリデーションルールの定義: 生成時にバリデーションを行い、不正な状態の値オブジェクトが存在できないようにする

集約の設計

トランザクション整合性の境界を定義する。集約が大きすぎると競合が発生し、小さすぎると整合性が保てない。適切な境界の見極めが最も重要。

• 集約ルートの識別: 外部からのアクセスポイントとなるエンティティを決定する
• 集約境界の定義: トランザクション整合性が必要な範囲を最小限にせよ
• 不変条件の設計: 集約内で常に満たすべきビジネスルールを明確にする

ドメインサービス定義

エンティティにも値オブジェクトにも属さないビジネスロジックを識別する。ドメインサービスは動詞で命名し、ステートレスに保て。

ダイアグラム作成

PlantUML を使用してクラス図・オブジェクト図を作成する。図はコードと同様にバージョン管理し、設計の変更を追跡可能にせよ。

コンテキストの戦略的分類には Mermaid.js の Quadrant Chart を使用する。

• X 軸: 競合他社との差別化（低い差別化 → 高い差別化）
• Y 軸: 業務ロジックの複雑さ（低い複雑さ → 高い複雑さ）
• 象限（左上から時計回り）:
  • quadrant-2（左上）: 一般 — 複雑だが差別化が低い（業界共通ロジック）
  • quadrant-1（右上）: 中核 — 複雑かつ差別化が高い（Core Domain）
  • quadrant-4（右下）: 補完 — 差別化はあるが複雑さは低い（Supporting Subdomain）
  • quadrant-3（左下）: 一般または補完 — 複雑さも差別化も低い（Supporting/Generic Subdomain）

quadrantChart
    title 差別化の度合いと業務ロジックの複雑さによる業務領域の分類
    x-axis "低い差別化" --> "高い差別化"
    y-axis "低い複雑さ" --> "高い複雑さ"
    quadrant-1 "中核"
    quadrant-2 "一般"
    quadrant-3 "一般または補完"
    quadrant-4 "補完"
    "Aコンテキスト": [0.75, 0.82]
    "Bコンテキスト": [0.82, 0.68]
    "Cコンテキスト": [0.62, 0.60]
    "Dコンテキスト": [0.28, 0.42]
    "Eコンテキスト": [0.65, 0.28]
    "Fコンテキスト": [0.30, 0.65]
    "Gコンテキスト": [0.18, 0.22]

作成の進め方

1. 入力ドキュメント（要件定義、ユースケース、アーキテクチャ設計）を確認する
2. @docs/reference/ドメインモデル設計ガイド.md を読み込む
3. ユビキタス言語の用語集を作成し、エンティティ→値オブジェクト→集約→ドメインサービスの順に設計する
4. 境界付けられたコンテキストを Mermaid.js Quadrant Chart で戦略的に分類し、概要セクションに追加する
5. docs/design/domain-model.md として出力する

途中から再開する場合

既存の docs/design/domain-model.md がある場合は、まずその内容を確認する。不足しているドメインオブジェクトや集約境界の見直しが必要な部分のみを修正する。

Example:

ユーザー: 「エンティティは識別した。集約の境界を決めたい」
回答: 既存の domain-model.md のエンティティ一覧を確認し、
      トランザクション整合性が必要な範囲を分析して集約境界を定義する。
      集約ルートを決定し、不変条件を明記する。

注意事項

• 要件定義とアーキテクチャ設計が完了していることが前提。未完了でも進めて構わない
• ダイアグラムは必ず PlantUML で作成する
• ユビキタス言語を使用してドメインエキスパートと共通認識を持つ。コード上のクラス名・メソッド名もユビキタス言語に合わせよ
• タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）

関連スキル

• orchestrating-analysis — 分析フェーズ全体のワークフロー案内
• analyzing-architecture — 前段のアーキテクチャ設計
• analyzing-data-model — 並行して進めるデータモデル設計
• analyzing-usecases — 入力となるユースケース・ユーザーストーリー