コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

『CQRS+ESカンファレンス』に行ってきたよメモ

行ってきたメモ

『CQRS+ESカンファレンス - connpass』に参加してきたのでそのメモです、

各発表の感想

※資料スライドは見つけたら貼ります。

ドメインイベントで描く未来: CQRS/ESが変えるシステムとDXの可能性

スライドは公開予定ではないということなのでブログを…

CQRS+ESカンファレンス(2024)を開催しました - ytake blog](https://blog.ytake.jp.net/entry/2024/12/24/090000)

感想

  • CQRS/ESをなぜ採用すべきか、というところと基本的な考え方を駆け抜けてサマリで説明
  • イベントを記録すれば後に違う角度で見たくなったときにも見えるという話や、機能的結合や時間的結合の話など改めて重要フレーズピックアップしたいような話でした。
  • 「データはイベントの蓄積である」という考え方をどれだけ持てるかが重要という話は頭に入れながら色々作るときに考えるとよいのかなと思いました。

関連リンク

2年間の実運用を経て振り返るイベントソーシングの実際

感想

  • 中小規模システムのためのCQRS+ESのフレームワークであるSekibanの紹介
  • 大きなものでないと恩恵を受けられないのではないか？というところへの1つの解になりそうな話でした。
  • 作ってみると遭遇しそうな疑問に関してのQ&Aはかなり後続で続く人たちのためにもなる情報に思えました。

関連リンク

いろんな機能をCQRS+ESで作ってみたので皆で所感を見てみよう

感想

  • AxonIQを使ったEventSourcingを用いた実システム作り方
  • 題材としてはAPIサーバを取り扱い、イベントがどのように保存しされ、Queryに使われるテーブルはどのような形になるのかという話をコードを追いながら解説されていました。
  • AxonIQがカバーしている部分もあるので、細かいところが気になったが全体感の理解としては進んだ
  • 最後に紹介のあったイベントストーミングをした図からChatGPTでAxonIQのコードがある程度起こせるデモがあり、雛形作成でここまでいけるのかーという驚きがあった。

関連リンク

イベントの使い方を一度身につけてしまったら、もうそれなしでは生きられなくなるだろう

スライドリンクは公開されたら貼ります

感想

  • 既存システムでのつらみ経験から導入していく家庭のお話
  • 「イベントがほしい」というところからCQRSへだんだん行く過程のお話だったので途中で時間切れになってしまい残念
  • イベントが始点で話をすると結果としてCQRS側へ帰結するんだろうなぁと思いました。

関連リンク

アクターシステムに頼らずEvent Sourcingする方法について

感想

  • ESはアクターモデルがないとできないのではないか？というところに対してのアプローチの話
  • AWSが提唱しているモデルのよくないところを交えつつ、実績のあるKJ法（KatoJun）も紹介されていて、実装したいときの参考になりそうな内容だった
  • 練度が低くてまだうわべだけしか見えていない感じがしたので、もう少し実践的な知識をえたら見直したい

関連リンク

パネルディスカッション

ディスカッション内容

Q. 外部インターフェイスとしては何を採用しているか（REST、gRPC、など）

tomohisaさんはsekibanを使っているためRESTスタイル、鈴木さんはgRPCを利用しているという話をされていた。かとじゅんさんはCommand側はRPCスタイル、ReadモデルはRESTスタイルと使い分けの話をされており、RESTはCommandとの相性問題があるのでその形式が多いと話されていました。成瀬さんはAxonを利用しているためそのあたりはフレームワークが勝手にやってくれているので意識していない旨のお話をされていました。

Q. Protocol Buffersのプロトコルはどうやって共有しているか

かとじゅんさんは他のシステムと連携するかどうかの観点で話をされており、クライアントとサーバーどっちで主管をするか決めて、運用する旨の話をしていました。鈴木さんは単一のアプリケーションに閉じているので、専用のディレクトリを用意して運用している旨の話をされていました。

Q.複雑なシステムじゃなければCQRS+ESは不要かと思うんですが、いるいらないの基準があるか

この話においては、パネルディスカッションのメンバー全員がCQRS+ESの実践者なのでどの方も大小かかわらず使いたいという意見でした。その中で出た意見で印象的だったのが以下の話です。

  • 採用しないとCRUDな作りになるので、データベースの考慮を入れると純粋なドメインモデルとのひずみが出る。そのときに手をいれる必要があるので、それであれば最初からやっておいたほうがよい。
  • そうではないものから書き換えてみたが、書く事自体が大変ではなく、新しい概念や知識を取り込むコストが高い。
  • EUのDDD関連のカンファレンスではCQRS+ESの話が多くなるので今後はメインストリームになるのではないかと考えている。

Q. CDC(Change Data Capture)対応のデータベースじゃないと実践できないですか？

イベントの取り扱いに関して言及があり、イベントをRDBに格納すること自体は問題ないがそのイベントをどうやって取り出すかが問題になる。その際にCDCが存在しないものを使うとポーリングするなどデータベースの負荷がかかるやり方になってしまうのでそのあたりが難しい、とのことでした。また、普通のRDBにしてしまうとスケールアウトの難しさが出るなどの問題があるので、ドキュメント指向のものを使うと良いという話もありました。

感想

  • いろいろな角度でなるほどなぁと思わされれる話が多かった。
  • RESTとイベント記録に関しては確かに噛み合わせが悪い、というよりかはCreate専門になってしまうよなという気持ちに
  • ドキュメント指向のデータベースを使う利点に関してもいままであまりユースケースがわかってなかったのですがこの話を聞いて合点が行きました。

関連リンク

CQRS+ES の力を使って効果を感じる

感想

  • AWSでCQRS+ESにチャレンジしてみる話
  • 前段でかとじゅんさんが指摘していたAWSの例を使っていた話だったので見直しの話が入ったのがタイムリーな感じでした

関連リンク

イベントソーシングとドメインモデリング

感想

  • イベントを中心としたモデリングに関してのLT
  • イベントソーシングはやらずとも、イベントを記録することは念頭に置いて実装することをするのがよいんだろうな、という学びになりました。

関連リンク

使いたいから使うんじゃなく「必然として」使うCQRS+ES

感想

  • 古くからあるシステムにCQRS+ESをあてていく話。
  • 個人的にはCQRS+ESの話というよりも、組織を上げてモダナイズすることの難しさを感じた話
    • マイクロサービス化がモダナイズ化です！という話にしないと前進しなかったんだろうな…という苦労がにじみ出ていた

関連リンク

ドメインイベント増えすぎ問題

感想

  • イベントの種類がたくさん増えてしまって困った話
  • すごく実践に即した話という感じがしており、これからやる人向けへの転ばぬ先の杖的なLTでした。
  • 実際問題このあたりは勘所がないと変な方向にやりそうだな…という感じも強く受けました。

関連リンク

Debeziumを活用したRDBMSイベントソーシングの仕組み

感想

  • Debeziumを利用したCQRSパターンの作成の話。
  • 先ほどのパネルディスカッションにあったCDCがないDBへのアプローチの一例として良さそうでした。
  • ただKafkaも必要になるので考えることは増えそう…

関連リンク

全体を通しての感想

  • まったく普段遣いしない知識の話が満載でしたが、なんとなくの理解でもついていけるように配慮されていてよかったです。
    • ただもう少しアクターモデルやベースの理解があったほうが楽しめた感は否めなかったです。
  • 自分自身がRailsメインが続いていたのでCQRS+ESの考え方自体はぼんやり理解しているレベルでしたが、この機会にもうちょっと足を突っ込むといいのかなと思っています。
  • 普段の実装でもイベントを意識する事自体はマイナスに働くことがないので活かしていきたいと思います。

関連リンク