株式会社ジェイテックジャパン CTOの高丘 @tomohisaです。2024年9月17日に吉祥寺.pm36で登壇をする際にイベントソーシングに関するアンケートを実施しましたが、この記事でその集計を公開します。
アンケートの詳細については以下の記事で説明しました。よろしければご覧ください。
またアンケート第２弾では良い点と悪い点についてアンケート結果をまとめています。
またアンケート第３弾では、成功の鍵についてのアンケート券っかをまとめています。
この記事では、イベントソーシング・CQRSにおいてフレームワークやライブラリを使用することに関してのご意見をまとめます。
フレームワークの使用に関して
質問：イベントソーシング・CQRSを行うにあたって、自分たちで全ての実装を作ることと、フレームワーク、ライブラリを使うことについてどのように考えておられますか？
まとめ：フレームワークの使用に関して
フレームワークの使用に関して イベントソーシング経験者の声
本当は自分たちで作った方がいい。全てコントロールできるので。でも、最近のフレームワークは自分たちで開発したらすごく時間がかかる機能があるので、フレームワークから入るのは良いと思う - tomohisa
原則的に、認知負荷を下げるためにフレームワークやライブラリを使ったほうがよいと思います。 - かとじゅん
"その言語にライブラリ等あるなら積極的に使った方がいい。
小さく始めるなら自前で作ってもいいが、どこかでレールに乗った方がいい。
完全にフルスクラッチするならイベントソーシング・CQRSを一定わかっていないと
中途半端なものになってしまう。
イベントソーシング・CQRSに限らないことではあるがコレらはシステムの構成にもかなり影響を及ぼす取り組みなので慎重になったほうがいいと思っている。 - 群馬の民"
フレームワーク、ライブラリ等は楽できるところは楽した方がいいと思います。CDC併用が一番楽に導入できると思います - ytake
分散システムならではの落とし穴があるため、フレームワークやライブラリを使うことを推奨 - なるせ（nrslib）
難易度や実装コストを考えると自分たちで一から実装は考えづらい - 社内のマネージャー
自分たちで全てを実装するのは現実的じゃないと思ってます - kazu_kichi_67
"自作か他作 -> 他作
・ 特有の要件がなければ自分たちのコードを増やしたくない
FWかクラウド系か
・ここはクラウド系しか触ったことがない。（実務での運用ではなく、個人で触っただけ）楽だけどトレーサビリティなどに難あり？ - よだ"
インフラレイヤーにそのインフラ用のライブラリを使うくらいで、それ以外でフレームワークやライブラリの必要性を感じたことはない - 夕暮おこは
使えるライブラリがある前提でES+CQRSを採用する - LDDDはいいぞ
"私は「自分たちで全ての実装を作る」方針のプロジェクトを経験できたのですが、機能やデータによってはイベントとして扱うのが冗長であったり、イベントとして扱いたくはあるけどパフォーマンスは求められないような場合があり、その場合の簡単VerのCQRS/ES(メンバーが慣れたやりかたに一部戻すイメージ。イベントストアをRDBMSにし、パフォーマンスのために結果整合性にしてたところを、スナップショット作成までトランザクションの中でやってしまったり、イベントの発火を監視せずに普通に後続処理を呼んでしまったり)をやったのですが、これは結構手応えがよかったのでそういった「ちゃんとCQRS/ESをやるほどではないけどエッセンスだけもらいたい」場合だけフレームワーク/ライブラリを使わない選択をするのもありだなと思いました。
簡単VerにすることでCQRS/ESのメリットを手放すよう思えます。しかし、ドメイン型にコマンド型を引数として渡したり、結果をイベント型として受け取ったりするのは型と実装量が増えるのがありつつも、これらを実装するときにモデリングの時点でちゃんと考えきれてなかったかも？と、イベントストーミングでやるはずだった部分の落ち穂拾いみたいなことが自然でき、CQRS/ESを学んだだけだった時点ではわからなかった、定性的？なメリットがあるように思えました。
長くなりましたが、真にボイラーテンプレートなのであればフレームワーク/ライブラリを使うべきだと思いますが、こういった経験を体感してしまったのでどちらが良いと明言しづらく、やはり機能やデータやメンバーによってケースバイケースであると考えています。 - かきあげせいろ"
あまりやりたいとは思わない - qsona (発音: kyu-sona)
非同期メッセージングによる結果整合性、メッセージの順序性、コマンドの冪等性あたりに技術的な難易度を感じるため、ここはライブラリのサポートがあると嬉しいです。また、スナップショット機能もサポートがあるといいなと思います。 - @memetics10
"私は普段Rustで開発をしていますが、どうしても最近の言語なので基盤がないです。
なので自作していますが、ぶっちゃけ非常に辛いです。遠慮なくES+CQRSの相性の良いフレームワークやAkkaやProtoActor等のActorModel系のライブラリに頼るのが無難な策だと思います。 - リシェラ"
あるものは積極的に使いたい - (匿名)
ドメインが依存しなければ構わない - しょーだい
組織の状況による。結果的に、現状は（先の言語の選択のところで書いたとおり）マネージドサービスの力を借りる形での簡易的な実装を選択している - (匿名)
イベントソーシングは複雑なため、すでに優れたフレームワークやライブラリがあるならそれを利用したほうが良い。 - (匿名)
既存フレームワークを使うと有償になってしまうことも多いことから現在は独自実装しています。 - たかさん
基本的には、定評のあるフレームワークやライブラリを使う方が費用対効果が高いと思う。 - masuda220
実装自体は誰が作っても大きく変わることはない気がするので、良さそうなライブラリがあれば積極的に使いたい。フレームワークやライブラリなら汎用的なのか、大規模向け、中小規模を想定しているのか明示されていると助かる。コアは薄め、テストのサポートやDBの選択をプラグインできるとうれしい。 - (匿名)
フレームワークの使用に関して イベントソーシング未経験者の声
"イベントソーシングやCQRSが必要になるということは、ある程度規模のある開発となる認識のため、開発者が情報キャッチアップしやすいフレームワークやライブラリを使うようにしたいです。
または、フレームワークやライブラリを独自拡張（ラッピングなど）して利用用途を限定したりすることで複雑さをなるべく排除して導入出来るようにしたいです。 - (匿名)"
基幹になるレベルであれば自前で用意したい気持ちがあります。 - @shotanue
Cluster Sharding を考慮すると、Akka 以外の選択肢が今はわかっていないです - (匿名)
導入がしづらい理由の1つに実装コストが高い問題があるので、フレームワークによって改善されるなら良いことだと思います。 - 非匿名希望
まずはフレームワークを使ってやってみる - (匿名)
イベントソーシングについては、イベントからビューを作る際の計算コストやディスクI/Oのことを気にする必要がある(キャッシュを用意しておくなど)ことから、実装難易度がある程度高いような印象を受けたので、仮に業務で採用する場合はフレームワークを積極的に利用したい。この場合は業務で利用しているプログラミング言語でそのような環境が存在しない場合は、導入の障壁になりそうと考える。 - @piyorinpa
"要件による、としか言えないですが、単一システム単一業務機能であれば作り込んだ方がいいと思います
プロジェクト内で複数の要件に対する複数の実装が必要であれば、フレームワーク、ライブラリに乗るべきです - Magnolia.K"
要件に沿うならライブラリを使っていいと思う - しがあきとし
採用している技術スタックによって考慮すべき観点も違うと思うので、まずは自分で実装してみて、型が見えてきた時点でフレームワーク化 or 既存のものを検討するで良いのかなと思っています - ＠ryuke
"https://learn.microsoft.com/ja-jp/azure/architecture/patterns/event-sourcing
MSが公開してるドキュメントを参考にしながら自分たちで実装したほうが自社で抱えている問題に深く刺さる気がしています。
ライブラリは薄いのがあれば採用したい感はあります。 - u-na-gi"
"既に既存の実装があるのであれば巨人の肩に乗りたいが、あまり見かけることがない。
自分たちで実装を作るしかないのかな？と思ったりしている - かろっく"
まずは典型的なパターンをカバーするフレームワーク、ライブラリから導入したい。フルマネージドサービスがあるならそれも可 - (匿名)
コストがかかる、設計が難しい、それなりに知識が必要で合意に至るまでに時間がかかりそう - (匿名)
まとめ
色々な意見がありますね。
後で気がついたのですが、使ったことのあるフレームワークをかけるところを作ればよかったと後悔しています。
Sekibanはフレームワークですが、個人的には自分で基盤を作れるなら作った方が良いと思います。
ただ、Sekibanを作る過程でも最初に作ったフレームワークから今のフレームワークでは大きく変わっていて、いまでは認知負荷が下がり、理解しやすい書き方に少しづつ近づいていると認識しています。単一プロジェクト内の基盤コードであれば絶対修正しない多くの点を修正していることからも、すでにいろいろな問題に直面して解決してきたフレームワークを使うのは悪くないと思います。
ただ、フレームワークを使っても開発者の学習や理解が必要というのはありそうなので、少しハードルが高い気はしますね。
私たちの作っている C#によるイベントソーシング・CQRSフレームワークSekibanはこちらです。（Starしてくださるととてもうれしいです。）
アンケート第５弾では、イベントソーシングやCQRSに関する質問をまとめています。
吉祥寺.pm36の参加レポート及び、登壇のスライドと練習動画はこちらです。
Discussion