1. Greg Young流CQRS - Mark Nijhof - Digital Romanticism
2. システムの 更新処理と 参照処理を 分離する
3. Event Sourcing
3.1. イベントを 蓄積する
3.2. 最新の 情報は イベントから 求める
3.3. 関数型で 処理できる
4. Toodledo は CQRS 的
4.1. タスクリストの 表示は クエリー
4.2. リストアイテムの 分類や 完了を 変更しても 画面上に 残り続ける
4.2.1. すぐに 元に 戻せる
4.2.2. 画面上では その場で 書き換え
4.2.3. サーバーには コマンドが 発行される
4.2.4. コマンドと クエリーが 分離している
5. 他マップ: プログラム構成法, ロジックの 置き場所
6. CQRS by Martin Fouler
6.1. コマンドと クエリーで 別の ドメインモデルを 使っても よい
6.1.1. ドメインモデルが 必要になるのは 主に コマンドの 場合
6.1.2. クエリーは ドメインモデルが無くて DB 直結でも よい
6.1.3. クエリー用に Reporting Database を作っても よい
7. Cloud 時代の Architecture
7.1. あらゆる メソッドは コマンドまたは クエリーの どちらかである
7.1.1. コマンド
7.1.1.1. アクションを 実行する
7.1.2. クエリー
7.1.2.1. データーを 返す
7.1.2.1.1. オブジェクトを 返さずに データーを 直読みする
7.1.2.2. 分散処理可能
7.1.2.2.1. データソースが 分散している 可能性
7.1.3. 両方を やっては いけない
7.1.4. 更新処理と 参照処理に 対する 応答部分を 明確に 分離する
8. Aggregate Root (集約ルート)
8.1. リポジトリアクセスの ための 最上位オブジェクト
8.2. クライアントは 集約ルートを 呼び出すだけで その 下の すべての オブジェクトを 呼び出すことが できる
9. エラーチェックについて
9.1. ここで 議論されている
9.1.1. dry - Does validation in CQRS have to occur separately once in the UI, and once in the business domain? - Stack Overflow
9.2. 問題
9.2.1. 送られた コマンドは 値を 返さない
9.2.2. エラーだったかどうか クライアント側からは わからない
9.3. 解決策
9.3.1. クライアントは コマンドについての エラーチェックだけを する
9.3.1.1. 例
9.3.1.1.1. 項目に 抜けや 間違いが あったら 送信ボタンが 押せないように する
9.3.2. 送られた コマンドが 処理されたか どうかは 確認しない
9.3.2.1. クエリーで 状態が 変わって いなければ 処理されなかったと 判断すべき
10. FAX の 送信は CQRS 的?
10.1. 紙を 読み込ませるのは コマンド
10.2. 結果は すぐに 返らず, 後で 送信履歴を 見て 判断する
10.3. でも FAX では 話し中が 数回あると エラーレポートが 印字される
10.3.1. CQRS では?
10.3.1.1. クエリーに エラー結果が 表示される
10.3.1.1.1. その コマンドを 送信した クライアントを 判断できる?