AI時代の開発において、AIをいかに活用するかは避けて通れないテーマです。

ビジネスの振る舞いは「イベント」として捉えると表現しやすく、イベントストーミングはその可視化に有効な手法です。
そして、イベントストーミングで描いた図をAIによってコードに変換する際、CQRS+ESの構造はトランザクショナルな処理と比べて図の意図を正確に反映しやすいです。

本セッションでは、イベントストーミング図からAIでコードを生成するデモを行い、その際に必要な準備や工夫についてお話しします。

LLMを使って開発しているとLLMに与えるガードレールの設計によりコード品質が大きな影響を受けます。純粋なインメモリのデータモデルと関数でまずドメインを設計してからそれをイベントソーシングフレームワークに載せることにより、LLMも多くのコードを参照せずにモデルの設計に集中することができます。

この手法において、個人的に上手くいった、Jeremie Chassaing 氏が // thinkbeforecoding ブログ"Functional Event Sourcing Decider"などで説明している、Deciderパターンの実践方法について解説します。その上で、SekibanフレームワークがDeciderパターンを使用して作成したドメインをもとにイベントソーシングを実践しているかも解説します。

コマンドモデルとリードモデルは、段階的に分離していくのが、アーキテクチャの可逆性を担保させる意味でも重要です。

①最初は、論理的には分離されているものの、物理的には１つのDB上でアトミック性を担保する。
②そこから、それぞれに異なるデータ品質要求が来ると、物理的に異なるDBにするものの、通信は同期で連携。（結果整合かつ同期通信
③そこからさらに疎結合化が進むと、両者のモデルは通信も非同期で、完全に独立した状態になります。

この段階的に進めていくためには、アーキテクチャを【※段階的に可逆性を担保させながら】進化させるサーガのメカニズムを抑えておく必要があります。
（そこでアンチパターンの紹介も盛り込み予定）

このメカニズムを用いながら、より安全にコマンドとリードを分離していく工程をご紹介します。

CQRSの真価を引き出すためには、ドメイン駆動設計の実践が必須というお話をしようと思います。

CQRSを生んだGreg Youngの出発点は、ドメイン駆動設計でした。
ユーザーの意図(=コマンド/イベント)をモデルに取り入れることで、 結果的にCQRSはシステムにスケーラビリティをもたらします。
一方で、ドメインを見ずにアーキテクチャパターンだけ適用してしまうと、本来不要な複雑さを生んでしまうかもしれません。

このセッションでは、まずは現実のドメインに焦点を当て、コマンド、イベント、集約、ポリシーといった概念をモデリングに活用することで、システムに一貫性と柔軟性の調和がもたらされる例を紹介します。

そしてその帰結として、CQRSやイベントソーシングといったアーキテクチャパターンがどのような領域でROIに見合うのか、どのように実装すると効果的か、自身の失敗と成功を交えて考察します。

概要

背景

ビットキーというスマートロックサービスを提供するスタートアップで、創業初期から現在まで約7年間開発に従事。様々な試行錯誤と失敗を経験し、最終的にES(Event Sourcing)を選択するに至った。スタートアップという泥臭く開発を推し進めていた状態から、どのような変遷を経てESに至ったのか、現場目線での発表をします。

本セッションの内容

1. なぜESを選んだのか

   • 7年間の変遷と失敗事例、そして学び
   • 解決策としてのESへの期待

2. 既存サービスへの段階的適用

   • CQRS + ESへの期待と優先度の判断
   • スモールスタートの具体的なアプローチ
   • 実践時の課題と対策

想定読者

• ES？なにそれ？おいしいの？...って方
• ESをどうやって始めていけば良いかわからない方

イベントソーシングについて、とくにイベントの価値についてお話しようと思います。

運用してて以下のようなこと事ありませんか？

データ分析するのにアプリケーションで主に扱うDBより、クライアントアプリのログが主になっている。そして欠損が免れない。

お問い合わせ対応をするときにアプリケーションログをみるしかない、DBにあるデータだと過去が遡れない。

新機能のために既存機能について分析したいけどDBはなにも教えてくれない。

私がお仕事で対面しているアプリケーションはまさにこの状況でした。

私はこの状況を改善するチャンスがありイベントをアプリケーションに取り入れてきました。

それはやがてイベントソーシングへと繋がり、自然な非同期処理への導入、CQRSの一歩手前へと歩みを進めてきました。

動いているアプリケーションへイベントを取り入れたことによる変化について話をしようかと思ます。

この問いは、CQRS/ESを触った人なら一度は悩むポイントです。

CQRS/ES のコマンド側をオブジェクトモデルで実装することは可能です。しかし、イベント書き込み時のロック競合、同時更新の制御、分散環境での一貫性維持といった課題に直面します。これらを根本的に解決する仕組みが「アクターモデル」です。集約をアクターとして実装し、クラスタシャーディングによって「1集約＝1実体」を保証すれば、ロックレスかつ逐次的に状態を管理できます。さらにメッセージ駆動により時間・場所・障害からの分離が得られ、リアクティブシステムとしてスケールと耐障害性を自然に実現できます。

近年注目される DCB（Data Consistency Boundary）との比較も交えながら、なぜコマンド側にアクターモデルが適しているのかを、Pekko/Akka を題材に深堀りして解説します。