■ 1. 概要
- イベント履歴式ドメインモデルは、状態ではなく「起きた出来事（イベント）」の履歴で集約を表現する設計手法
- 『ドメイン駆動設計をはじめよう』第7章で扱われる内容
■ 2. 従来の状態保存との違い
- 一般的なシステム（状態保存）:
- 現在のステータスのみを管理し、更新していく設計
- 分かるのは「今どうなっているか」だけであり、過程は表現されない
- イベント履歴式ドメインモデル:
- 現在の状態を直接保存せず、注文に対して起きたイベントを時系列で記録する
- 例: 注文作成 → 支払い完了 → 発送完了、という順でイベントを保存
- 状態はイベントの履歴から再構築できる
■ 3. 業務における「過程」の重要性
- 状態は結果であり、業務改善や分析では「そこに至る過程」が重要
- 状態保存のみでは把握できない情報の例:
- キャンセルを試みた履歴があるか
- 決済に何回失敗したか
- 支払いが遅れたことがあるか
- イベント履歴があることで上記のような業務理解が可能になる
■ 4. 現在の状態の扱い方
- イベントを先頭から順に適用することで現在の状態を再構築する
- イベント数が多くコストが高い場合は、途中時点の状態を保存し、そこから先のイベントのみ適用する工夫も行われる
- 重要なのは「状態を保存しないこと」ではなく、「イベント履歴をもとに状態を再構築する設計であること」
■ 5. イベント履歴から構築できる目的別モデル
- 同じイベント履歴から目的に応じた複数のモデルを作成できる:
- 現在の状態を知るためのモデル: 今の注文状況を画面表示する
- 検索しやすくするためのモデル: 過去の状態も含めて検索する
- 業務分析のためのモデル: キャンセル率や支払い成功率を分析する
■ 6. イベントストア
- イベントを保存するデータベースをイベントストアと呼ぶ
- イベントストアは追記専用であり、保存済みイベントは更新・削除しない
- イベントを「過去の事実」として扱うことがその理由
■ 7. メリット
- 過去の状態を再現できる:
- 任意の時点の状態をあとから再現可能
- 障害や不具合の調査に活用できる
- 業務の流れを詳しく把握できる:
- どこで失敗が多いか、処理が滞りやすいかを把握しやすい
- 業務改善につながる
- 履歴をそのまま監査に使える:
- 操作履歴を正確に追えるため、金銭を扱うシステムとの相性が良い
- 同時更新の内容を見て処理を判断できる:
- 通常の楽観的排他制御は「更新があったかどうか」のみを確認する
- イベント履歴がある場合は、追加されたイベントの内容を見て業務的に問題がないか判断できる
■ 8. デメリット
- 学習コストが高い:
- 従来の設計に慣れていると理解に時間がかかる
- チーム全体の理解が必要
- イベント設計の変更が難しい:
- イベントは基本的に書き換えないため、設計ミスの影響が大きい
- システムが複雑になりやすい:
- 設計・運用ともに難易度が上がる
- 正当な理由なく選択すべきではないとされている
■ 9. まとめ
- イベント履歴式ドメインモデルは、状態ではなくイベント履歴で集約を表現する設計
- 業務上重要な「過程」を記録できる点に価値がある
- 学習コストや設計の難しさもあるため、常に採用すべき手法ではない
- 設計の選択肢の一つとして理解し、要件に応じてチームで検討することが重要