勢いでカンファレンスを開催！
CQRS ESカンファレンス爆誕しましたのでよろしくおねがいしますー
— yuuki takezawa@ytake (@ex_takezawa) 2024年10月11日
CQRS/ESに関する質問や疑問も直接聞くことができたり、
ドメインイベント活用などについても知ることができます！
当日スタッフも募集しておりますー！
https://t.co/6SKgAKssLm #cqrs_es_con
ということで
2024/12/21にCQRS+ESにフォーカスしたカンファレンスを開催しました。
登壇されたみなさま、LTに申し込んでいただいたみなさま、
当日スタッフのみなさま、そして来場者のみなさま
本当にありがとうございました！
当日は200名超えに皆さんに参加していただき びっくり！
個人的には以前ヨーロッパで開催されていたEventSourcing Liveに参加した際の内容が非常によく、
同じようなモデリングや技術に取り組んでいる身としては
国内にエッセンスをどうにかして持ってきたい と考えていました。
国内ではCQRS+ESを軸にしたイベントは存在せず、
国内で実践する方も少なくなかなか採択されにくいということもありつつ、
DDD関連のイベントでもCQRS+ESが大きく取り上げられることもなく・・
DDDヨーロッパに負けたくない！などいろいろ考えながら、
技術に特化したものをやりたい！という欲が達成できて非常に満足です。
感無量！
全体的な流れとしても皆さんのトークをつなげると割とストーリー的なつながりになっていて、
Ask the Speakerで細かいことも聞けたりこれが無料なのか・・と主催側もびっくりでした。
やってて思いますが豪華過ぎませんかねこれ・・・
当日のトーク
資料はコンテキストが多分伝わらないと思いますので、公開は今のところ考えていませんが
自分からは「なぜCQRS+ESに取り組むのか、実際にはどうやるのか？」というのをテーマに
お話させていただきました。
CQRS+ESはソフトウェアのレイヤだけで語られることも多少なりともあり、
ドメインイベントがおまけのような扱いを受けることも多くあります。
またドメインイベントの内容がidだけだったり、
伝播させるためだけの扱いであったり本来の意図したものと違う形で扱われることもあったりします。
（自分も以前端折ってイベントの伝播が主のような伝え方をしてしまったのもありますが・・）
ソフトウェアのレイヤー構造や処理の観点だけでは複雑になってしまい、
本来意図しているものからかけ離れてしまうことが多くなってしまいます。
イベントストーミングを行うことでドメインイベントを明らかにしたうえで、
ドメインイベントを中心に物事が派生していく、
ドメインイベントの積み重ねがみなさんが扱うデータであり、
その積み重ねを様々な方向から再解釈することが最大の価値ですよ、
という内容が伝われば！と思っています。
参加できなかった方のために簡単に補足すると・・
例えば自販機の設計や状態を考える場合はどのようにしますか？
多くの方は自販機のタイプやアイスクリーム（商品）、在庫数、価格などを
イメージしながら “現在の状態”をDBに保存する 設計を思い浮かべると思います。
しかし、
イベントソーシングの考え方では「アイスクリームが製造された」「補充された」「売れた」といった
ドメインイベントの積み重ねをシステムの中心に置きます。
たとえば「アイスクリームが売れた」というイベントが積み重なれば、
どの味がいつどのくらいの本数売れたかが追跡できますし、
「補充された」というイベントを見ればどのタイミングでどれだけ在庫を追加したかが分かります。
そして、これらのイベントを過去から時系列で集計すれば、
「今の在庫」「売上傾向」「人気フレーバー」などを自在に割り出せます。
もし新しい分析項目が増えたとしても、
過去のイベントを再生すれば対応できる柔軟性があります。
従来のように 在庫数 や 価格 を直接データベースのカラムに持って更新し続ける方式でも目的は達成できますが、
イベントによる履歴が明確に残っていないと
「なぜこの在庫数なのか？」「いつからこうなっているのか？」といった
過去の経緯を再現しにくい 場合もあります。
CQRS + ES のようにイベントを蓄積するパターンをとることで
ドメインイベントというビジネス上の事象の変遷をそのまま保存し、
あらゆる集計や再解釈が可能な設計になっていきます。
もちろん多くの場合ではそこまでしなくても・・
というのはあると思いますし全てで導入する必要はありませんが、
うまくエッセンスを活用することはできると思います。
もちろんアイスクリームを購入しに来た人にとっては
現在購入したいものが購入できるかどうか、予算で購入できるか、
といった今の状態がほしいのは間違いありません。
ですがDX文脈やプロダクトの観点ではどうでしょうか？
現在のビジネスを維持するだけでなく変化に対応することも、
もしくは自ら変化を起こしていく場合には自分たちのドメインに大きく活用できるはずです。
そしてこれらをうまくアプリケーションに落とし込む場合に
アクターモデルを活用するのも一つの選択肢になりますよ、
ということで少しだけProto Actor利用例もお話しました。
（アクターモデルを採用しないと難しい、と言わないように反省しています・・ｗ）
参加者の方もDDDカンファレンスの様なイメージで参加されていたり、
そこからの応用のような感想を持たれたり、
密かに意図した形で伝わっていたのも非常に良かったなぁと思っています。
少しでもCQRS+ESに興味を持っていただければ幸いです！
また機会があればどこかで同じような話をしようかなと思います。
ちなみに従来の方法にGAなどを使えばいいじゃん、ももちろんありますし
多くはそうなっていると思いますが、
その結果データ基盤を作ったり傾向分析のために色々なシステムを更に作らなければいけなくなったり、
実は複雑にしているのは自分たちの従来の設計なのかもしれない、という点に注目するのも一つかなと思います。
開催までの話
もともとのきっかけは Object-Oriented Conference 2024
このときにちょうど
成瀬さんがイベントストーミングについて、
かとじゅんさんがCQRS/Event Sourcingのハンズオン、
自分がメッセージングのアンチパターンのトークをしていました。
これらはCQRS+ES・ドメインイベントを軸にそれぞれ違う方向からのトーク
その時の懇親会で
「CQRS+ESにチャレンジすれば見えてくるものも大きいのでなにかやりたい」、
的な話をしたのがきっかけでした。
それから日程調整等をしながら取れたのが12/21
翌日にPHPカンファレンスがあるけど まぁなんとかなるでしょう！
ということで日程が確定しました。
成瀬さんもめちゃくちゃ忙しいのに色々対応してもらってありがとうございました！
やるのであればtomohisaさんにSekibanの話をしてもらいたい！
ということで２ヶ月位前に連絡して快諾していただき（急にすいませんでした・・ｗ）、
色々準備しつつ開催の日を迎えました。
忙しい人達が企画と準備などをしつつ登壇する、という割とハードな期間でしたが
結果開催して非常に良かったなぁと思いました。
振り返ってみると、
Laravel JP Conference2019を開催したときのノリとほぼ同じような感じでしたね・・
一瞬東京でLaravel JPカンファレンス企画しようかと思ったんですが、
— yuuki takezawa@ytake (@ex_takezawa) 2018年2月21日
時間にあまり余裕がないので数人で興味ある方やってみませんか？
次回はありますか？
今回やってみて様々な方から一回で終わるのは勿体ない！
めちゃくちゃ楽しかった、内容もめちゃくちゃ良かった！
2年に一回くらいやってもいいのでは？！
CQRS+ESを国内にも伝えていくには継続してもいいのかも？などなど色々いただきました
しかしながら・・・
残念ながら・・・
来年どこかで必ず２回目を開催します！
しかしながら、今のところスポンサーなしカンファレンスということもあり、
時期や場所については色々考えていきたいと思いますので今しばらくお待ち下さい。
あとはぜひチャレンジして開催時に応募してください！
登壇駆動だと少しばかり難しいテーマではありますので是非どうぞ！
実践時に疑問点などがありましたら是非Xやmixi2などでもポストしてみてください。
きっと誰かが（おっと
