DCB と集約の共存 ── 「どちらか」ではなく「どちらも」

---

DCB は集約を殺すのか？

Sara Pellegrini の講演タイトル “Kill Aggregate!” はインパクトがあるが、DCB の提唱者たち自身が明確に述べている：

DCB は集約を否定するのではなく、その進化形である。

DCB と集約は相互に排他的ではなく、補完的だ。

---

使い分けの指針

集約が適しているケース

1. 不変条件が単一エンティティに閉じている
   → Order 集約内で合計金額を検証するなど
   → DCB を使うまでもない。集約がシンプルで十分。

2. パフォーマンスがクリティカル
   → DCB の条件付き書き込みはクエリを2回実行する（読み取り + 検証）
   → 高頻度の書き込みでは集約のストリームバージョンの方が軽量

3. チームが DDD の集約に慣れている
   → 学習コストとの兼ね合い
   → 既存コードベースとの一貫性

4. 状態遷移が集約内で完結する
   → 注文のステータス遷移（作成→確認→出荷→完了）など
   → 集約の内部状態として自然にモデリングできる

DCB が適しているケース

1. 不変条件が複数エンティティにまたがる
   → 講座の定員 + 受講者の上限（Ch.5 のケース1）
   → Saga を避けて即時一貫性が欲しい

2. グローバルな一意性制約
   → メールアドレスの重複防止
   → 集約の外にある制約

3. 集約の境界が頻繁に変わる（ドメインが進化中）
   → スタートアップの初期フェーズなど
   → タグとクエリの変更だけで境界を再定義できる

4. 不要なシリアライゼーションを避けたい
   → 同じ集約への書き込みが全て直列化される問題
   → 関連する操作だけが競合するようにしたい

---

共存パターン

パターン1: コアドメインは集約、クロスカットは DCB

集約で管理:
  Order 集約: 注文の作成・明細追加・ステータス管理
  → 不変条件が集約内で完結

DCB で管理:
  「同一ユーザーの未払い注文は3件まで」
  → User と Order にまたがる制約
  → タグ ["user:U1", "order:O1"] で横断クエリ

パターン2: 既存の集約を段階的に DCB に移行

Phase 1: 既存の集約ベースのイベントストアはそのまま
Phase 2: 新しいクロス集約の制約を DCB で追加
Phase 3: 不要になった Saga を DCB に置き換え
Phase 4: （必要なら）集約のストリーム構造をフラット化

パターン3: 境界づけられたコンテキスト内で DCB、コンテキスト間は非同期

コンテキスト内（DCB で即時一貫性）:
  講座管理コンテキスト内の「受講者登録」
  → 定員と受講上限を DCB で同時に保証

コンテキスト間（イベントで結果整合性）:
  講座管理 → 請求コンテキスト
  → StudentRegistered イベントをサブスクライブ
  → 請求レコードを作成
  → 従来通りの結果整合性で十分

---

DCB の制約と注意点

1. イベントストアの対応が必要

DCB は「タグによるフィルタリング」と「条件付き書き込み」をネイティブにサポートするイベントストアが必要。

DCB 対応のイベントストア:
  - EventSourcingDB（DCB の仕様策定者が開発）
  - UmaDB（DCB ネイティブ対応）
  - 自作実装（PostgreSQL + タグテーブルで構築可能）

従来のイベントストア（そのままでは DCB 不可）:
  - EventStoreDB（ストリームベース）
  - Axon Server（集約ベース）
  → アダプターレイヤーで対応可能な場合もある

2. クエリのパフォーマンス

集約ベース:
  ストリームの末尾から読むだけ → O(1) に近い

DCB ベース:
  タグ + タイプでフィルタして全件スキャン → インデックスが必要
  → 適切なインデックス設計がないと大量イベント時にパフォーマンス劣化

対策:
  - タグとイベントタイプの複合インデックス
  - スナップショット（Projection のキャッシュ）
  - タグの設計でクエリ範囲を限定（日付タグなど）

3. 学習コスト

集約は DDD の中核概念として広く知られ、書籍やコミュニティの蓄積が厚い。
DCB は 2023年に提唱された新しい概念で、実践事例やパターンの蓄積はまだ少ない。

→ チームへの導入は段階的に行うのが現実的
→ まずクロス集約の制約がある具体的な問題に DCB を適用し、効果を実感してから拡大

---

意思決定フローチャート

Q: 不変条件は単一の集約に閉じているか？
  YES → 集約で十分

  NO → Q: 結果整合性は許容できるか？
    YES → Saga / プロセスマネージャー

    NO → Q: イベントソーシングを使っているか？
      YES → DCB が最適な選択肢
      NO  → Q: イベントソーシングの導入は検討できるか？
        YES → DCB の導入を検討
        NO  → ドメインサービス + 分散ロック（従来型）

---

まとめ

観点	集約	DCB
成熟度	高い（2003年〜）	低い（2023年〜）
学習リソース	豊富	まだ少ない
単一エンティティの制約	◎ 最適	○ 可能だがオーバーキル
クロスエンティティの制約	△ Saga が必要	◎ 本領
パフォーマンス	○ 軽量	△ クエリコストあり
柔軟性	△ 境界の変更が困難	◎ タグとクエリで柔軟
イベントストアの要件	汎用的	専用対応が必要

＋ － ⟳ ✕