EventからStateを構築するロジックを変更した時
GPT-4.icon
Event Sourcingのコンセプトでは、すべての変更イベントが保存され、それらのイベントから状態が再構築されます。ご指摘の通り、イベントを基にした状態計算ロジックに変更が加わると、過去のイベントから正しい状態を再生成するのが難しくなる問題が発生します。この問題を解決するために、以下のような工夫やパターンが使用されます。
### 1. **イベントバージョニング**
イベント自体にバージョン情報を持たせることで、古いイベントと新しいイベントを区別します。これにより、新しいイベントのロジックが追加されても、古いイベントはそのバージョンに対応したロジックで処理されます。
### 2. **スナップショット**
定期的に状態のスナップショットを保存することで、イベントストリーム全体をリプレイする必要を減らします。スナップショットはイベントストリームの特定の時点での完全な状態を保存したもので、新しいイベントはこのスナップショットから適用されます。
### 3. **アップキャスト**
イベントのスキーマが変更された場合、古いイベントを新しい形式に変換するためのアップキャスト（Upcasting）という手法を用います。これにより、古いイベントを再生成する際に最新のロジックが適用されるようにします。
### 4. **互換性を考慮した設計**
イベントの設計段階で将来的な拡張を考慮し、後方互換性を保つようにします。例えば、イベントに新しいフィールドを追加する場合は、デフォルト値を設定するなどして、既存のロジックが破綻しないようにします。
### 5. **リプレイ機能のテスト**
イベントストリームの再生ロジックをテストするための専用の環境を用意し、イベントのリプレイが正確に行われることを確認します。このテスト環境では、新しいロジックが過去のイベントにどのように影響するかを検証できます。
### 6. **イベントストアの移行**
場合によっては、古いイベントストアを新しいイベントストアに移行する必要があります。これには、全てのイベントを新しい形式で再保存する、あるいは新しいイベントストアを導入するなどの方法があります。
これらの工夫やパターンを組み合わせて使用することで、Event Sourcingを利用する際のロジック変更による問題に対処しています。どの方法を選択するかは、システムの要件やアーキテクチャに依存します。
あとは、溜まっているevents全てに変更かける処理を行うとか
HTTP APIとかもそうだけど、過去のversionのAPI実装がコードベース上に残り続けるのが嫌
stateの構造を変更すると壊れる
eventの構造を変更すると壊れる
後方互換性を保つための認知コストが大きい
過去のデータをどうmigrationするか？を常に考えないといけなくなる
eventからstateを作るまでのフローをシンプルに保っておく必要がある
そのフロー自体が短い
stateが小さい
eventが小さい
softwareは修正が容易であることが強みだったのに、それが活かせない感覚がある
プログラム内のentityの構造は基本自由に変えられるべきであるが、
eventなどが永続化されていると、そこが密結合し、容易に変更できない範囲が増える
例えば、境界でこういうparseを導入するとか
永続化しているeventの構造→プログラム用のeventの構造
適当に書いてるのでこれで何が解決されるのかしらんけど、疎結合にはなる