EventのVersioning
↑タイトルと内容はたぶん一致してない
様々な変更の理由がある
Eventの構造を変えた
永続化してるデータも全部新しくする？
あるいは、処理する前に新しいものに変換する
Event Handlerは新しいものにのみ対応すればいい
しかしこれは変更が蓄積されてそのうち辛くなりそうな気もする(?)
eventの統合、分割、更新、削除があり得る
「EventのVersioning」は、この内の更新しか指していないmrsekut.icon
Stateの構造を変えた
create系、update系のeventの内容も変わったことを意味する
つまり、これも何らかのeventの更新を意味する
EventからStateを構築するロジックを変えた
後方互換性を保つための認知コストが大きい
過去のデータをどうmigrationするか？を常に考えないといけなくなる
永続化済みのEventを更新する方針
in-store migraion
event store内のデータを直接変更する
データの整合性を損なう可能性がある
バックアップしとかないと怖い
out-of store migraion
既存のeventを書き換えるのではなく、書き換えた別のevent列を作る
古いストリームからデータを読み込み、必要な変換を行う
変換後のデータを新しいストリームに書き込む
古いストリームを後で削除
この辺↑の変更時に容易に対応できるかはかなり重要
プログラム内のentityの構造は基本自由に変えられるべきであるが、
eventなどが永続化されていると、そこが密結合し、容易に変更できない範囲が増える
Gitみたいなツールがあるといいmrsekut.icon
過去が蓄積されつつも、過去の書き換えができる
commitを積み上げられるのはもちろん、コンフリクトを直せる、rebaseできる、
eventからstateを作るまでのフローをシンプルに保っておく必要がある
そのフロー自体が短い
stateが小さい
eventが小さい
eventの永続期間
例えば、Cosenseを考えると
エディタ上の操作のeventの永続期間はリロードするまでの間
一方でhistoryも別途ある
こっちはたぶん、定期的にstateを保存してる
例えば、見積から完了までのスパンが長いような注文処理を考えると
注文完了まではeventが保持されるべきだが、完了して用済みになったら後は不要、ということもありえる
その場合、重要なのは最終のstateだけであり、その経過のeventは今後の修正に影響を与えない
サービスローンチから一生eventが蓄積される場合、変更容易性がかなり重要になる
GPT-4.icon
Event Sourcingのコンセプトでは、すべての変更イベントが保存され、それらのイベントから状態が再構築されます。ご指摘の通り、イベントを基にした状態計算ロジックに変更が加わると、過去のイベントから正しい状態を再生成するのが難しくなる問題が発生します。この問題を解決するために、以下のような工夫やパターンが使用されます。
### 1. **イベントバージョニング**
イベント自体にバージョン情報を持たせることで、古いイベントと新しいイベントを区別します。これにより、新しいイベントのロジックが追加されても、古いイベントはそのバージョンに対応したロジックで処理されます。
### 2. **スナップショット**
定期的に状態のスナップショットを保存することで、イベントストリーム全体をリプレイする必要を減らします。スナップショットはイベントストリームの特定の時点での完全な状態を保存したもので、新しいイベントはこのスナップショットから適用されます。
### 3. **アップキャスト**
イベントのスキーマが変更された場合、古いイベントを新しい形式に変換するためのアップキャスト（Upcasting）という手法を用います。これにより、古いイベントを再生成する際に最新のロジックが適用されるようにします。
### 4. **互換性を考慮した設計**
イベントの設計段階で将来的な拡張を考慮し、後方互換性を保つようにします。例えば、イベントに新しいフィールドを追加する場合は、デフォルト値を設定するなどして、既存のロジックが破綻しないようにします。
### 5. **リプレイ機能のテスト**
イベントストリームの再生ロジックをテストするための専用の環境を用意し、イベントのリプレイが正確に行われることを確認します。このテスト環境では、新しいロジックが過去のイベントにどのように影響するかを検証できます。
### 6. **イベントストアの移行**
場合によっては、古いイベントストアを新しいイベントストアに移行する必要があります。これには、全てのイベントを新しい形式で再保存する、あるいは新しいイベントストアを導入するなどの方法があります。
これらの工夫やパターンを組み合わせて使用することで、Event Sourcingを利用する際のロジック変更による問題に対処しています。どの方法を選択するかは、システムの要件やアーキテクチャに依存します。
あとは、溜まっているevents全てに変更かける処理を行うとか
HTTP APIとかもそうだけど、過去のversionのAPI実装がコードベース上に残り続けるのが嫌