event sourcingとは? 状態ではなく変更を保存する
event sourcingは、あらゆる状態変更を不変のイベントとして保存し、現在の状態はそれらのイベントを順に再生することで導き出されます。
最新の状態だけを保存する代わりに、event sourcingは何が起きたかの完全な履歴をイベントの列として記録します。現在の状態は、その履歴に対するfoldです。これにより完璧な監査証跡と、過去の任意の状態を再構築する能力が得られますが、より複雑なクエリと慎重なスキーマ規律という代償を伴います。
真実の源泉としてのイベント
イベントログが記録の唯一の源です。各イベントは起きた事実 (口座に入金された、商品が発送された) を捉え、決して変更されません。状態はイベントを再生して計算されるため、履歴は常に完全で監査可能です。
得られるもの
- 構造上、完全で不変な監査証跡。
- 履歴から状態を再構築したり、新しいread modelを構築したりする能力。
- タイムトラベル: 過去の任意の時点の状態を再構築する。
- CQRSやイベント駆動設計との自然な適合。
スキーマの進化が難所
古いイベントは永遠に残るため、イベントフォーマットの変更は読める状態を保たねばなりません。イベントをバージョン管理し、古い形を新しい形に変換するupcasterを書きます。これを誤ると再生が壊れるため、イベントスキーマのテストがCIで重要になります。
再生とprojectionのテスト
event sourcingのシステムは、イベントの列を与えて、結果の状態とprojectionをアサートすることでテストします。パイプラインは、スキーマ変更後も過去のイベントが正しく再生されることも検証すべきであり、これはevent sourcing特有のテストです。
デプロイと再構築
新しいprojectionをデプロイすることは、しばしばイベントログ全体を再生してread modelを再構築することを意味し、遅くなりえます。チームは、古いread modelがまだトラフィックを処理している間に、projectionがバックグラウンドで再構築されるようデプロイを設計します。
より重いテストプロファイル
長いイベントストリームに対する再生と再構築のテストはCPU負荷が高くなります。適切にサイズされたウォームなrunner (Latchkeyが提供するもの) は、それらの長めのスイートがフィードバックループを引き延ばさないようにします。
重要なポイント
- event sourcingは不変のイベントを保存し、それらを再生して状態を導き出します。
- 完全な監査証跡を提供しますが、規律あるイベントスキーマのバージョン管理を要求します。
- デプロイでは履歴を再生してread modelを再構築することがあるので、パイプラインでそれを見込んでおきましょう。