Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

コマンドクエリ責務分離 (CQRS: Command and Query Responsibility Segregation) by Mind Map: コマンドクエリ責務分離 (CQRS:
Command and Query Responsibility
Segregation)
5.0 stars - 1 reviews range from 0 to 5

コマンドクエリ責務分離 (CQRS: Command and Query Responsibility Segregation)

Greg Young流CQRS - Mark Nijhof - Digital Romanticism

システムの 更新処理と 参照処理を 分離する

Event Sourcing

イベントを 蓄積する

最新の 情報は イベントから 求める

関数型で 処理できる

Toodledo は CQRS 的

タスクリストの 表示は クエリー

リストアイテムの 分類や 完了を 変更しても 画面上に 残り続ける

すぐに 元に 戻せる

画面上では その場で 書き換え

サーバーには コマンドが 発行される

コマンドと クエリーが 分離している

他マップ: プログラム構成法, ロジックの 置き場所

CQRS by Martin Fouler

コマンドと クエリーで 別の ドメインモデルを 使っても よい

ドメインモデルが 必要になるのは 主に コマンドの 場合

クエリーは ドメインモデルが無くて DB 直結でも よい

クエリー用に Reporting Database を作っても よい

Cloud 時代の Architecture

あらゆる メソッドは コマンドまたは クエリーの どちらかである

コマンド, アクションを 実行する

クエリー, データーを 返す, オブジェクトを 返さずに データーを 直読みする, 分散処理可能, データソースが 分散している 可能性, 読み込み用 DB を 作成しておく, アプリケーションごとに, 非正規化しておく

両方を やっては いけない

更新処理と 参照処理に 対する 応答部分を 明確に 分離する

Aggregate Root (集約ルート)

リポジトリアクセスの ための 最上位オブジェクト

クライアントは 集約ルートを 呼び出すだけで その 下の すべての オブジェクトを 呼び出すことが できる

エラーチェックについて

ここで 議論されている

dry - Does validation in CQRS have to occur separately once in the UI, and once in the business domain? - Stack Overflow

問題

送られた コマンドは 値を 返さない

エラーだったかどうか クライアント側からは わからない

解決策

クライアントは コマンドについての エラーチェックだけを する, 例, 項目に 抜けや 間違いが あったら 送信ボタンが 押せないように する

送られた コマンドが 処理されたか どうかは 確認しない, クエリーで 状態が 変わって いなければ 処理されなかったと 判断すべき

FAX の 送信は CQRS 的?

紙を 読み込ませるのは コマンド

結果は すぐに 返らず, 後で 送信履歴を 見て 判断する

でも FAX では 話し中が 数回あると エラーレポートが 印字される

CQRS では?, クエリーに エラー結果が 表示される, その コマンドを 送信した クライアントを 判断できる?