CQRSデザインパターンを使用する場合
私のチームとCQRS（Command Query Responsibility Segregation）デザインパターンの使用について議論してきましたが、それを使用することの長所と短所を評価しようとしています。によると： http://martinfowler.com/bliki/CQRS.html
この分野でのCQRSの十分な使用はまだ見ていませんが、その長所と短所を理解しているとは確信できません。
それでは、問題がCQRSの使用を要求するのはいつですか？
CQRLの批評家は、CQRSは複雑であり、真実であると言うかもしれません。
もちろん、CQRSスタイルの単純なCRUDアプリケーションを開発するオーバーヘッドが追加されるため、次の場合にのみCQRSを使用することを検討します。
- 大規模チーム-CQRSアーキテクチャを選択した場合、開発タスクを人々の間で簡単に分割できます。上位の人々は、ドメインロジックに取り組むことができ、通常の作業はスキルの低い開発者に任せます。
- 困難なビジネスロジック-CQRSを使用すると、ドメインロジックとインフラストラクチャ操作の混在を避けることができます。
- スケーラビリティが重要-CQRSを使用すると、優れた読み取りおよび書き込みパフォーマンスを達成でき、コマンド処理は複数のノードでスケールアウトでき、クエリは読み取り専用操作であるため、高速読み取り操作を実行するために最適化できます。
複雑またはハードなビジネスドメインがあり、次の場合：
- イベントソーシング;ロジックをテストする素敵な方法が欲しい
- イベントソーシング;テストと推論により行動を証明したい
- ドメインサービスのクライアントまたはコンシューマが複数ある（単一のWebサーバーではない）
または、共通データに基づいて行動する必要があるユーザーがいます：
- ドメインのデータマージの概念を形式化したい
- または、イベントをマージするためのロジックを適用したい
または、スケーラビリティ要件があります：
- パターンをボトルネックを除去する非正規化パターンとして適用します
- 垂直ではなく水平にスケーリングしたい
または、パフォーマンスの問題がある（スケーラビリティの反対側）：
- 例えばアーキテクチャーをイベント駆動型アーキテクチャーに移行する必要があります-パターンとしてのCQRSは良い踏み台です。
または、物理的に分離したチームがあります：
- 例えばチームの一部が別の国にいます
- または、対面のコミュニケーションをとるのが難しいので、読み取りモデルを物事の書き込み側（Sagas、Domain、CRUD）から切り離したい
過度に複雑なのはCQRSではなく、コンピューターです。
CQRS設計パターンを使用する場合
CQRSアーキテクチャパターンは、ユーザーが表示する必要があるすべてのデータをリポジトリからクエリすることが困難な場合に使用できます。これは、UXデザインが複数の集計タイプとインスタンスにまたがるデータのビューを作成する場合に特に当てはまります。ドメインが洗練されるほど、これは真実になる傾向があります。
UX設計で妥協するのが不適切な場合、CQRSを使用すると、次のような他のソリューションに関連する問題を軽減しようとします。
- クライアントが複数のリポジトリを使用してすべての集約インスタンスを取得することを要求します。または
- 単一のクエリを使用してばらばらのデータを収集するための、さまざまなリポジトリ上の専門的なファインダーの設計。
要約すると、ユーザーが表示する必要のあるリポジトリデータからクエリを実行するのが困難な場合にCQRSを使用します。これは、ドメインがより高度になると発生する傾向があります。
私の観点から、それは2つの大きな利点を追加します。（他の多くの中で）
- 究極のスケーリング能力
- 配布されたチームに関して非常に便利です。
CQRSを使用する理由は次のとおりです。
- スケーラビリティ（読み取りは書き込みを上回るため、それぞれのスケーリング要件は異なり、より適切に対処できます）
- 柔軟性（個別の読み取り/書き込みモデル）
- 複雑さの軽減（複雑さを個別の懸念事項にシフト）
- ドメイン/ビジネスに集中
- 直感的なタスクベースのUIの設計を容易にします
実際のシナリオでは、CQRSは、複数のドメインからの大量のデータを必要とするフロントエンド/ Webサービスクライアントがあり、データベースからのこれらのデータの取得に時間がかかる場合に役立ちます。
そのような場合、開発がより速くなり、実行時間がより速くなる可能性のある個別の読み取りモデルの作成を検討することができます。