【いべんとそーしんぐ】
イベントソーシング とは？
最終更新:
💡 今の値だけでなく、そこまでの出来事を状態の源にする
業務上の変更をイベントとして順序付きで記録し、その履歴から状態を組み立てる設計。再生と訂正、CQRSとの関係、履歴を維持する難しさを説明します。
📌 このページのポイント
- 業務上の変更をイベントとして追記して保存する
- イベントの順序に沿って状態を組み立てる
- 訂正は過去の記録の書き換えではなく、打ち消すイベントなどで表す
- 履歴の形式や再生方法、外部への副作用を考えて設計する
ひよこ イベントソーシングは、操作ログを残すこと？
ペンギン先生 履歴を残すだけではなく、そのイベントを状態の源として扱う設計だよ。例えば残高0から「5000円入金」「8000円入金」「3000円出金」を順に適用すると、残高10000円になる。
ひよこ 過去の状態にも戻せる？
ペンギン先生 必要なイベントが残り、当時の記録を扱える処理があれば、ある時点まで再生して状態を組み立てられるよ。ただし実際の送金まで巻き戻せるという意味ではない。再生時に同じ外部処理を繰り返さない工夫が必要なんだ。
ひよこ 間違った記録は、上書きして直す？
ペンギン先生 通常は過去のイベントを変えず、打ち消すイベントなどを追加する。長く使うとデータ形式も変わるので、古いイベントを読み取る方法まで設計する必要があるよ。
ひよこ CQRSとはセットで使うの？
ペンギン先生 読み取り用と更新用の扱いを分けるCQRSと組み合わせることはあるけれど、別の考え方だよ。履歴から状態を作り直す必要があるか、複雑さに見合うかを考えて選ぼう。単なる履歴保存で足りる場合もあるんだ。
まとめ：ざっくりこれだけ覚えればOK！
「イベントソーシング」って出てきたら「出来事の履歴を源にして状態を組み立てる設計」と思えばだいたいOK！
📖 おまけ：英語の意味
「Event Sourcing」 ＝ イベントを状態の源にすること
💬 業務上の変更を表すEventをSourceにする設計です。単に操作ログを残すことではなく、保存したイベントを状態の根拠として扱います。