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

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

この段階的に進めていくためには、
【同期通信かつアトミックなサーガ → 同期通信かつ結果整合なサーガ → 非同期通信かつ結果整合なサーガ】
という風に、アーキテクチャを【※段階的に可逆性を担保させながら】進化させるメカニズムを抑えておく必要があります。

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

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

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

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

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

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 を題材に深堀りして解説します。