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

Slide 1

Slide 1 text

RailsでCQRS/ES をやってみた気づき鈴木まー　イベントソーシング・CQRS勉強会 #1

Slide 2

Slide 2 text

自己紹介鈴木まー Railsの特性を活かしつつ、拡張性と保守性を両立する設計を探求中。 DDDやモジュラーモノリスを実践してきて、Rails + クリーンアーキテクチャのLT経験あり。最近はRailsに CQRS/ESを適用する方法を模索してる千葉県で設計について登壇をしている船橋.dev 東葛.dev

Slide 3

Slide 3 text

なんで　 RailsでもCQRS/ESをするのか？

Slide 4

Slide 4 text

なんで　 RailsでもCQRS/ESをするのか？イベントソーシングをおこないやすくするため

Slide 5

Slide 5 text

履歴を保持することで過去の状態を正確に再現できる外部システムとの連携時も状態を追跡しやすく、再現性が高まるコマンドとクエリーを分離することでスケールしやすい設計が可能になるイベントソーシングのメリット

Slide 6

Slide 6 text

イベントソーシングは、プログラミング言語を問わず、システムの過去の状態を正確に再現できる仕組み Railsでも適用でき、特にコアドメインが複雑なシステムでは、データの履歴を追跡しやすく、バグの特定や状態の復元が容易になる Railsでもイベントソーシングは有効

Slide 7

Slide 7 text

実際に鈴木がRailsのプロダクトで CQRS/ESをしてみると良かったなと思った過去の事例

Slide 8

Slide 8 text

実装をした機能 UberEatsなど、複数の配送サービスAPIを統合し配達者にとって最適な配送手段を選択して自動手配するサービスを開発する仕様 1. ユーザーが配送条件を入力 2. システムが最適な配送サービスを選択 3. 選択した配送サービスへ正式な注文を送信 4. 配送の進行状況を記録

Slide 9

Slide 9 text

配送サービスAPIは独自に開発してもらっているものだから不安定開発してもらたAPIがバグでエラーになったのか、プロダクト側で失敗した理由かがわからない「現在の状態」はわかるが、いままでどのよなことをしてその状態(配送中とか)になったのかがわからない   システムを動かすためには作成してもらった APIを動かす必要があるがその連携がたいへん  APIを作ってもらった会社に連絡をする必要がある問題点

Slide 10

Slide 10 text

複雑な機能は多くのプロダクトで発生し、イベントソーシングはそれを適切に管理する強力な手法システムの状態変化を履歴として記録し、過去のプロセスを再現できるエラーの発生箇所や原因を正確に追跡できるビジネスルールの変更にも柔軟に対応し、長期的な拡張性を確保イベントソーシングを使う事によるメリット

Slide 11

Slide 11 text

イベントソーシングは重要なのわかったけど、実際にRailsでどう実装していくの？

Slide 12

Slide 12 text

DDD/EAが盛んなEUで導入されているリポジトリのStar数が1.4k 機能面 Hexagonalアーキテクチャで外部依存を分離し、 ActiveRecordのコールバックを排除。疎結合なイベント駆動の連携・副作用の分離・完全な履歴管理により、拡張性の高い、スケールしやすく安定したシステムを構築しやすい https://railseventstore.org/ Rails Event StoreというGemがある

Slide 13

Slide 13 text

ESについて理解していない状態でこのライブラリーをしようするのはおすすめしない挫折する理由になってしまう

Slide 14

Slide 14 text

従来のCRUDとは異なるパターンのため、単にライブラリを使うだけでは、内部で何が起こっているのかを正しく理解することは難しい。このライブラリを利用する場合でも、CQRS/ESの独特な実装パターンを把握し、EventStoreやEventBusなどの仕組みを理解することが重要になる。

Slide 15

Slide 15 text

難しいので、挫折しそうだけど、最初はなにをじっそうするといいのか？

Slide 16

Slide 16 text

難しいので、挫折しそうだけど、最初はなにをじっそうするといいのか？最初は同期処理のスクリプト(rake)でユーザーからの入力を受け取りそれをイベントとして記録するだけのものを作るのがおすすめ

Slide 17

Slide 17 text

同期処理がいい理由通常CQRS/ESは非同期処理で実装をするが、普段はRESTAPIなどの同期処理のプログラミングスタイルをしている人にとっては、何がいつ実行されているのかが分かりづらくなる。また非同期処理は実装が複雑になりやすい。そのため、まずは同期処理で動作を理解する

Slide 18

Slide 18 text

スクリプトがいい理由 Webアプリとして作ると、フロントエンドやAPIの設計が絡み、 CQRS/ESの本質を理解する前に「どうリクエストを受けるか？」といった別の課題に直面しがち。スクリプトなら、「コマンド → ハンドラー → イベント発生 → 状態更新」だけにフォーカスできるため、CQRS/ESの構造を最小限の実装で学べる。

Slide 19

Slide 19 text

CQRS/ESの簡単なスクリプトの例

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

Railsで実装するときにしっておいたほうがいいこと

Slide 22

Slide 22 text

EventStoreはActiveRecordで問題ない PostgreSQL や MySQL の JSON カラムを活用すれば、イベントデータを柔軟に格納できるため、普段使い慣れている ActiveRecord で実装できる一方で、MongoDB など普段使い慣れていないデータベースを導入すると、新しい手法を学びながら、さらに別の新しい技術にも適応する必要があり、挫折しやすくなる

Slide 23

Slide 23 text

従来の実装では、データベースの処理は通常、一つのトランザクションにまとめてSQLを実行するしかし、CQRS/ESでは、イベント登録とクエリーの更新を同じトランザクションで行うのは一貫性の問題が発生するため、明確なアンチパターンとなるイベント登録とクエリーの更新を同じトランザクションではしていはいけない

Slide 24

Slide 24 text

Railsで同期的なPub/Subをするには ActiveSupport::Notificationsがつかえる通知 Publish Subscribe

Slide 25

Slide 25 text

まとめ RailsでもESで実装をするとコアドメインの複雑な機能の実装とかの重要なデータに関する部分の実装は役に立つはず　いきなり、ESのライブラリーを使うと何を実装しているのかがわからないまま実装をしてしまう最初は、簡単な同期的更新をするスクリプトを自分で作成してどのように実装をするのかを理解する

Slide 26

Slide 26 text

ご清聴ありがとうございました