Successfully reported this slideshow.

イベント・ソーシングを知る

40

Share

1 of 33
1 of 33

イベント・ソーシングを知る

40

Share

Download to read offline

Transcript

  1. 1. イベント・ソーシングを知る より価値の高いソフトウェア開発 のために
  2. 2. なんのはなし? • ソフトウェアの設計的な話 • ソフトウェアの情報をどのように永続化 して扱うか(ソーシング, Sourcing) • いつもと少し違うアプローチを紹介しま す
  3. 3. 例: 本のレンタルサービス 1. ユーザが本を登録する 2. 本はユーザなら誰でも借りられる 3. 本を借りた人が本を返す 4. 本がまた借りられるようになる(2に戻る)
  4. 4. 「フツーに」考える
  5. 5. たぶんこうなる 本テーブル的なもの タイトル 貸し出し ONE PIECE NARUTO
  6. 6. たぶんこうなる 1. スタンが「HUNTER×HUNTER」を登録 タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER
  7. 7. たぶんこうなる 1. スタンが「HUNTER×HUNTER」を登録 2. カイルが「HUNTER×HUNTER」を借りる タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER カイルが借り出し中
  8. 8. たぶんこうなる 1. スタンが「HUNTER×HUNTER」を登録 2. カイルが「HUNTER×HUNTER」を借りる 3. カイルが「HUNTER×HUNTER」を返す タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER
  9. 9. たぶんこうなる 1. スタンが「HUNTER×HUNTER」を登録 2. カイルが「HUNTER×HUNTER」を借りる 3. カイルが「HUNTER×HUNTER」を返す 4. ケニーが「HUNTER×HUNTER」を借りる タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER ケニーが借り出し中
  10. 10. 状態を中心に考える ステート・ソーシング
  11. 11. ステート・ソーシング • 従来の一般的な考え方 • ステート=状態 • 状態中心のソフトウェア設計 • あらゆる情報は状態が永続化される • 最新の状態を常に記憶しておくのが一般 的
  12. 12. フツーですね
  13. 13. 見落とされがちな問題 • 現在の状態はわかるが… • 状態が変化した理由や経緯が全て失われ る • ソフトウェアにとって非常に価値の高い 情報 • 履歴やログで記録をとるのは限界がある
  14. 14. ステート・ソーシングの問題を解決するために イベント・ソーシングとは
  15. 15. イベント中心に捉える • 様々な出来事(イベント)の結果、状態が変 化する • 「状態」はイベントの結果に過ぎず、本 質ではないのではないか(という考え方)
  16. 16. イベントを記録する • ソフトウェアで起こる全てのイベントを 記録する • 記録されたイベントは変更や削除をしな い • 「状態」は記録しません! • 何が起きたかだけを淡々と記録します
  17. 17. ほんとにそのまま記録します 1. スタンが「HUNTER×HUNTER」を登録 2. カイルが「HUNTER×HUNTER」を借りる 3. カイルが「HUNTER×HUNTER」を返す 4. ケニーが「HUNTER×HUNTER」を借りる このままです タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER ケニーが借り出し中
  18. 18. いやいや、でも状態は必要で しょ?
  19. 19. イベントを再生する • 記録されたイベントを順に再生すること で、現在の状態を導出できる • 1つずつイベントを辿れば必ず今の状態に たどり着きます
  20. 20. イベントを再生する順番に辿ります 1. スタンが「HUNTER×HUNTER」を登録 2. カイルが「HUNTER×HUNTER」を借りる 3. カイルが「HUNTER×HUNTER」を返す 4. ケニーが「HUNTER×HUNTER」を借りる 記録されているイベン タイトル 貸し出し ト ONE PIECE NARUTO
  21. 21. イベントを再生する 1. スタンが「HUNTER×HUNTER」を登録 2. カイルが「HUNTER×HUNTER」を借りる 3. カイルが「HUNTER×HUNTER」を返す 4. ケニーが「HUNTER×HUNTER」を借りる タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER
  22. 22. イベントを再生する 1. スタンが「HUNTER×HUNTER」を登録 2. カイルが「HUNTER×HUNTER」を借りる 3. カイルが「HUNTER×HUNTER」を返す 4. ケニーが「HUNTER×HUNTER」を借りる タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER カイルが借り出し中
  23. 23. イベントを再生する 1. スタンが「HUNTER×HUNTER」を登録 2. カイルが「HUNTER×HUNTER」を借りる 3. カイルが「HUNTER×HUNTER」を返す 4. ケニーが「HUNTER×HUNTER」を借りる タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER
  24. 24. イベントを再生する 1. スタンが「HUNTER×HUNTER」を登録 2. カイルが「HUNTER×HUNTER」を借りる 3. カイルが「HUNTER×HUNTER」を返す 4. ケニーが「HUNTER×HUNTER」を借りる タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER ケニーが借り出し中
  25. 25. イベントを再生する 1. スタンが「HUNTER×HUNTER」を登録 2. カイルが「HUNTER×HUNTER」を借りる 3. カイルが「HUNTER×HUNTER」を返す 4. ケニーが「HUNTER×HUNTER」を借りる 最新の状態が再現 タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER ケニーが借り出し中
  26. 26. イベント・ソーシングのすごいと ころ • ソフトウェアの完全な履歴が手に入る • ソフトウェアの任意の部分あるいは全体 を「ある時点」に簡単に再現できる • 有用な設計と相性が良い – ドメイン駆動設計(DDD) – コマンドクエリ責務分離(CQRS)
  27. 27. イベント・ソーシングすごい!
  28. 28. 残念ながら問題点も
  29. 29. パフォーマンス • 「最新の状態」を得るために、毎回膨大 な量のイベントをリプレイしていたら大 変 • 大量のイベントを捌かなければならない • ストレージ容量を多く使用する可能性
  30. 30. バージョニング • 仕様変更が起こったら、過去のイベント をどう処理するか • 最新の状態のみ影響を考えればよいス テート・ソーシングと違って、大量の過 去のイベントにも影響が出る
  31. 31. 実装が複雑 • イベントを記録してリプレイする機構を 実装しないといけない • 様々な問題に対処するために、様々な仕 組みを導入する必要があり、さらに複雑 さに輪をかける – キャッシング – イベントのアップデータ – 参照系の処理への対処
  32. 32. 最後に • ステート・ソーシングの問題を認識する – 当たり前すぎて気づかなかったり • イベント・ソーシングの可能性 – いろいろ問題はありますが、ステート・ソー シングでは成し得ない価値の提供ができるの では?
  33. 33. 参考 • Greg Young流CQRS - Mark Nijhof • Why Event Sourcing? • Event Sourcing and CQRS, Let's use it. • state ソーシング、 event ソーシング 【ス タイルの選択肢】 • event とメッセージング 【きっと、良い パターン】

