マイクロサービス・パターンの「イベントソーシングを使ったビジネスロジックの開発」を読んで

イベントソーシングに関して復習したく、過去に読んだマイクロサービス・パターンのChapter6を復習。 下記、読んで覚えておきたいことのメモ。イベントソーシング、正直難しい。。イベントソーシングを適用した実装パターンのイメージがまだ曖昧で輪郭をぼんやりとしか捉えられてないので、他のリファレンス等も参照して学びを深めたい。

• イベントソーシング
  • イベントを中心に据えてビジネスロジックを書き、ドメインオブジェクトを永続化するアプローチ。アグリゲート（境界の範囲内にあるドメインオブジェクトの集合）に対する全ての変更履歴が保持される
  • イベントソーシングはアグリゲートが更新、作成された時に必ずイベントがパブリッシュされることを保証する
  • 個々のイベントはアグリゲートの状態変更を表す

• 従来の永続化が抱える問題点

  • 従来の永続化では、クラス（アグリゲート）をデータベースのテーブルに、クラスのフィールドをテーブルのカラムに、クラスのインスタンスをテーブルのレコードにマッピングする
  • 上記のデメリット
    • アグリゲートの現在の状態しか格納しないので、履歴が失われる
    • ドメインイベント（アグリゲートの状態が変わった時に、アグリゲートがパブリッシュするイベント）のパブリッシュをサポートしないので、イベント生成ロジックを後付けで実装する必要がある

• イベントソーシングの概要

  • イベントという形でアグリゲートを永続化し、それらのイベントからアグリゲートの現在の状態を再構築する　　　　
  • 個々のイベントがアグリゲートの状態変更を表す
  • データベースにイベントのシーケンスという形で個々のアグリゲートを永続化し、それをイベントストアと呼ぶ
  • アプリケーションはアグリゲートを作成、更新した時にアグリゲートが生成したイベントをEVENTSテーブルに格納する
• 楽観的ロックを使った同時更新
  • 複数のリクエストが同じアグリゲートを更新しようとするパターンがある
  • 従来の方法では他のトランザクションによる上書きを防ぐため、楽観的ロックを使用する
  • イベントソーシングでも楽観的ロックが使用可能
  • アグリゲートが更新されるたびにバージョンを更新し、アグリゲートを読み取ってバージョンに対して変更がない場合のみUPDATEに成功する。二つのトランザクションが同じアグリゲートを読み取った場合、先にアグリゲートを更新した方が成功する
• メッセージコンシューマを開発するときに大切なこと
  • メッセージブローカーは同じメッセージを複数回送ってくる可能性があるので、イベント消費時の処理をべき等にする必要がある
  • 処理したメッセージのIDをprocessed_messagesに格納する。メッセージのIDが既にある場合、そのメッセージは重複分であり、捨てると判断できる

Chris Richardson　著/長尾高弘　訳/橂澤広亨　監修 マイクロサービスパターン[実践的システムデザインのためのコード解説] (impress top gear)（インプレス発行 978-4295008583）