株式会社ジェイテックジャパン CTOの高丘 @tomohisaです。2024年9月17日に吉祥寺.pm36で登壇をする際にイベントソーシングに関するアンケートを実施しましたが、この記事でその集計を公開します。
アンケートの詳細については以下の記事で説明しました。よろしければご覧ください。
良いところ
質問：イベントソーシング・CQRSの良いところはどんなところと思いますか？
まとめ：イベントソーシングの良いところ
まとめ：CQRSの良いところ
良いところ - イベントソーシング経験者の声
履歴がのこる、永続化が共通化できる、データの活用が行いやすい、イベントストーミングのような設計手法も取り入れやすい。イベントドリブンでの連携を行いやすい - tomohisa
連携する複数のシステムを運用することが多い現代の開発では、そもそもイベントが蔑ろにされていると思います。APIでデータをプルするだけではなく、イベントを使ってプッシュできるアーキテクチャが必要なるし、結果的にそのほうがシンプルになると感じることが多いです。 - かとじゅん
"イベントソーシング : システム上の業務に関する出来事が自然にデータベースに集まる構造になる。イベントをトリガーに動くコンポーネントを作る際にエンジニア以外にも説明可能な語彙で設計できる。
CQRS : Command側は概念モデルへより近い実装を目指して、Query側は融通を聞かせて妥協しやすい。 - 群馬の民"
"モデルを含めてシステムが小さくなり、複雑になりにくいです
ミドルウェアを使うかどうかで全体の複雑さは多少変わりますが、近年のデータ分析やデータパイプラインなどの発展を考えても、ビジネス的な価値とも直結しやすいアプローチでもあります
HTTPの流れと別として捉えらるのでこれも良い点だと思います
何かの事象をきっかけにコンテキストやビジネスに発展するので自然な仕組みだとも思っています - ytake"
"プログラミングをしながら決定の先送りが可能：コマンドの処理を作りながらクエリのことは考えない
システム拡張の余地ができる：ジャーナルのデータを利用した別システムの構築等 - なるせ（nrslib）"
イベントソーシングについては、データ操作の監査機能、将来的なデータ活用が良いところと考えています。 - 社内のマネージャー
高い弾力性と耐障害性、関心の分離によるドメインモデルの最適化 - kazu_kichi_67
"・機能的なスケーリング
・pub/subで疎結合になるから
・pub側はイベントをpubするだけ、sub側は勝手にsubするだけで、チーム間調整みたいなことが減らせる
・readモデルを、それぞれのサービス要件にあったスキーマでそれぞれ作れる
・readモデルのスキーマ変更が比較的容易？（イベントストアからリプレイすれば良いから。やったことは無し）
・非機能的なスケーリング
・read/writeの負荷分散（ここはnewSQLでも解決できるやつ？全然詳しくない）
・分析系への連携
・現在は細かいイベントまで全てデータ収集することが基本と思われる。そうしたときに、現況のステートだけではなくイベント全てを収集することがどっちみち求められるのでは？ - よだ"
CQRS+ESを使うことというよりは、設計の段階で明示的かつユビキタス言語的なドメインイベントが定義され、そのイベントが正確に把握されて外部コンテキストに送出できることが価値だと思っている。 - 夕暮おこは
イベントソーシングはドメインの特性や処理を表現しやすい点、CQRSはリードモデルを柔軟に構築できる点 - LDDDはいいぞ
一般に語られるメリットの他に、デメリットである ストレージ容量/結果整合性/実装難易度・量 を乗り越えさえすれば、他の難易度が高い問題をほとんど考えなくてよくなり、質とスピードにも貢献していると感じれることが好きです。 - かきあげせいろ
"ドメイン駆動設計に適している
イベントが完全なログとして機能する
柔軟性が高く、スケールしやすい - @memetics10"
設計がシンプルかつ、リプレイが可能になり再現性を担保できる所だと思います。 - リシェラ
DDDとの親和性が高いところ。リードモデルとドメインモデルを分離できるところ - (匿名)
"システム間の結合が疎結合になること
システム連携を非同期に分割しやすくなるので、連携失敗の影響を抑えやすい - しょーだい"
責務の境界が明確で非同期な処理が許容される場合は、境界が明確な形ですっきり実装できるところ - (匿名)
スケールする。ドメインに忠実なコードが書ける - (匿名)
イベントに情報が集約される為、システム全体の可視性をイベントを確認することで担保できること。コマンドとクエリが同期しないことで、スループットが向上すること。 - たかさん
関心の分離の実現、結果として変化する複雑さを扱いやすくなる - masuda220
イベントソーシング→データ変更の履歴が参照できる。出来事の記録なので記録方法さえ間違わなければ後から自由に読み取りデータ構造を設定できるところ。CQRS→データが通る向きが一方向なので、データを健全な状態に保ちやすいところ。 - (匿名)
良いところ - イベントソーシング未経験者の声
"イベントソーシングに関しては、業務ロジックが複雑になりづらく、UnitTestなどがしやすそう（ロジックがシンプルになる）のが良い点だと思っています。
反面、イベントに関して経験がある開発者が身近では少なく、導入コストが高いと考えています。CQRSは永続化ストレージを分離しなくても利用でき、導入コストは低く効果が高いと考えています。
コマンドとクエリでは要件が異なり、クエリは画面などのユースケースによってかなり複雑になったりするので、リポジトリとの相性が悪く、リポジトリとは別の位置付けにした方がシンプルになると考えています。
この辺りがシンプルになることが良い点だと思っています。 - (匿名)"
リードモデルの再構築可能性、コストの低さは魅力的に思います。 - @shotanue
関心ごとが分離されるため内部品質向上に寄与すると考えます。また、過去の履歴を参照することが可能になるため、信頼性の向上にも寄与すると考えます。 - (匿名)
"ES：過去の記録に基づく要件が新しく出た時に対応できること。
CQRS：domain layer の責務は整合性担保だと考えているが、CとQでモデルが同じだと、domain layer が参照のためのコードで溢れ返る傾向がある。モデルを分けることで domain layer が責務通りのコードで凝縮されるため好んでいる。 - 非匿名希望"
1.法律の絡む業務や顧客の意思決定など、履歴が重要視される場合に使える。2.非同期的にいろいろなサービスが絡むシステムなど、サービスを仲介するデータの整合性が重要視される場合に使える。 - (匿名)
イベントソーシングの、任意時点の状態を再現できることは魅力的に感じます。 - (匿名)
CQRSを使うと、Writeは安全にしつつ、Readは柔軟に行えるようになる。 - (匿名)
イベントソーシングについては、履歴に価値があるようなデータの取扱いにおいてよくマッチしていると理解している。CQRSについては複数の集約を結合して作成するようなビューが必要な場合に読み書きの責務をうまく分離でき、それぞれに特化した選択ができるところに価値があると理解している。 - @piyorinpa
（ユーザー目線含めた）関心の分離 - Magnolia.K
イベントを追跡出来るところ、特定のポイントでエンティティを復元できる所 - しがあきとし
データの履歴が残るところ - ひろた
二律背反になりがちな「柔軟なビュー」と「データの一貫性」を両立しやすいところ - ＠ryuke
"イベントソーシングはデータの変更を全て記録できるのでマイクロサービスでどこかのデータオブジェクトが死んだときなどに復帰がしやすいかなとおもいます。
CQRSは正直そこまで深く理解しているわけではないですが、Readはたとえばスケールしたときにレプリカ読みに行くといった要件が増えたときにあらかじめ分離されていれば対応しやすいかなとは思います。 - u-na-gi"
"イベントソーシングにおいて、ユーザのドメインイベントを後から確認できるようにするのはステート永続化のやり方より抜け落ちる事実が少なくて好ましい設計のように思う。
また、CQRSについて、クエリとコマンドでモデルが異なってくるのは自然なことのように思う。 - かろっく"
データ構造が自然と履歴ベースになるので分析系と相性がよさそう（妄想 - (匿名)
"時系列でイベントが保存される
疎結合にできる - (匿名)"
悪いところか苦手な点
質問：イベントソーシング・CQRSの苦手な点、悪いところがあれば、あげてください
まとめ
悪いところか苦手な点 イベントソーシング経験者の声
とっつきにくいところがあるのかな - tomohisa
複雑度や手数が増えるところ。特にプロジェクトの初期 - かとじゅん
やったことない。状態から できるようになる。までが容易ではない - 群馬の民
ちょっとだけ敷居が高いのはあります。CDCを活用するかアクターモデルなどを導入するか、サポートしてくれるフレームワークを見つけられるかという点もポイントかもしれません。あとは絶対にリアルタイムで処理しなければならない、という考え方を持ち続けると多少向き合うのが難しいかもしれません。あとはできたと思ったものがイベントストリーミングだった、などもありますね‥ - ytake
ミドルウェアや分散システム特有の難解さが根本に存在する。この難解さがCQRS+ESと混同されていることが多い。 - なるせ（nrslib）
学習コストが高いこと、シンプルな要件の業務アプリではオーバースペックなこと、DBメンテなどの運用コストが不透明なこと - 社内のマネージャー
学習コストが高い、オブザーバビリティとセットじゃないと解析がしんどい、小さなプロダクトの初手で選択するにはコストが高そう - kazu_kichi_67
イベントストア -> read modelへのderiveでこけたとき。①トレースやリカバリが複雑そう（実運用経験は無く、イメージで言っている）②失敗の、ユーザへの通知についてサーバサイドpushが必要になる - よだ
projectionの難易度が高いように感じる - 夕暮おこは
強いて言えばActiveRecord(Pure Rails)の開発と比べて開発速度は落ちる点 - LDDDはいいぞ
CQRS/ESはデータ管理やパフォーマンスなど、コンピュータの難しい分野を相手にすることだと思うので、そもそも難しいことをしているという点が苦手意識があります。最初のハードルは高いことは悪いところだと思います。DDDとの相性の良さがCQRS/ESの良いところではありますが、そもそもDDDがハードルが高いものだと思っているので、DDDとCQRS/ESがセットだとこういったことにあまり興味がないメンバーは苦労する。 - かきあげせいろ
CQRSの定義次第であるが、例えばかとじゅんさんの定義 https://speakerdeck.com/j5ik2o/event-sourcingwojie-shuo-suru?slide=6 を参照すると、スタックごと分けるのは仰々しい (そうしなくてもパフォーマンス上等の問題が実際には起きない) ことが現実には多い。設計者が、通常の設計の範疇で、CQRS的な考えを活かしつつ、必要に迫られたら真剣にスタック分離を考える、のような登り方ができればよいが、多くの人はオーバーエンジニアリングに走ったり、定義にこだわりすぎて現実に適した設計ができなかったりする。(CQRSの悪いところではない気がしつつ、名前がついているアーキテクチャ一般の悪いところである) - qsona (発音: kyu-sona)
DB が分かれている場合、リードモデルへの反映が非同期的になること。これによりクライアントが複雑になることがある。例えば、リダイレクトしたページで最新の情報が閲覧できないことがあるので、フェイクを差し込むなどしないといけない。また、イベントソーシングは基本的に集約 id 起点でしか集約を再生できないので、名前の重複チェックをするようなケースで困る。 - @memetics10
実装が非常に難しい所、基盤がないと非常に苦労することになる - リシェラ
フレームワークやライブラリをもう少し選択肢があると良い。モジュール結合の設計が複雑になりがち - (匿名)
エンジニアのスキルレベルが低いと開発できない - しょーだい
トランザクション処理が必要になって、オーケストレーションだのコレオグラフィだのという話が出てくると、どうしても理解して実装する難易度が上がるところ - (匿名)
リプレイに時間がかかる。実装が複雑化する。 - (匿名)
実装が複雑、エンジニア教育が大変。 - たかさん
知見の共有がまだまだ不足している - masuda220
よく言われるがシンプルなCRUDならオーバースペック。データ変更履歴が必要ない場合も。ちょっと変えるだけ、というのが思っているより難しい（イベントの取り扱いを変えるという場合、過去のデータの取り扱いにも影響する）。ビューやプロジェクション組み立てが面倒（copilotに任せたい）。 - (匿名)
悪いところか苦手な点 イベントソーシング未経験者の声
開発メンバーへの教育コストが必要な点です。また結果整合を使う場合はトランザクションの境界とどこまでを結果整合で許容するか、や集約の設計が難しいなと考えています。 - (匿名)
結果整合性を採用すると思うが、異常系のフローをきちんと設計出来るかどうかが鍵になってくる気がします。 - shimabox
イベントストアにつかうwriteがスケールする運用不可の低いDB/ストレージ選定は悩みそうかなと思ってます。 - @shotanue
やはり学習コストが高いことが一番のデメリットでしょう。特に結果整合性、集約の再構築とスナップショット管理、スケールする際のライトモデル側のトランザクション管理など、学習ハードルの高い知識を多く要する印象です。ただし、ソフトウェア工学の観点では品質とスピードを向上させることに対して成長コストはトレードオフであり、ES+CQRS の学習に費やすコストは将来性のある真っ当な投資であるとも考えているため、一概にデメリットとは言い切れないかもしれません。 - (匿名)
学習コストが高いこと。環境によると思いますが、そもそもドメインイベントに馴染みが無かったり、モデルの意識自体無い方も少なくないと感じています。ESやCQRSは更にその次のステップなので、チーム開発でやる場合はメンバーに普及する難易度が高いように思います。 - 非匿名希望
1.「一旦CRUDで実装したあとイベントととしてモデリングし直す」のコストがなかなか高そう。2.データモデル変更に伴う過去データの整合性担保が大変そう。 - (匿名)
イベントソーシングは、毎回状態をイベントから復元しないといけないのか、よくわかっていない。CQRSはコードが冗長になりがち。 - (匿名)
役割を分けることで、それぞれの要件への最適性が確保できるが、必ずそこに混ざる要素が出てくるので、そこをどう整理／調整していくかまでは設計手法は答えてくれない - Magnolia.K
参考になる事例が少ない - しがあきとし
インフラ層の実装の複雑性 - ひろた
プロダクト初期ではオーバーエンジニアリングになりがち？ - ＠ryuke
イベントソーシング: コスト問題。オブジェクトの復帰などは実装が複雑になりそう、dynamoの場合１アイテム400ｋｂしか格納できないがイベントソーシングに対応するとその要件が仕様になってしまう。 - u-na-gi
イベントソーシングのフレームワークがJavaに多く、手を出しづらい。また、ステートレスなコンテナのオーケストレーションが流行している中で、ステートフルな形になりやすいイベントソーシング実装は肩身が狭いのではないか。 - かろっく
まとめ
この記事ではみなさんのアンケートをまとめてみました。
イベントソーシング経験者と未経験者を分けることにより、使ってみて感じるものと、すでに書籍などの情報で理解している点で共通している点と少し違う点がわかると思います。また、経験者の中でもシステムの規模や取り組み方の方法によって違いがあることもわかると思います。
私たちはフレームワークを作っていますが、できるだけ良い点を伸ばし、悪い点、苦手な点を減らしていけるように努力していますが、まだまだやらなければならないことがたくさんあることにも気づかされました。皆様、ありがとうございます！
アンケート第３弾では、成功の鍵についてのアンケート結果をまとめています。
またアンケート第４弾では、フレームワーク使用に関するアンケートの結果をまとめています。
そしてアンケート第５弾では、イベントソーシングやCQRSに関する質問をまとめています。
吉祥寺.pm36の参加レポート及び、登壇のスライドと練習動画はこちらです。
Discussion