cqrs-to-event-sourcing

CQRSはなぜEvent Sourcingになるのか

CQRSを実装すると、C側からQ側への同期問題に直面し、イベントソーシングに至る。これはオプションではなく、実装上の必然である。

よくある誤解: 「CQRSはモデルを分ける必要がない」

この解釈は危険な誤読である。

正しい意味は「システムのうち、CQRS領域と非CQRS領域に分けることができ、CQRSを部分導入できる」ということ。モデルを分けなくてよいのは非CQRS領域であり、CQRS領域内ではコマンドモデルとクエリモデルの分割は必須。

システム全体
├── CQRS領域     → モデル分割は必須
└── 非CQRS領域   → 分割不要（従来のCRUDで十分）

「CQRSはモデルを分割しなくてもいい」という解釈は、もはやCQRSではない。

C側とQ側のデータの違い

CQRSにおいて、C側（コマンド）とQ側（クエリ）のデータは根本的に異なる。

具体例: カートシステム

C側テーブル（ドメインモデルの永続化に必要な最小データ）:

カートテーブル	カートアイテムテーブル
カートID (PK)	カートアイテムID (PK)
顧客アカウントID	カートID (FK)
上限予算金額	商品ID
作成日時	数量
	作成日時

Q側テーブル（表示・検索に必要なデータ）:

カートテーブル	カートアイテムテーブル
カートID (PK)	カートアイテムID (PK)
顧客アカウントID	商品ID
顧客アカウント名 ★	商品名 ★
上限予算金額	数量
合計金額 ★	単価 ★
	価格 ★

★の値はC側のデータベースに存在しない。ドメインオブジェクトの振る舞いによって計算される派生値である。

case class Cart(id: CartId, items: CartItems, ...) {
  // 合計金額はドメインオブジェクトの計算結果であり、DBに保存されない
  def totalPrice(priceResolver: ItemId => Price): Price =
    items.fold(Price.zero){ (t, item) => t + item.price(priceResolver) }
}

case class CartItem(id: CartItemId, itemId: ItemId, quantity: Quantity, ...) {
  // 単価は外部から提供され、価格は計算される
  def price(priceResolver: ItemId => Price): Price =
    priceResolver(itemId) * quantity
}

同期方法の段階的検討と限界

方法1: トリガーによる同期

C側のテーブル更新時にSQLでQ側を書き込む。

限界:

• 静的データ（顧客名等）の転送には有効
• 計算された値（★）は同期できない - ドメインロジックの計算結果はDBに存在しない
• 同じ計算ロジックのSQLを書くのは困難であり、ビジネスロジックの重複を生む
• 苦肉の策として計算結果もC側に保存すると、リポジトリのインターフェースが歪む

// ❌ リポジトリに計算ロジックの責務が漏れる
trait CartRepository {
  def store(cart: Cart, priceResolver: ItemId => Price): Unit
  // priceResolverはリポジトリの責務ではない
}

方法2: ポーリングによる同期

プログラムでC側テーブルを読み込み、ドメインオブジェクトで計算後、Q側に書き込む。

限界:

• 計算結果のQ側転送は可能
• 「いつ変更されたか」を検知できない - 変更トリガーがない
• 全集約をポーリングする必要があり、スケーラビリティがない
• 大量の集約が存在する場合、実用的ではない

結論: 最新状態を手に入れるにしても、更新イベントが必要。

方法3: イベント通知キューの導入

変更時にイベントをキューに発行し、Q側更新プログラムがイベントを受信して同期する。