CRUD から CQRS へ ～ 分離が可能にする柔軟性 イベントソーシング・CQRS 勉強会 #2 2025年 5月 19日 株式会社ジェイテックジャパン 川江貴志 

自己紹介 川江貴志 | Kawae Takashi X: @takashikawae 株式会社ジェイテックジャパン 所属 Developer Advocate for Sekiban Solution Architect 

セッション内容 1. CRUD の課題 2. CQRS という解決策 3. CQRS とイベントソーシングは不可分 CQRS とイベントソーシングに関する、割と基礎的な概念の話です 

CRUD でも良いけれど... 

Client 書き込み操作 読み取り操作 Create Update Delete Read DB CRUD とは Create / Read / Update / Delete の頭文字 データベースやアプリケーションでデータ を操作する際に必要な基本的な4つの機能 実装がシンプルで理解しやすいデータ操作 の概念 通常、読み取り (Read) と書き込み (Create/Update/Delete) に同じデータモ デル (エンティティやテーブル構造) を使う → 読み取りと書き込みは同じ？ 

データの読み取りと書き込みの特性は違う 観点 読み取り (クエリ) 書き込み (コマンド) 目的と責任 データの検索・取得 データの状態の変更 期待されるデータモ デル 表示のための非正規化モ デル データの整合性を維持する正規 化モデル 最適化の方向性 データ取得の高速性が重 要 ビジネスロジックの正確な実行 が重要 スケーリング スケールアウトで対応し やすい スケールアップで対応しやすい アプリケーションが複雑になればなるほど相違が明確になる 本質的に異なるものを一つにまとめるのは簡単ではない 

CRUD で生じやすい課題 読み取りと書き込みの最適化の難しさ 単一モデルの制約: 同じデータモデルを読み取りと書き込みの両方に使用するた め、それぞれに最適化することが困難 相反する最適化: 読み取り向けのインデックスが書き込みパフォーマンスを低下さ せるなど、トレードオフが生じやすい コードの複雑化 責務の混在: 読み取りと書き込みのロジックが同じクラスやモジュールに混在 テスト難易度の上昇: 読み書きが密結合しているため単体テストが複雑になりやす い 

CRUD で生じやすい課題 スケーラビリティの制限 分離できない負荷: 読み取りと書き込みを独立してスケールできない 不均衡な操作頻度: 読み取り操作は書き込みよりも頻繁に行われるため、リソース 配分が非効率になりやすい 監査とセキュリティの課題 変更履歴の管理: 変更の追跡や監査証跡の仕組みが別途必要 権限管理の複雑さ: 操作タイプごとに異なる権限設定を単一モデルで管理するのが 困難 

CQRS にしてみよう 

Client コマンド処理 Command Model Write DB クエリ処理 Query Model Read DB CQRS とは 日本語ではコマンドクエリ責務分離 コマンド (更新操作) とクエリ (読み取り操作) を 明確に分離し、異なるモデルとして実装する設 計手法 読み取りと書き込みで異なるデータストアの使 用も可能 読み取りと書き込みは本質的に違うので、 別々に設計・実装しよう、という考え方 

CQRS のメリット 読み取りと書き込みの最適化が容易に モデルの分離: 読み取り専用モデルと書き込み専用モデルを別々に最適化可能 専用の設計: それぞれの用途に最適なスキーマやインデックス戦略を採用できる コードの単純化と責務の明確化 明確な境界: コマンド処理とクエリ処理が分離され、コードの責務が明確に テストの容易さ: コマンドとクエリを独立してテスト可能 

CQRS のメリット 柔軟なスケーリング 独立したスケーリング: 読み取りと書き込みを別々にスケールでき、リソースを効 率的に配分 負荷に応じた最適化: 読み取り頻度が高いシステムでは、読み取りサービスだけを 増強可能 監査とセキュリティの強化 変更履歴の自然な記録: コマンドモデルで変更履歴を管理しやすい構造 きめ細かな権限設定: コマンドとクエリで異なる認可ポリシーを適用可能 

CQRS のデメリット 複雑性の増加 2つのモデル管理: 読み書きモデルを別々に設計・維持する必要がある 同期メカニズム: コマンド処理の結果をクエリモデルに反映させる仕組みが必要 結果整合性への対応 即時一貫性の欠如: 読み取りモデルの更新に遅延が生じる可能性がある ユーザー体験の考慮: 更新後すぐに反映されない状況を適切に処理する必要がある 導入の難しさ 学習コスト: 従来の CRUD ベースの開発に比べて概念理解のハードルが高い オーバーエンジニアリングの危険: 小規模なアプリケーションでは不必要に複雑に なる可能性がある 

CQRS？ならイベントソーシングも一緒に 

Client Command Model Command Handler Event Event Store Query Model Projection Projector Materialized View CQRS とイベントソーシングは一体 自然な相互補完: イベントソーシングはコマン ド処理の結果をイベントとして記録し、クエリ モデルの更新ソースとなる 状態管理の整合性: コマンドから生成されたイ ベントが、読み取りモデルの唯一の情報源とな り一貫性を確保 独立した発展: クエリモデルはイベントストリ ームから自律的に構築され、コマンドモデルと の分離が促進される 履歴トレーサビリティ: イベントの連続として システム全体の状態変化を追跡・再現可能 

Closing 

まとめ CRUD は読み書きの異なる性質を単一のモデルで扱うため、複雑なシステムでは 最適化が困難になる CQRS はコマンドとクエリを分離することで、それぞれに適した設計と実装を可能 にする イベントソーシングと CQRS の組み合わせにより、データの整合性を確保しつつ 多様なクエリ要件に柔軟に対応できる 

ありがとうございました ジェイテックジャパン テックブログ https://zenn.dev/p/jtechjapan_pub Sekiban - イベントソーシング & CQRS フレームワーク https://github.com/J-Tech-Japan/Sekiban