DDD 戦術パターン / DDD Tactical Design Patterns

エンティティ、値オブジェクト、集約、リポジトリ、ドメインサービスの使い分け。

→ DDD 対応: ddd/03-aggregates/ (我々のシステムでの適用), ddd/06-value-objects.md

---

1. ビルディングブロック一覧

---

2. エンティティ vs 値オブジェクト

判断基準

製造業の例

---

3. 集約の設計ルール

ルール 1: 真の不変条件だけを集約内に

集約は「1 つのトランザクションで保証すべき整合性の範囲」。

✅ 見積 + 見積明細 → 合計金額の整合性 (同一トランザクション)
❌ 見積 + 受注 → 別々のタイミングで変更される (別集約)

ルール 2: 集約は小さく保つ

大きい集約 = ロック競合 = パフォーマンス問題。

❌ 受注集約 { 手配[], 製作指示[], 検収[], 売上, 日報[] }  ← 大きすぎ
✅ 受注集約 { 注文書 }
   手配集約 { → 受注への参照 }
   製作指示集約 { 日報[] }

ルール 3: 集約間は ID で参照

❌ purchaseOrder.salesOrder.customer.name  ← オブジェクト参照
✅ purchaseOrder.orderNumber → SalesOrder を別途取得  ← ID 参照

ルール 4: 集約外は結果整合性

集約間の整合性はドメインイベント + 結果整合性 (Eventual Consistency) で実現。

受注確定 → OrderAccepted イベント発行
  → 手配サービスが受信 → PurchaseOrder を自動生成
  → 製作指示サービスが受信 → ProductionInstruction を自動生成

---

4. リポジトリ

原則

• 集約ルートに対して 1 リポジトリ (子エンティティ用のリポジトリは作らない)
• コレクションのように振る舞う (add, find, remove)
• 永続化の詳細を隠蔽 (SQL, NoSQL はリポジトリの中に閉じ込める)

インターフェース例

interface SalesOrderRepository {
  findByOrderNumber(orderNumber: string): SalesOrder | null;
  findByCustomer(customerCode: string): SalesOrder[];
  save(order: SalesOrder): void;
}

アンチパターン

❌ QuotationLineRepository  ← 子エンティティ用リポジトリ
❌ repository.findAll()     ← 全件取得は集約の目的ではない
❌ repository.update(field)  ← 部分更新。集約全体を save する

---

5. ドメインサービス

いつ使うか

エンティティにも値オブジェクトにも自然に属さないドメインロジック。

注意点

• ドメインサービスに ロジックを集めすぎない (貧血ドメインモデルの兆候)
• まずエンティティ/値オブジェクトにロジックを置けないか検討
• ドメインサービスは ステートレス (状態を持たない)

---

6. バウンデッドコンテキスト統合パターン

我々のシステムでの適用

Sales CRM ──(Conformist)──→ Integration Contracts
Integration Contracts ──(ACL)──→ PMS

Sales は Contracts の仕様に準拠 (Conformist)
PMS は ACL で自ドメインモデルに変換して取り込む

---

7. よくある間違いと対策