1. イベント・ソーシングを知る
より価値の高いソフトウェア開発
のために

2. なんのはなし？
• ソフトウェアの設計的な話
• ソフトウェアの情報をどのように永続化
して扱うか(ソーシング, Sourcing)
• いつもと少し違うアプローチを紹介しま
す

3. 例: 本のレンタルサービス
1. ユーザが本を登録する
2. 本はユーザなら誰でも借りられる
3. 本を借りた人が本を返す
4. 本がまた借りられるようになる(2に戻る)

4. 「フツーに」考える

5. たぶんこうなる
本テーブル的なもの
タイトル 貸し出し
ONE PIECE
NARUTO

6. たぶんこうなる
1. スタンが「HUNTER×HUNTER」を登録
タイトル 貸し出し
ONE PIECE
NARUTO
HUNTER×HUNTER

7. たぶんこうなる
1. スタンが「HUNTER×HUNTER」を登録
2. カイルが「HUNTER×HUNTER」を借りる
タイトル 貸し出し
ONE PIECE
NARUTO
HUNTER×HUNTER カイルが借り出し中

8. たぶんこうなる
1. スタンが「HUNTER×HUNTER」を登録
2. カイルが「HUNTER×HUNTER」を借りる
3. カイルが「HUNTER×HUNTER」を返す
タイトル 貸し出し
ONE PIECE
NARUTO
HUNTER×HUNTER

9. たぶんこうなる
1. スタンが「HUNTER×HUNTER」を登録
2. カイルが「HUNTER×HUNTER」を借りる
3. カイルが「HUNTER×HUNTER」を返す
4. ケニーが「HUNTER×HUNTER」を借りる
タイトル 貸し出し
ONE PIECE
NARUTO
HUNTER×HUNTER ケニーが借り出し中

10. 状態を中心に考える
ステート・ソーシング

11. ステート・ソーシング
• 従来の一般的な考え方
• ステート＝状態
• 状態中心のソフトウェア設計
• あらゆる情報は状態が永続化される
• 最新の状態を常に記憶しておくのが一般
的

12. フツーですね

13. 見落とされがちな問題
• 現在の状態はわかるが…
• 状態が変化した理由や経緯が全て失われ
る
• ソフトウェアにとって非常に価値の高い
情報
• 履歴やログで記録をとるのは限界がある

14. ステート・ソーシングの問題を解決するために
イベント・ソーシングとは

15. イベント中心に捉える
• 様々な出来事(イベント)の結果、状態が変
化する
• 「状態」はイベントの結果に過ぎず、本
質ではないのではないか(という考え方)

16. イベントを記録する
• ソフトウェアで起こる全てのイベントを
記録する
• 記録されたイベントは変更や削除をしな
い
• 「状態」は記録しません！
• 何が起きたかだけを淡々と記録します

17. ほんとにそのまま記録します
1. スタンが「HUNTER×HUNTER」を登録
2. カイルが「HUNTER×HUNTER」を借りる
3. カイルが「HUNTER×HUNTER」を返す
4. ケニーが「HUNTER×HUNTER」を借りる
このままです
タイトル 貸し出し
ONE PIECE
NARUTO
HUNTER×HUNTER ケニーが借り出し中

18. いやいや、でも状態は必要で
しょ？

19. イベントを再生する
• 記録されたイベントを順に再生すること
で、現在の状態を導出できる
• 1つずつイベントを辿れば必ず今の状態に
たどり着きます

20. イベントを再生する順番に辿ります
1. スタンが「HUNTER×HUNTER」を登録
2. カイルが「HUNTER×HUNTER」を借りる
3. カイルが「HUNTER×HUNTER」を返す
4. ケニーが「HUNTER×HUNTER」を借りる
記録されているイベン
タイトル 貸し出し ト
ONE PIECE
NARUTO

21. イベントを再生する
1. スタンが「HUNTER×HUNTER」を登録
2. カイルが「HUNTER×HUNTER」を借りる
3. カイルが「HUNTER×HUNTER」を返す
4. ケニーが「HUNTER×HUNTER」を借りる
タイトル 貸し出し
ONE PIECE
NARUTO
HUNTER×HUNTER

22. イベントを再生する
1. スタンが「HUNTER×HUNTER」を登録
2. カイルが「HUNTER×HUNTER」を借りる
3. カイルが「HUNTER×HUNTER」を返す
4. ケニーが「HUNTER×HUNTER」を借りる
タイトル 貸し出し
ONE PIECE
NARUTO
HUNTER×HUNTER カイルが借り出し中

23. イベントを再生する
1. スタンが「HUNTER×HUNTER」を登録
2. カイルが「HUNTER×HUNTER」を借りる
3. カイルが「HUNTER×HUNTER」を返す
4. ケニーが「HUNTER×HUNTER」を借りる
タイトル 貸し出し
ONE PIECE
NARUTO
HUNTER×HUNTER

24. イベントを再生する
1. スタンが「HUNTER×HUNTER」を登録
2. カイルが「HUNTER×HUNTER」を借りる
3. カイルが「HUNTER×HUNTER」を返す
4. ケニーが「HUNTER×HUNTER」を借りる
タイトル 貸し出し
ONE PIECE
NARUTO
HUNTER×HUNTER ケニーが借り出し中

25. イベントを再生する
1. スタンが「HUNTER×HUNTER」を登録
2. カイルが「HUNTER×HUNTER」を借りる
3. カイルが「HUNTER×HUNTER」を返す
4. ケニーが「HUNTER×HUNTER」を借りる
最新の状態が再現
タイトル 貸し出し
ONE PIECE
NARUTO
HUNTER×HUNTER ケニーが借り出し中

26. イベント・ソーシングのすごいと
ころ
• ソフトウェアの完全な履歴が手に入る
• ソフトウェアの任意の部分あるいは全体
を「ある時点」に簡単に再現できる
• 有用な設計と相性が良い
– ドメイン駆動設計(DDD)
– コマンドクエリ責務分離(CQRS）

27. イベント・ソーシングすごい！

28. 残念ながら問題点も

29. パフォーマンス
• 「最新の状態」を得るために、毎回膨大
な量のイベントをリプレイしていたら大
変
• 大量のイベントを捌かなければならない
• ストレージ容量を多く使用する可能性

30. バージョニング
• 仕様変更が起こったら、過去のイベント
をどう処理するか
• 最新の状態のみ影響を考えればよいス
テート・ソーシングと違って、大量の過
去のイベントにも影響が出る

31. 実装が複雑
• イベントを記録してリプレイする機構を
実装しないといけない
• 様々な問題に対処するために、様々な仕
組みを導入する必要があり、さらに複雑
さに輪をかける
– キャッシング
– イベントのアップデータ
– 参照系の処理への対処

32. 最後に
• ステート・ソーシングの問題を認識する
– 当たり前すぎて気づかなかったり
• イベント・ソーシングの可能性
– いろいろ問題はありますが、ステート・ソー
シングでは成し得ない価値の提供ができるの
では？

33. 参考
• Greg Young流CQRS - Mark Nijhof
• Why Event Sourcing?
• Event Sourcing and CQRS, Let's use it.
• state ソーシング、 event ソーシング 【ス
タイルの選択肢】
• event とメッセージング 【きっと、良い
パターン】