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

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

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

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

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

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

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

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

機能

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

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

概要

背景

ビットキーというスマートロックサービスを提供するスタートアップで、創業初期から現在まで約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 を題材に深堀りして解説します。