Command（コマンド）・Event（イベント）・Saga（サーガ）の 3 要素を組み合わせ、CQRS とイベントソーシングを分散トランザクション運用まで一気通貫で扱う設計スタイル。
概要
単一サービス内では CQRS + Event Sourcing でうまくいくが、サービス境界を跨ぐ業務（注文確定 → 在庫引当 → 決済 → 配送手配）では 2PC（2 フェーズコミット）が現実的でない。CES アプローチは 「イベントを駆動軸にした長期トランザクション」 を Saga として明示的にモデリングする。
3 要素の役割
| 要素 | 役割 | 例 |
|---|---|---|
| Command | 「◯◯せよ」という意図。受け付けて妥当性を検証する | PlaceOrderCommand |
| Event | 「◯◯が起きた」という事実。追記のみで不変 | OrderPlacedEvent |
| Saga | 複数 Event を協調させる長期プロセス。失敗時の補償も持つ | 注文 → 在庫 → 決済 → 配送 の連鎖と巻き戻し |
Saga の 2 つのスタイル
| スタイル | 制御 | 適性 |
|---|---|---|
| Choreography（振付） | 各サービスがイベントを購読して自律的に動く | 関係数が少ない・疎結合を最優先 |
| Orchestration（指揮） | 中央の Saga マネージャが順序を制御 | フローが複雑・補償が多い |
補償トランザクション
Saga の核心は 失敗時の巻き戻しを業務イベントで表現する点にある。DB のロールバックではなく、「在庫引当キャンセル」「決済返金」「注文取消」といった業務上のアクションを補償イベントとして発行することで、結果整合性を保つ。
CES が効く場面
- マイクロサービス間で長期トランザクションが必要
- 業務上「失敗」が日常的に起こる（在庫切れ・決済失敗・配送不可）
- 監査要件が厳しく、すべての出来事を追跡可能にしたい
- 複数チャネル（モール・店頭・倉庫）で在庫やステータスを同期する
CES が過剰な場面
- 単一 DB で完結する CRUD 主体の業務
- 結果整合性を業務側が許容できない領域
- チームに DDD・Event Sourcing の運用知見が薄い段階
EC ドメインでの適用イメージ
CTS-EC 共通商品マスタのようにマルチモール在庫・出品状態を同期するドメインでは、 「商品マスタ更新 → 各モール反映 → 在庫差分検知 → 自動補正」 といった長期工程が日常的に発生する。各ステップで部分的な失敗（モール側 API エラー・在庫不整合）が起こりうるため、補償付き Saga として明示的にモデリングする価値が高い。
関連記事
- 開発手法ガイド：概要 — DDD 発展形としての位置づけ
- CTS-EC 共通商品マスタ — マルチモール EC で CES を活かせるドメイン例