RailsでCQRS/ESをやってみたきづき

このスライドでは、RailsでCQRS/ESを実装する際のポイントやメリットについて解説しています。

イベントソーシングを導入することで、システムの状態変化を履歴として記録し、過去の状態を正確に再現できるようになります。これにより、バグの原因特定やデータの復元が容易になります。

また、CQRSを組み合わせることで、データの書き込み（コマンド）と読み取り（クエリ）を分離し、スケールしやすく、保守性の高い設計を実現できます。

実装の具体例として、「Rails Event Store」を活用する方法が紹介されています。ただし、いきなりライブラリを使うのではなく、まずはシンプルな同期処理のスクリプトを作成し、基本的な流れを理解することが推奨されています。

さらに、イベント登録とクエリの更新を同じトランザクションで行わないことや、ActiveSupport::Notificationsを活用した同期的なPub/Subの実装方法についても解説されています。

Transcript

1. RailsでCQRS/ES をやってみた気づき 鈴木まー　 イベントソーシング・CQRS勉強会 #1
2. 自己紹介 鈴木まー Railsの特性を活かしつつ、拡張性と 保守性を両立する設計を探求中。 DDDやモジュラーモノリスを実践し てきて、Rails + クリーンアーキテク チャのLT経験あり。最近はRailsに CQRS/ESを適用する方法を模索し てる 千葉県で設計に ついて登壇を している 船橋.dev 東葛.dev
3. なんで　 RailsでもCQRS/ESを するのか？
4. なんで　 RailsでもCQRS/ESを するのか？ イベントソーシングを おこないやすくするため
5. 履歴を保持することで 過去の状態を 正確に再現できる 外部システムとの連携時も 状態を 追跡しやすく、再現性が高まる コマンドとクエリーを分離することで スケールしやすい設計が可能になる イベントソーシングのメリット
6. イベントソーシングは、プログラミング言語 を問わず、システムの過去の状態を正確に再 現できる仕組み Railsでも適用でき、特にコアドメインが複 雑なシステムでは、データの履歴を追跡しや すく、バグの特定や状態の復元が容易になる Railsでもイベントソーシングは有効
7. 実際に鈴木がRailsのプロダクトで CQRS/ESをしてみると良かったなと 思った過去の事例
8. 実装をした機能 UberEatsなど、複数の配送サービスAPIを統合し 配達者にとって最適な配送手段を選択して自動手配 するサービスを開発する 仕様 1. ユーザーが配送条件を入力 2. システムが最適な配送サービスを選択 3. 選択した配送サービスへ正式な注文を送信 4. 配送の進行状況を記録
9. 配送サービスAPIは独自に開発してもらっている ものだから不安定 開発してもらたAPIがバグでエラーになったのか、 プロダクト側で失敗した理由かがわからない 「現在の状態」はわかるが、いままでどのよなことを してその状態(配送中とか)になったのかがわからない

 システムを動かすためには作成してもらった APIを動かす必要があるがその連携がたいへん
 APIを作ってもらった会社に連絡をする必要がある 問題点
10. 複雑な機能は多くのプロダクトで発生し、 イベントソーシングはそれを適切に管理する強力な手法 システムの状態変化を履歴として記録し、 過去のプロセスを再現できる エラーの発生箇所や原因を正確に追跡できる ビジネスルールの変更にも柔軟に対応し、長期的な拡張性を確保 イベントソーシングを使う事によるメリット
11. イベントソーシングは 重要なのわかったけど、 実際にRailsでどう 実装していくの？
12. DDD/EAが盛んなEUで導入されている リポジトリのStar数が1.4k 機能面 Hexagonalアーキテクチャで外部依存を分離し、 ActiveRecordのコールバックを排除。 疎結合なイベント駆動の連携・副作用の分離・完全な履歴管理により、 拡張性の高い、スケールしやすく安定したシステムを構築しやすい https://railseventstore.org/ Rails Event StoreというGemがある
13. ESについて理解していない状態でこのライブラ リーをしようするのはおすすめしない 挫折する理由になってしまう
14. 従来のCRUDとは異なるパターンのため、単にライブラ リを使うだけでは、内部で何が起こっているのかを正し く理解することは難しい。 このライブラリを利用する場合でも、CQRS/ESの独特 な実装パターンを把握し、EventStoreやEventBusなどの 仕組みを理解することが重要になる。
15. 難しいので、挫折しそうだけど、最初はなにを じっそうするといいのか？
16. 難しいので、挫折しそうだけど、最初はなにを じっそうするといいのか？ 最初は同期処理のスクリプト(rake)でユーザー からの入力を受け取りそれをイベントとして記録 するだけのものを作るのがおすすめ
17. 同期処理がいい理由 通常CQRS/ESは非同期処理で実装をするが、普段はRESTAPIなど の同期処理のプログラミングスタイルをしている人にとっては、 何がいつ実行されているのかが分かりづらくなる。 また非同期処理は実装が複雑になりやすい。 そのため、まずは同期処理で動作を理解する
18. スクリプトがいい理由 Webアプリとして作ると、フロントエンドやAPIの設計が絡み、 CQRS/ESの本質を理解する前に「どうリクエストを受けるか？」 といった別の課題に直面しがち。 スクリプトなら、「コマンド → ハンドラー → イベント発生 → 状 態更新」だけにフォーカスできるため、CQRS/ESの構造を最小限 の実装で学べる。
19. CQRS/ESの簡単なスクリプトの例
21. Railsで実装するとき にしっておいたほう がいいこと
22. EventStoreはActiveRecordで問題ない PostgreSQL や MySQL の JSON カラムを活用すれ ば、イベントデータを柔軟に格納できるため、普段 使い慣れている ActiveRecord で実装できる 一方で、MongoDB など普段使い慣れていないデー タベースを導入すると、新しい手法を学びながら、 さらに別の新しい技術にも適応する必要があり、挫 折しやすくなる
23. 従来の実装では、データベースの処理は通常、一つのトラ ンザクションにまとめてSQLを実行する しかし、CQRS/ESでは、イベント登録とクエリーの更新 を同じトランザクションで行うのは 一貫性の問題が発生す るため、明確なアンチパターンとなる イベント登録とクエリーの更新を同じ トランザクションではしていはいけない
24. Railsで同期的なPub/Subをするには ActiveSupport::Notificationsがつかえる 通知 Publish Subscribe
25. まとめ RailsでもESで実装をするとコアドメインの複雑な機 能の実装とかの重要なデータに関する部分の実装は 役に立つはず　 いきなり、ESのライブラリーを使うと何を実装して いるのかがわからないまま実装をしてしまう 最初は、簡単な同期的更新をするスクリプトを自分 で作成してどのように実装をするのかを理解する
26. ご清聴ありがとう ございました