Transcript

  1. 1. イベント・ソーシングを知る より価値の高いソフトウェア開発 のために
  2. 2. なんのはなし? • ソフトウェアの設計的な話 • ソフトウェアの情報をどのように永続化 して扱うか(ソーシング, Sourcing) • いつもと少し違うアプローチを紹介しま す
  3. 3. 例: 本のレンタルサービス 1. ユーザが本を登録する 2. 本はユーザなら誰でも借りられる 3. 本を借りた人が本を返す 4. 本がまた借りられるようになる(2に戻る)
  4. 4. 「フツーに」考える
  5. 5. たぶんこうなる 本テーブル的なもの タイトル 貸し出し ONE PIECE NARUTO
  6. 6. たぶんこうなる 1. スタンが「HUNTER×HUNTER」を登録 タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER
  7. 7. たぶんこうなる 1. スタンが「HUNTER×HUNTER」を登録 2. カイルが「HUNTER×HUNTER」を借りる タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER カイルが借り出し中
  8. 8. たぶんこうなる 1. スタンが「HUNTER×HUNTER」を登録 2. カイルが「HUNTER×HUNTER」を借りる 3. カイルが「HUNTER×HUNTER」を返す タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER
  9. 9. たぶんこうなる 1. スタンが「HUNTER×HUNTER」を登録 2. カイルが「HUNTER×HUNTER」を借りる 3. カイルが「HUNTER×HUNTER」を返す 4. ケニーが「HUNTER×HUNTER」を借りる タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER ケニーが借り出し中
  10. 10. 状態を中心に考える ステート・ソーシング
  11. 11. ステート・ソーシング • 従来の一般的な考え方 • ステート=状態 • 状態中心のソフトウェア設計 • あらゆる情報は状態が永続化される • 最新の状態を常に記憶しておくのが一般 的
  12. 12. フツーですね
  13. 13. 見落とされがちな問題 • 現在の状態はわかるが… • 状態が変化した理由や経緯が全て失われ る • ソフトウェアにとって非常に価値の高い 情報 • 履歴やログで記録をとるのは限界がある
  14. 14. ステート・ソーシングの問題を解決するために イベント・ソーシングとは
  15. 15. イベント中心に捉える • 様々な出来事(イベント)の結果、状態が変 化する • 「状態」はイベントの結果に過ぎず、本 質ではないのではないか(という考え方)
  16. 16. イベントを記録する • ソフトウェアで起こる全てのイベントを 記録する • 記録されたイベントは変更や削除をしな い • 「状態」は記録しません! • 何が起きたかだけを淡々と記録します
  17. 17. ほんとにそのまま記録します 1. スタンが「HUNTER×HUNTER」を登録 2. カイルが「HUNTER×HUNTER」を借りる 3. カイルが「HUNTER×HUNTER」を返す 4. ケニーが「HUNTER×HUNTER」を借りる このままです タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER ケニーが借り出し中
  18. 18. いやいや、でも状態は必要で しょ?
  19. 19. イベントを再生する • 記録されたイベントを順に再生すること で、現在の状態を導出できる • 1つずつイベントを辿れば必ず今の状態に たどり着きます
  20. 20. イベントを再生する順番に辿ります 1. スタンが「HUNTER×HUNTER」を登録 2. カイルが「HUNTER×HUNTER」を借りる 3. カイルが「HUNTER×HUNTER」を返す 4. ケニーが「HUNTER×HUNTER」を借りる 記録されているイベン タイトル 貸し出し ト ONE PIECE NARUTO
  21. 21. イベントを再生する 1. スタンが「HUNTER×HUNTER」を登録 2. カイルが「HUNTER×HUNTER」を借りる 3. カイルが「HUNTER×HUNTER」を返す 4. ケニーが「HUNTER×HUNTER」を借りる タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER
  22. 22. イベントを再生する 1. スタンが「HUNTER×HUNTER」を登録 2. カイルが「HUNTER×HUNTER」を借りる 3. カイルが「HUNTER×HUNTER」を返す 4. ケニーが「HUNTER×HUNTER」を借りる タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER カイルが借り出し中
  23. 23. イベントを再生する 1. スタンが「HUNTER×HUNTER」を登録 2. カイルが「HUNTER×HUNTER」を借りる 3. カイルが「HUNTER×HUNTER」を返す 4. ケニーが「HUNTER×HUNTER」を借りる タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER
  24. 24. イベントを再生する 1. スタンが「HUNTER×HUNTER」を登録 2. カイルが「HUNTER×HUNTER」を借りる 3. カイルが「HUNTER×HUNTER」を返す 4. ケニーが「HUNTER×HUNTER」を借りる タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER ケニーが借り出し中
  25. 25. イベントを再生する 1. スタンが「HUNTER×HUNTER」を登録 2. カイルが「HUNTER×HUNTER」を借りる 3. カイルが「HUNTER×HUNTER」を返す 4. ケニーが「HUNTER×HUNTER」を借りる 最新の状態が再現 タイトル 貸し出し ONE PIECE NARUTO HUNTER×HUNTER ケニーが借り出し中
  26. 26. イベント・ソーシングのすごいと ころ • ソフトウェアの完全な履歴が手に入る • ソフトウェアの任意の部分あるいは全体 を「ある時点」に簡単に再現できる • 有用な設計と相性が良い – ドメイン駆動設計(DDD) – コマンドクエリ責務分離(CQRS)
  27. 27. イベント・ソーシングすごい!
  28. 28. 残念ながら問題点も
  29. 29. パフォーマンス • 「最新の状態」を得るために、毎回膨大 な量のイベントをリプレイしていたら大 変 • 大量のイベントを捌かなければならない • ストレージ容量を多く使用する可能性
  30. 30. バージョニング • 仕様変更が起こったら、過去のイベント をどう処理するか • 最新の状態のみ影響を考えればよいス テート・ソーシングと違って、大量の過 去のイベントにも影響が出る
  31. 31. 実装が複雑 • イベントを記録してリプレイする機構を 実装しないといけない • 様々な問題に対処するために、様々な仕 組みを導入する必要があり、さらに複雑 さに輪をかける – キャッシング – イベントのアップデータ – 参照系の処理への対処
  32. 32. 最後に • ステート・ソーシングの問題を認識する – 当たり前すぎて気づかなかったり • イベント・ソーシングの可能性 – いろいろ問題はありますが、ステート・ソー シングでは成し得ない価値の提供ができるの では?
  33. 33. 参考 • Greg Young流CQRS - Mark Nijhof • Why Event Sourcing? • Event Sourcing and CQRS, Let's use it. • state ソーシング、 event ソーシング 【ス タイルの選択肢】 • event とメッセージング 【きっと、良い パターン】

More Related Content

Related Audiobooks

Free with a 30 day trial from Scribd

See all

×