Slide 1
Slide 1 text
Event Sourcingの
理想と現実
2024 JJUG CCC Fall
Slide 2
Slide 2 text
● 名前：なかやまひろ@せち
● 都内のシステム開発会社に勤務
○ フリーランスと会社員を行ったりきたり
● 最近のお仕事は社内の何でも屋！
○ AWSからFEまでやってます
○ Javaやりたい・・・
● 趣味は自転車乗ったりゲームしたり
○ スライド作りとかで乗れてないのがつらい
● JJUGはオフラインでは初めて
● 猫可愛いので覚えて帰って
自己紹介
JJUG Tシャツを
バリバリした直後の犯
猫
Slide 3
Slide 3 text
QRコードをスマホ等で読み込むか、気合いで解読してください。入り切らな
かったネタとかも書いてあります。
スライドこちら
Slide 4
Slide 4 text
EventSourcingについて・・・
● 知らない！聞いたこともない！今日初めて知った！
● ネットで記事を見たことあるし、概要は知ってるけど使ったことない
● めっちゃ使ってますし、何でしたら代わりに20分話しますよ？
質問です！
Slide 5
Slide 5 text
EventSourcingについて・・・
● 知らない！聞いたこともない！今日初めて知った！
● ネットで記事を見たことあるし、概要は知ってるけど使ったことない
● めっちゃ使ってますし、何でしたら代わりに20分話しますよ？
質問です！
Slide 6
Slide 6 text
このセッションで得られる（といいなぁ・・・）もの
● 知らない人
○ EventSourcingっていうものがあること
● 知ってるけどやったことない人
○ 経験しなければわからないところを知っていただければ
● 既に導入してる人
○ こういうアプローチもある
知らなくても大丈夫です
Slide 7
Slide 7 text
● Event Sourcingとは？
● Event Sourcingを実践してみた話
● まとめ（良かったところとか）
EventSoucingのアプリケーションに携わった経験も交えつつ、お話ししていく
予定です。
今日話すこと
Slide 8
Slide 8 text
● EventSoucingについての詳しい解説
○ これだけで20分飛んでしまう・・・
● 実装は簡単に紹介しますが、具体的な細かいところまでは踏み込まない
です
○ SpringModulithとEventSoucingで検索すると良さげなサンプルが
あります
今日話さないこと
Slide 9
Slide 9 text
Event Sourcingとは？
Slide 10
Slide 10 text
一言で言うならば「アプリケーションの状態管理とデータ保存のためのアーキ
テクチャパターン」で、以下の2つが特徴です。
● システムで発生するEventを記録（状態は記録しない）
○ 一般的なシステムは状態を記録・更新していく
● 保存したイベントを発生順に再生することで「現在の状態」を表現する
実際に設計する際はCQRSと組み合わせることが多いです。（CQRSの説明は
割愛）
Event Sourcingとは？
Slide 11
Slide 11 text
銀行の例で説明してみます。口座開設からの入出金のEventを記録します。
残高（現在の状態）が必要な場合、Eventを最初から再生することで算出でき
ます。
Event?再生？どゆこと？
Slide 12
Slide 12 text
どうやってEventの登録と再生を行うのでしょうか。ざっくり書くとこのような形
になります。（各要素の呼び名は色々あります）
どう実現するのか？
Slide 13
Slide 13 text
一般的にこういうところがメリットと言われています。
● 関心ごとが別れているため、ソースコードの複雑さが軽減する
○ アーキテクチャの複雑さでなんとかする
● 発生したEventを全て記録することで、データロス発生を防ぐ
● Eventが監査にも利用できるログやデータ更新の履歴管理として利用で
きる（副次的な効果）
もちろん欠点もありますが、それは後ほど。
で、Event Sourcingは何を解決したいの？
Slide 14
Slide 14 text
Event Sourcingを構成する要素を、以下の５つに定義します。
● Command：Eventを登録する更新用API
● Query：現在のデータを参照するAPI
● EventListner：Eventを再生して現在のデータを作り出す処理。キューを
用いて非同期で実行することもある。
● EventStore：Eventを登録するデータベース
● ViewModel：Eventを再生して作成した参照用データベース
※色々呼び名はあります
本資料における用語の定義（参考）
Slide 15
Slide 15 text
Event Sourcingを実践してみた話
Slide 16
Slide 16 text
一番最初にEvent Sourcingと出会ったのは2018年くらい。レガシーの金融シ
ステムをクラウドにリプレイスするにあたり、全体的なアーキテクチャや設計方
針を検討中の時でした。
その当時流行っていたマイクロサービスでの構築を検討していたものの、デー
タの整合性をどうやって担保するかで悩んでいました。
そんなときにEvent Sourcingと出会い、一縷の希望を感じたものPoCの実践
までで断念しました。
Event Sourcingとの出会い（自分語り）
Slide 17
Slide 17 text
昔のことなのでうろ覚えですが、こんなことを感じました。
● 上手く作ればハマりそうな気がする
● でも難易度が高すぎるのでは？
○ そこそこ大きなプロジェクトなのでメンバーが多く、全員にEvent
Sourcingを習得させるのは困難
○ 設計失敗したら取り返しがつかないのでは？
● イレギュラーなケース出てきたとき対応し切れるのか・・・
○ 将来発生するであろう未知の要件への不安
Event Sourcingを諦めた理由
Slide 18
Slide 18 text
現在の会社に入社し、担当になったのがEvent Sourcingで構築されたサー
ビス。
個人的な感想としては「マジか！あの難しそうなもので作り切ったのか！スゴ
イ！」
今回はこのサービスをベースにお話しします。
Event Sourcingとの再会
Slide 19
Slide 19 text
アプリケーションは売り手と買い手の間を取り次ぐ業務システム。
1. 買い手は欲しい商品を検索
2. 商品が見つかったら売り手が見積（条件のすり合わせ）
3. 条件に合意したら発注
条件のすり合わせ中に発生する差分、過去に販売した金額確認で履歴が重
要という声がユーザーから上がっていた。
履歴が重要・・・Event Sourcingやってみよう！
サービスの簡単な説明
Slide 20
Slide 20 text
アーキテクチャは前に紹介した構図とほぼ同じ。ただ、Event Listnerは
Commandから起動し、同一トランザクションで処理を実施する。（１トランザク
ションでEventとViewModelの両方を作成）
アーキテクチャ
Slide 21
Slide 21 text
EventListenerはCommandから実行しています。とは言え、直接呼ぶわけ
ではなく、Eventの型に応じたクラスのListnerが動く仕組みになっています。
今だとSpring Modulith使うとフレームワークで解決できますね。
Eventの再生はQueueを用いて非同期で行うこともありますが、同期で実行し
ています。
ではEventとは一体なんなのでしょうか？
アーキテクチャ補足
Slide 22
Slide 22 text
Eventはシステムで発生した出来事で、Javaの場合はRecordで実装するの
がおすすめです。ドメインに関する属性とEventとして取り扱うための属性から
構成されます。
Eventはデータクラス
例えばユーザー作成Eventであれば、メールア
ドレスやユーザー名といった属性が含まれます。
1つのユースケースに対して1個のEventができ
る。簡単ですね。
Slide 23
Slide 23 text
特別な処理をしているわけではなく、普通のビジネスロジックを実行していま
す。
個人的には同じイベントを複数回再生されても大丈夫なように作るのを推奨し
ます。
Event再生ってなにするの？
Slide 24
Slide 24 text
大きいイベントは分割して持つ場合があります。例として、注文は複数明細を
持つため、各明細は別Eventとして扱います。テーブル設計に近いと思いま
す。Listenerの設計も大変・・・。
Eventが複雑になると・・・
Slide 25
Slide 25 text
設計の進め方は色々あると思いますが、モデリングやデータの設計をした後、
何をイベントにするのかを決めるのが良いと思います。
ん？設計する量が増えてるように見える？
キノセイデスヨ、タブン・・・。
では、EventSourcingで何を得られるのか？
どの時点でここらへんを設計するの？
Slide 26
Slide 26 text
Event Sourcingの恩恵は受けれたと思います。
● CommandとQueryの構成による関心ごとの分離
● 参照データに変更が必要な場合、EventListenerとViewmodelを追加
するというアプローチが取れる
○ REST APIにおけるV2が作りやすい
○ 変更しやすいことで、Query周りの設計のコスト削減ができる
■ テーブル含めたリファクタリングがやりやすい
この構成で解決できたこと
Slide 27
Slide 27 text
Eventを再生する処理とその先の参照テーブルを新しく作成して切り替えま
す。EventSourcingではなくても可能ですが、比較的楽にできるのが強みだと
思います。
テーブルのリファクタリングについて補足
Slide 28
Slide 28 text
もちろん、いいことだらけではないです。
● Event Sourcingの課題である設計の難しさ
○ 普通にCRUD作るより難しい
○ 開発のコストがかかる
● システム全体の正しさの担保が難しい
○ 特に1つのユースケースでイベントが複数発生する場合
○ よくわからないけど動いてる、コワイ！なところはたまにある
● オーバーエンジニアリング感
一方で課題も・・・
Slide 29
Slide 29 text
悩みを
● Command実行時に現在の状態を参照したいときどうするか
○ EventStore参照はコストが辛い
○ ViewModel見るのは依存関係的に辛い
● Listenerでエラーが発生したらどうするか？
○ 今回は全部ロールバックできるが、非同期とかにしていた場合は・・・
設計時にも悩み・・・
Slide 30
Slide 30 text
EventSourcingの理想は素晴らしいと思う反面、現実的にはある程度の抜け
道が欲しいケースはしばしばあります。
「ちょっとデータ登録失敗したから裏でSQL流して直してくれない？」みたいな
ケースは対応し辛いです。
EventSourcingのルールに従うのであれば、補正Eventを登録するというア
プローチになります。
理想はわかるけど・・・！
システムは改ざんしたい
Slide 31
Slide 31 text
あくまで母数1の感想です！
今の課題というよりは将来への投資という印象。重すぎるアプローチで、開発
生産性は犠牲になってる気がする。もちろん、EventSourcingを軽量で上手く
回しているところもあると思うが・・・。
難易度は高いためコードを理解するのに時間がかかる。多分、プロジェクトに
参加してからパフォーマンスを発揮できるまでは厳しい。
でも助けられたところも多くある。
EventSoucingを実際にやってみた感想
Slide 32
Slide 32 text
まとめ
Slide 33
Slide 33 text
EventSourcingが出た当時に比べれば資料もライブラリも増えてきました。
Javaで実装する場合も、Spring Modulithを利用すればいい感じに実装でき
ると思います。
AIに尋ねれば色々教えてくれます。スライド作成時、Claudeさんに色々質問し
ましたがいい感じに答えてくれます。
情報は十分にあるため、始めるにあたって情報不足で詰まることはないと思い
ます。
Event Sourcingは難しい、けど楽しい
Slide 34
Slide 34 text
プロジェクトの技術選定する立場でEventSoucingを採用するかを問われた
ら、この辺りを考慮したらいいと思います。
● 自分たちが作ろうとするアプリケーションとマッチするか
● チームに技術力と学習する時間は確保できているか
● 工数はちゃんと合意できてるか
● 運用面で発生する課題に立ち向かう覚悟はあるか
技術選定するにあたって多角的な視点を身につけられたのはプラス。（昔だっ
たら飛びついてたかも・・・！）
とは言え、気軽に始められない
Slide 35
Slide 35 text
エンジニア人生の中で、Event Sourcingに携わることは少ないかもしれない
です。
ただ、エンジニアとして使える武器として持っておくことは損はないです。Event
Sourcingを導入せずとも、思想やアプローチが問題解決の役にたつケースは
あるはず。
１エンジニアとしてはとても楽しかったですし、大きな学びを得られたと思いま
す。
最後に
Slide 36
Slide 36 text
ご清聴ありがとうございました！
Slide 37
Slide 37 text
● Eventを再生する処理がViewModelにある未来のデータを参照してしま
い、再構築ができなくなったケース
● Event自体を変更・無かったことにしたい場合
○ 金融で検討したときあったケース
● 今のアプリケーションでは発生しないが、大量のデータを処理するバッチ
系の処理
○ これも金融系
○ 例えば給料日の反映処理
入り切らなかったネタ
Slide 38
Slide 38 text
● 監査ログとか履歴は副次的な効果なので、それ目的に導入するのは
ちょっと違うと思う
○ 別にEventSourcingじゃなくてもできるよねー
● 途中から入れるのは辛いけど、スモールスタートに向かないのが厳しいと
ころ
● 全部イベントにするのが理想だけど、多分現実的には厳しいよねー。
入り切らなかったネタ