ddd-domain-designer

DDD ドメイン設計

イベントストーミングの結果から、コードにすぐ使えるドメインモデル、集約、境界づけられたコンテキストを作成するまでの、ドメイン設計の全ワークフローです。

ワークフロー

このスキルでは、ビジネスの理解からコードにすぐ使えるモデルの作成まで、ドメイン設計の完全なパイプラインを扱います。

Business Requirements → [Event Storming] → 6-Step Process → Code-Ready Domain Models

Step 1: プロダクトビジョン — FOR [ユーザー] WHO [ニーズ]…UNLIKE [代替案] テンプレート。成果物：ビジョンボード。 Step 2: シナリオ分析 — ユーザージャーニーを整理し、ドメインイベント（オレンジ）／コマンド（青）／役割（黄）を捉えます。成果物：イベントタイムライン。 Step 3: ドメインモデリング — エンティティ／値オブジェクトを抽出 → 集約にクラスタリング → 境界づけられたコンテキストに分割します。成果物：集約一覧。 Step 4: マイクロサービスへの分割 — 各 BC を独立してデプロイする価値を評価します。1 つの BC = 1 つの潜在的なマイクロサービスです。成果物：コンテキストマップ。 Step 5: 詳細設計 — 集約ルート、エンティティ、値オブジェクト、ドメインイベント（過去形で命名）、不変条件を決定します。 Step 6: 開発とテスト — 集約単位で開発とテストを構成し、集約ごとに Repository インターフェースを 1 つ設けます。

詳細は references/ddd-tactical.md を参照してください。

使用する場面

使用する場面：イベントストーミングの成果からドメインモデルを設計する場合、集約／境界づけられたコンテキストを特定する場合、DO／DTO／VO／PO をマッピングする場合、値オブジェクトの永続化戦略を選択する場合、ドメインイベントと不変条件を設計する場合。

対象外：イベントストーミングの入力がない場合 → ddd-event-storming | DDD の基本概念 → ddd-architecture-awesome | 既存モデルのレビュー → ddd-code-reviewer | API の生成 → ddd-api-designer | 単純な CRUD（ドメインモデリングを省略）

対応範囲

得意なこと：

• イベントストーミングの結果からドメインモデルを設計（集約、境界づけられたコンテキスト、エンティティ／値オブジェクト）
• 集約設計の 6 原則を適用：整合性境界、小さな集約、ID による参照
• 境界づけられたコンテキストの分割と 7 種類のコンテキストマッピングパターン
• ドメインオブジェクトからコードオブジェクトへのマッピング（DO／DTO／VO／PO）
• 値オブジェクトの永続化戦略の選択（Inline／JSON／Embeddable）
• ドメインイベントと公開戦略の設計、ドメイン不変条件の特定

必要な条件：イベントストーミングの出力または明確なビジネス要件があること、アーキテクチャパターンが選択されていること、ユビキタス言語（UL）が統一されていること、ドメインエキスパートがレビューできること。

対象外：イベントストーミングの結果がない場合 → ddd-event-storming | 基本概念のみが必要な場合 → ddd-architecture-awesome | 既存モデルのレビュー → ddd-code-reviewer | モデルから API を生成 → ddd-api-designer | 単純な CRUD → ドメインモデリングを省略

対象ユーザー

このスキルは、バックエンド開発者（DDD アーキテクチャの実装）、ソフトウェアアーキテクト（パターンの評価と選択）、テックリード（チームの実装のレビュー）、DDD 初学者（ドメイン駆動設計の基礎の学習）を対象としています。

適用ユーザー

ユーザータイプ	前提知識
バックエンド開発者	DDD の基本概念（エンティティ／値オブジェクト／集約）を理解している
アーキテクト	分散システムの経験があり、ドメイン駆動設計を理解している
テックリード	DDD の戦略的設計を理解している
DDD 初学者	先に ddd-architecture-awesome を読むことをお勧めします

イベントストーミング主導の 6 ステップワークフロー

詳細は references/ddd-tactical.md、references/clean-ddd-hexagonal-tactical.md を参照してください。

集約のルール／集約設計の 5 ステップと 6 原則

5 ステップ：(1) エンティティ／値オブジェクトを特定 → (2) 整合性境界ごとにグループ化 → (3) 集約ルートを選択 → (4) 不変条件を定義 → (5) ドメインエキスパートがレビュー

6 原則：

