ES: Event Sourcing について考えている。今日は実践ドメイン駆動設計 (IDDD) の付録 A の『集約とイベントソーシング : A+ES 』をざっと読んだ。そのことについては書かない。それを見ていて疑問に思ったことや考えたことを書く。正しいかは知らない。
ES: Event Sourcing は永続化層の実装の詳細として扱えるだろうか。
リポジトリの実装でのみイベントを扱う。集約やユースケースなどではイベントを扱わない。そういうことができるのだろうか。
よく見る ES の例はどれもイベントは永続化層で収まっていない。前述の IDDD の付録 A もそうだ。ユースケース (アプリケーションサービス) の位置にイベントが出てくる。なぜだろう。どうしてイベントを永続化層の実装の詳細としてリポジトリの裏側に押し込まないのだろう。押し込めないのだろうか。 ES は永続化層の実装の詳細として扱えないのだろうか。
イベントを永続化層の実装の詳細として扱えないのだとするとより影響の大きな選択になる。 ES が影響の小さな選択であればより選択しやすい。できれば扱えてほしい。
ぼくの結論としては「扱えない」になった。
仮に「扱える」とする。つまりリポジトリの実装でのみイベントを扱う。集約やユースケースなどではイベントを扱わない。
このときリポジトリから集約を得ることはできる。イベントから状態は復元できる。イベントの積み重ねで状態は復元できる。
しかし集約をリポジトリに渡すことで永続化することはできない。状態からイベントを復元するのは難しい。不可能ではないだろうけど難しい。
let mut aggregate = repository.find_by_id(aggregate_id); // これはできる。リポジトリはイベントを持っている。イベントから状態を復元できる。 aggregate.update(); repository.save(aggregate); // これはできない。リポジトリは追加するイベントを必要とする。しかし状態しか渡されていない。
リポジトリの実装だけではなく集約もイベントを扱う。モデルにイベントを登場させることになる。
https://twitter.com/bouzuya/status/1434639124305092619
今日のコミット。
- rust-sandbox 1 commit
- rust-atcoder 2 commits
