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

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

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

履歴が残っていなくて困った…
イベントソーシングになっていれば…

そう思っても、ステートソーシングに慣れてしまっていると、イベントから状態を復元するメリットややり方が想像しづらいことがあります。

そんな時に、HTMLとJSだけでで、ペライチで作れるイベントソーシング電卓はいかがでしょうか？

このセッションではイベントソーシングの概念を理解して、チームに紹介するために作ったイベントソーシング電卓を紹介します。

機能

• 四則演算
• 押したボタンを記録する
• イベントログのコピー
• イベントログから計算を復元する

電卓が実際に動くのを見て、イベントソーシングに親しみましょう！

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

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

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

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

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

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

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

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

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

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

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

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

ベントストーミングはビジネスプロセスを可視化し、コンテキスト境界を見定めるのに有効な手法です。

本ワークショップでは、Miroを使って実際にイベントストーミングを体験します。
基本的な記法を学んだ後、具体的なテーマをもとに手を動かしながら図を描いていきます。
その場で出てきた疑問はリアルタイムで解消しますので、初めての方も安心してご参加ください。

※参加にはPCとインターネット回線が必要です

概要

背景

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

本セッションの内容

1. なぜESを選んだのか

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

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

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

想定読者

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

CQRSを取り入れる際、コマンドモデルとリードモデルとの連携はどう考えましょう？

いきなり非同期にしますか？　２つのモデルは、異なるネットワークセグメントに配置しますか？
たしかにそれだと、セキュリティなどの観点から見たら、爆発半径が限定され安心かもしれません。

でもそれだと、チームはCQRSという1つの複雑さ以外にも、
・データラグによるUX低下という問題への対処
・コマンドモデルとリードモデル間のコントラクトが不確実
といった、複数の複雑な概念に向き合わなくてはならなくなり、学習効果も低下します。

そこでセキュリティリスクを意図的に許容し、「同期から始め、徐々に非同期へ」という、
段階的にコマンドとリードを配置モデル上でも分離するためのプロセスや注意点をご紹介します。

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

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

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

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

本ハンズオンでは、TypeScript を用いた仕様駆動開発（Specification-Driven Development）と CQRS/ES（Command Query Responsibility Segregation / Event Sourcing）を実践的に体験します。利用する OSS は登壇者が公開している cqrs-es-spec-kit-js、event-store-adapter-js、および仕様駆動開発ツール cc-sdd です。これらを用いて「仕様 → コード生成 → コマンド実行 → イベント永続化 → 状態再構築」までを一貫して試せる開発フローを学びます。TypeScript の基礎と簡単な非同期処理の理解があれば参加可能です。Blogリンクに読んでおくとよい資料を記載しました。

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

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