#	原則	説明	レビューのポイント
1	整合性境界内で真の不変条件をモデル化する	集約がビジネスルールをカプセル化します	不変条件が外部から破られる可能性はありますか？
2	小さな集約を設計する	大きな集約は並行処理のボトルネックを招きます	エンティティが 5 個を超えていますか？ N+1 の懸念はありますか？
3	一意な識別子で他の集約を参照する	集約間では ID のみを保持し、オブジェクト参照は保持しません	直接のオブジェクト参照がありませんか？
4	境界の外では結果整合性を使用する	1 つのトランザクションで変更する集約は 1 つだけです	集約をまたぐ処理はドメインイベントで非同期に扱います
5	アプリケーション層で集約間の呼び出しを実装する	ドメインサービスは集約をまたいで直接呼び出しません	アプリケーション層がオーケストレーションを担っていますか？
6	最適なのは自分たちに合った方法	原則から外れることもできますが、理由を記録する必要があります	ADR に決定理由を記録します

詳細は references/advanced-tactical-patterns.md、references/domain-invariants.md を参照してください。

境界づけられたコンテキストの分割

分割基準：言語の変化点、チームの組織境界（コンウェイの法則）、変更頻度の違い、独立したデプロイの必要性、ビジネス能力の領域（コア／支援／汎用）。

7 種類のマッピングパターン：Partnership（高結合） | Shared Kernel（高） | Customer-Supplier（中） | Conformist（中） | Anti-Corruption Layer（低） | Open Host Service（低） | Published Language（低）

詳細は references/bounded-context-mapping.md を参照してください。

ドメインオブジェクト → コードオブジェクトのマッピング

4 種類のオブジェクト：PO（永続化 → Infrastructure） | DO（ドメインオブジェクト → Domain、リッチモデル） | DTO（転送オブジェクト → Interface／App） | VO（ビューオブジェクト → Interface）

変換チェーン：VO ↔ DTO ↔ DO ↔ PO（Repository が DO ↔ PO を管理；Assembler が DO → DTO に変換；BFF が DTO → VO を組み立てます）

詳細は references/code-model-mapping.md を参照してください。

ddd-event-storming との関係

推奨ワークフロー：event-storming（探索） → domain-designer（詳細設計） → (アーキテクチャSkill)（実装）

注意点

1. 集約が大きすぎる（エンティティ 10 個以上）→ 小さな集約の原則を適用し、1～5 個を推奨します
2. 整合性境界がない（1 つのトランザクションで集約ルートを 2 つ変更）→ 1 つのトランザクションで変更する集約は 1 つだけにします
3. 値オブジェクトをエンティティとして扱う（Address に ID がある）→ 属性が等しければ VO とし、不変にします
4. 集約ルートの ID に自動採番 ID を使う → UUID または業務番号を使用します（ドメインイベント／分散環境での一意識別に必要です）
5. ドメインイベントの命名が不適切 → 過去形で命名します（"PayOrder" ではなく "OrderPaid"）
6. ドメイン層がフレームワークのアノテーションに依存する → Domain 層は純粋な POJO とし、フレームワークへの依存をゼロにします
7. 集約をまたいでオブジェクトを直接参照する → 集約 B の ID のみを保持します
8. 集約をまたぐトランザクション → 結果整合性とアウトボックスパターン（Outbox Pattern）を使用します
9. 集約ルートの振る舞いが Service に漏れる → ビジネスロジックは集約ルートのメソッドに集約し、Service はオーケストレーションのみを行います
10. ユビキタス言語（UL）を無視する → コードの用語をビジネス言語と一致させます

詳細は references/ddd-tactical.md を参照してください。

検証ガイド

自己チェックリスト：不変条件を文書化しているか？ | 集約ルートIDに業務識別子を使用しているか？ | 集約をまたぐID参照を使用しているか？ | 1つのトランザクションで変更する集約は1つか？ | 値オブジェクトは不変か？ | エンティティはリッチドメインモデルか？ | ドメインイベントは過去形か？ | 各イベントに発行者／コンシューマーがあるか？ | 値オブジェクトの永続化方針を決めているか？ | BCの境界は明確か？ | ユビキタス言語を確立しているか？ | 集約のサイズは妥当か（エンティティ5個以下）？

FAQ

