イベント駆動アーキテクチャ / Event-Driven Architecture

CQRS、イベントソーシング、Saga パターン。 集約間の結果整合性とシステム間連携の基盤。

→ DDD 対応: ddd/04-domain-events.md, ddd/02-context-map.md (統合パターン)

---

1. ドメインイベント

定義

「ドメインで何かが起きた」ことを表す不変のオブジェクト

コマンド vs イベント

---

2. イベントストーミング (Event Storming)

目的

ドメインエキスパートと開発者が協働でドメインモデルを発見する手法。

プロセス

1. ドメインイベントを付箋で貼り出す (オレンジ)
   例: 「見積が承認された」「受注が登録された」

2. コマンドを追加 (青)
   例: 「見積を承認する」→ 「見積が承認された」

3. 集約を特定 (黄)
   例: コマンドとイベントをグルーピング → 「見積集約」

4. バウンデッドコンテキストを発見
   例: イベントの流れの断絶点 = コンテキスト境界

付箋の色

---

3. CQRS (Command Query Responsibility Segregation)

原則

書き込み (Command) と読み取り (Query) を分離する

┌─ Command Side ─┐     ┌─ Query Side ─┐
│ CreateOrder     │     │ OrderList    │
│ → Domain Model  │────→│ → Read Model  │
│ → Write DB     │ イベント │ → Read DB    │
└────────────────┘     └──────────────┘

いつ使うか

我々のシステムでの適用

CostReport = CQRS の Read Model

Command Side: 受入登録, 日報登録, 検収登録 (各集約が独立に処理)
    ↓ ドメインイベント
Query Side: CostReport (材料費+労務費+検収額を非同期に集計)

---

4. イベントソーシング (Event Sourcing)

原則

状態を直接保存するのではなく、イベントの列として保存する

従来: orders テーブルの status = 'completed' を UPDATE
ES:  events テーブルに OrderAccepted, WorkStarted, WorkCompleted を INSERT
     → 現在の状態はイベントを再生 (replay) して導出

メリットとデメリット

製造業での適用判断

推奨: フル ES ではなく、イベントの記録 + 状態テーブル のハイブリッド。

---

5. Saga パターン

問題

複数の集約/サービスにまたがるトランザクション。 分散トランザクション (2PC) は複雑で脆い。

解決: Saga

長期実行トランザクションを、ローカルトランザクションの連鎖 として実行する。 各ステップに 補償アクション (Compensating Action) を定義する。

コレオグラフィ vs オーケストレーション

製造業での Saga 例: 受注→手配→製作指示

コレオグラフィ方式:

1. SalesOrder: save() → OrderAccepted イベント発行
2. ProcurementService: OrderAccepted を受信 → PurchaseOrder 作成
3. ProductionService: OrderAccepted を受信 → ProductionInstruction 作成

補償: 受注キャンセル時
1. SalesOrder: cancel() → OrderCancelled イベント発行
2. ProcurementService: OrderCancelled を受信 → PurchaseOrder キャンセル
3. ProductionService: OrderCancelled を受信 → ProductionInstruction キャンセル

---

6. トランザクショナルアウトボックス

問題

「DB 更新とイベント発行を原子的に行う」のは難しい。

❌ 1. DB に save()  ← 成功
   2. イベント publish()  ← ここで失敗すると不整合

解決: アウトボックステーブル

✅ 1. DB に save() + outbox テーブルにイベントを INSERT (同一トランザクション)
   2. 別プロセスが outbox を polling → イベントを publish → outbox から削除

---

7. 設計判断のガイドライン