イベント駆動パターンの選定(アーキテクチャ設計)
4パターンの混同を避けることが最重要(Fowler の中心的指摘)
| 担当ロール | アーキテクト |
|---|---|
| インプット | — |
| アウトプット | — |
タスク(第3階層)
- Event Notification — 変化を知らせるだけ。結合最弱だが論理フローが暗黙化しデバッグ困難
- Event-Carried State Transfer — イベントに状態を載せ受信側の問い合わせ不要。復元力・低遅延だがデータ重複
- Event Sourcing — 状態変化をイベントログとして永続化、再生で状態復元。監査に強いが外部連携が難しい
- CQRS — 読み/書きモデルを分離。複雑ドメインを簡素化するが複雑性を追加