• 集約にはエンティティがいくつ含まれますか？ 1～5個です。5個を超える場合は、分割を検討します。
• 集約ルートはVOにできますか？ できません。集約ルートはエンティティである必要があります（独立したライフサイクルとグローバルに一意なIDを持つため）。
• ドメインサービスとアプリケーションサービスの違いは何ですか？ ドメインサービス：ビジネスルール（割引の計算など）。アプリケーションサービス：技術的なオーケストレーション（注文作成後の通知など）。
• BCはマイクロサービスと同じですか？ 理想的には1つのマイクロサービスに対応しますが、チームやデプロイ頻度に応じて調整できます。BCは少なくともモジュールの境界です。
• エンティティとVOはどう区別しますか？ 独立したIDを持つものはエンティティです。不変で、属性の等価性に基づくものはVOです。どちらにも当てはまらない場合は、再モデリングします。
• 集約をまたぐクエリはどう実行しますか？ アプリケーション層でRepositoryのクエリを組み合わせるか、CQRSのクエリ側で読み取りモデル／マテリアライズドビューを作成します。
• 値オブジェクトは必ずクラスでカプセル化する必要がありますか？ 単純な値にはプリミティブ型を使用できます。検証や振る舞いがある場合は、クラスでのカプセル化を推奨します（Email、Moneyなど）。
• ドメインエキスパートがいない場合はどうすればよいですか？ 経験豊富な業務担当者やプロダクトマネージャーから、ドメインエキスパートの役割を担う人を探します。
• 同じエンティティを複数のBCに配置できますか？ できます。ただし、BCごとに意味や属性が異なります（たとえば「ユーザー」は権限BCでは「アカウント」、注文BCでは「購入者」です）。
• Outbox Patternとは何ですか？ ローカルトランザクション内でドメインイベントをEventOutboxテーブルに書き込み、バックグラウンドプロセスで読み取ってMQに発行することで、少なくとも1回の配信を保証するパターンです。

キーワード

DDD domain design, ドメインモデリング, aggregate design, 集約設計, bounded context, 限界づけられたコンテキスト, entity, value object, 値オブジェクト, domain event, ドメインイベント, event storming, aggregate root, 集約ルート, consistency boundary, 整合性境界, context mapping, コンテキストマッピング, Anti-Corruption Layer, 腐敗防止層, ubiquitous language, コードマッピング, DO DTO VO PO, ヘキサゴナルアーキテクチャ, ドメインサービス, 集約のアンチパターン, ドメイン不変条件, 永続化方針, 結果整合性, outbox pattern, CQRS, BC分割の意思決定ツリー

参考資料

ファイル	用途
references/clean-ddd-hexagonal-strategic.md	DDDの戦略的設計—限界づけられたコンテキスト、コンテキストマッピング、統合パターン
references/clean-ddd-hexagonal-tactical.md	DDDの戦術的設計—Entity／VO／Aggregate／Repository／Domain Event
references/ddd-tactical.md	戦術パターンの補足—集約内部の構築、エンティティ／値オブジェクトのコードテンプレート
references/code-model-mapping.md	コードモデルのディレクトリ構成、オブジェクトマッピング表、レイヤー戦略
references/advanced-tactical-patterns.md	高度な戦術パターン—Factory／Specification／Domain Service
references/domain-event-catalog.md	ドメインイベント設計ガイド—分類、データ構造、発行戦略
references/bounded-context-mapping.md	7種類のマッピングパターンの詳細—意思決定ツリー、Mermaidテンプレート、コード例
references/persistence-strategies.md	値オブジェクトの永続化方針—Inline／JSON／Embeddableの意思決定ツリー
references/domain-invariants.md	ドメイン不変条件の設計—分類、実装パターン、仕様パターン、文書テンプレート
references/guides/partme-13-code-model-1.md	コードモデル（前編）—DDDマイクロサービスのコードモデル設計
references/guides/partme-14-code-model-2.md	コードモデル（後編）—ドメインモデルとコードモデルの一貫性の確保

例

ファイル	ドメイン
examples/ecommerce-domain.md	ECプラットフォーム
examples/banking-domain.md	銀行システム
examples/insurance-domain.md	保険業務
examples/order-fulfillment-domain.md	注文履行
examples/healthcare-domain.md	医療・ヘルスケア
examples/payment-domain.md	決済システム
examples/logistic-domain.md	物流・輸送

セキュリティと安全性

このスキルは純粋なドキュメントです。ユーザーデータを収集せず、外部サービスやネットワークにアクセスせず、実行可能なスクリプトも含みません。