こんにちは。
私は普段フリーランスエンジニアとして、バックエンドやインフラ面からアプリ構築を支援したりしています。
今回は、設計の概念であるイベントソーシングについてざっくりと書きます。
◇イベントソーシング
イベントソーシング（Event Sourcing）は、データベース内のエンティティの状態を “状態の変更イベント” のログとして記録する手法です。
通常、データベースのエンティティ（たとえば注文やユーザー情報など）の現在の状態だけを保持するのではなく、その状態に至るすべての変更イベントを順番に保存しておくことで、エンティティの任意の時点での状態を再現できます。
◇基本概念
・イベントの記録
各エンティティの変更（たとえば「注文の作成」「注文のキャンセル」）は「イベント」として記録されます。このイベントには、発生した日時や対象エンティティなどの情報が含まれます。
・イベントをソース（ソースオブ・トゥルース）とする
状態を直接変更するのではなく、イベントをもとに状態を再現します。現在の状態は、過去のイベントのリプレイ（再生）によって生成されるため、データの整合性と履歴の透明性が確保できます。
・アプリケーションのビジネスロジック
イベントに基づいてビジネスロジックを実行し、アプリケーションの状態を更新することが可能になります。
◇イベントソーシングのメリット
・履歴管理と監査性
すべての変更履歴が保存されるため、いつ誰が何を行ったかを正確に追跡可能です。監査が必要なアプリケーションに適しています。
・データ復元と再構築
任意の時点の状態を再構築できるため、例えばバグの修正後に過去のデータを適用することができます。
・非同期処理と拡張性
イベントを他のサービスやシステムと非同期で共有可能です（特にマイクロサービスアーキテクチャに適しています）。
◇イベントソーシングのデメリット
・複雑さの増加
イベントのリプレイにより状態を計算するため、システムが複雑になりやすく、管理が難しくなることがあります。
・ストレージのコスト
イベントの履歴が増えるほど、ストレージコストが高くなります。また、全イベントをリプレイするのに時間がかかる可能性があります。
・イベントのデータスキーマのバージョン管理
イベントのスキーマ変更が難しく、過去のイベントに遡って修正するには慎重な設計と対応が必要です。
◇イベントソーシングの実装例
・イベントの保存
たとえば、注文システムで「注文作成」「支払い」「キャンセル」などのイベントを保存する場合、それぞれのイベントは「イベントテーブル」や「ログ」に記録されます。
・アグリゲートの生成
イベントをリプレイすることで、現在の注文情報（支払い済み、キャンセル済みなど）の状態を生成します。
・クエリモデルの更新
状態が頻繁に参照される場合、各イベントのリプレイに時間がかかるため、「スナップショット」を作成してリプレイの負荷を下げることもあります。
◇まとめ
イベントソーシングは、エンティティの状態を「イベント」の形で記録し、それを再生して任意の時点の状態を再現する設計手法です。履歴追跡やシステム拡張性に優れていますが、設計の複雑さとデータ管理が難しいため、システム要件や目的に応じて慎重に検討する必要があります。
入会申込
ログイン
