CQRSの基本

この記事は、CQRSに関するさまざまな記事の資料と、このアプローチを採用したプロジェクトに基づいています。



企業、プロジェクト、従業員の管理システムは、私たちの生活に長く含まれています。 そして、このようなエンタープライズアプリケーションのユーザーはますます要求が厳しくなります。スケーラビリティ要件、ビジネスロジックの複雑さが増し、システム要件が急速に変化し、リアルタイムでレポートが必要になります。



したがって、開発中に、コードとアーキテクチャの整理、およびそれらの複雑化において、同じ問題をしばしば観察できます。 間違った設計アプローチでは、遅かれ早かれ、コードが非常に複雑で混乱し、変更ごとにより多くの時間とリソースが必要になる瞬間が来るかもしれません。

典型的なアプリケーション設計アプローチ

階層化アーキテクチャは、Webアプリケーションを構築する最も一般的な方法の1つです。 上の図のように、その簡単なバリエーションでは、アプリケーションはデータレイヤー、ビジネスロジックレイヤー、ユーザーインターフェイスレイヤーの3つの部分に分かれています。



データレイヤーには特定のリポジトリがあり、データウェアハウスから私たちを引き離します。

ビジネスロジックレイヤーには、ビジネスルールをカプセル化するオブジェクトがあります（通常、名前はServices / BusinessRules / Managers / Helpers内で異なります）。 ユーザーリクエストはUIからビジネスルールを通り、次にリポジトリを通り、データウェアハウスの操作が実行されます。



このアーキテクチャでは、データの受信と変更の要求は通常、ビジネスロジック層の同じ場所で行われます。 これはコードを整理するための非常にシンプルで馴染みのある方法であり、このようなモデルはほとんどのアプリケーションに適しています。これらのアプリケーションでは、ユーザーの数が時間の経過とともに大きく変化せず、アプリケーションに大きな負荷がかからず、機能の大幅な拡張が必要な​​い場合



しかし、Webリソースが非常に一般的になった場合、1つのサーバーでは十分ではないという疑問が生じる場合があります。 そして、複数のサーバー間の負荷分散の問題が生じます。 負荷をすばやく分散する最も簡単なオプションは、リソースとデータベースの複製の複数のコピーを使用することです。 そして、そのようなシステムのすべてのアクションが決して分離されていないことを考えると、これは新しい問題を生み出します。



従来の多層アーキテクチャでは、このような問題を簡単に解決することはできません。 したがって、これらの問題を最初から解決するアプローチを使用するとよいでしょう。 そのようなアプローチの1つがCQRSです。

コマンドとクエリの責任分離（CQRS）

CQRSは、状態を変更するコードを、その状態を単に読み取るコードから分離するソフトウェア設計アプローチです。 この分離は論理的で、さまざまなレベルに基づいています。 さらに、物理的で、異なる層またはレベルを含めることができます。



このアプローチは、コマンドクエリ分離（CQS）の原理に基づいています。



CQSの主な考え方は、オブジェクトには2つのタイプのメソッドが存在できるということです。

• クエリ：メソッドは、オブジェクトの状態を変更せずに結果を返します。 つまり、クエリには副作用はありません。
• コマンド：メソッドは、値を返さずにオブジェクトの状態を変更します。

この分離の例については、1つのIsEmailValidメソッドを持つUserクラスを検討してください。

1. public class User { public string Email { get ; private set ; } public bool IsEmailValid( string email) { bool isMatch = Regex .IsMatch( "email pattern" , email); if (isMatch) { Email = email; // Command } return isMatch; // Query } }
   
   
   
   
2. public class User { public string Email { get ; private set ; } public bool IsEmailValid( string email) { bool isMatch = Regex .IsMatch( "email pattern" , email); if (isMatch) { Email = email; // Command } return isMatch; // Query } }
   
   
   
   
3. public class User { public string Email { get ; private set ; } public bool IsEmailValid( string email) { bool isMatch = Regex .IsMatch( "email pattern" , email); if (isMatch) { Email = email; // Command } return isMatch; // Query } }
   
   
   
   
5. public class User { public string Email { get ; private set ; } public bool IsEmailValid( string email) { bool isMatch = Regex .IsMatch( "email pattern" , email); if (isMatch) { Email = email; // Command } return isMatch; // Query } }
   
   
   
   
6. public class User { public string Email { get ; private set ; } public bool IsEmailValid( string email) { bool isMatch = Regex .IsMatch( "email pattern" , email); if (isMatch) { Email = email; // Command } return isMatch; // Query } }
   
   
   
   
7. public class User { public string Email { get ; private set ; } public bool IsEmailValid( string email) { bool isMatch = Regex .IsMatch( "email pattern" , email); if (isMatch) { Email = email; // Command } return isMatch; // Query } }
   
   
   
   
9. public class User { public string Email { get ; private set ; } public bool IsEmailValid( string email) { bool isMatch = Regex .IsMatch( "email pattern" , email); if (isMatch) { Email = email; // Command } return isMatch; // Query } }
   
   
   
   
10. public class User { public string Email { get ; private set ; } public bool IsEmailValid( string email) { bool isMatch = Regex .IsMatch( "email pattern" , email); if (isMatch) { Email = email; // Command } return isMatch; // Query } }
    
    
    
    
11. public class User { public string Email { get ; private set ; } public bool IsEmailValid( string email) { bool isMatch = Regex .IsMatch( "email pattern" , email); if (isMatch) { Email = email; // Command } return isMatch; // Query } }
    
    
    
    
12. public class User { public string Email { get ; private set ; } public bool IsEmailValid( string email) { bool isMatch = Regex .IsMatch( "email pattern" , email); if (isMatch) { Email = email; // Command } return isMatch; // Query } }
    
    
    
    
14. public class User { public string Email { get ; private set ; } public bool IsEmailValid( string email) { bool isMatch = Regex .IsMatch( "email pattern" , email); if (isMatch) { Email = email; // Command } return isMatch; // Query } }
    
    
    
    
15. public class User { public string Email { get ; private set ; } public bool IsEmailValid( string email) { bool isMatch = Regex .IsMatch( "email pattern" , email); if (isMatch) { Email = email; // Command } return isMatch; // Query } }
    
    
    
    
16. public class User { public string Email { get ; private set ; } public bool IsEmailValid( string email) { bool isMatch = Regex .IsMatch( "email pattern" , email); if (isMatch) { Email = email; // Command } return isMatch; // Query } }
    
    
    
    

このメソッドでは、送信された電子メールが有効かどうかを問い合わせます（クエリを実行します）。 はいの場合はTrue、それ以外の場合はFalseを取得します。 ここでは、値を返すことに加えて、有効な電子メールの場合、その値（コマンドを実行）をすぐに[電子メール]フィールドに割り当てることも決定されています。



この例は非常に単純であるにもかかわらず、ネストのいくつかのレベルで呼び出されたときにさまざまなオブジェクトの状態を変更するQueryメソッドを想像すれば、それほどささいな状況も可能です。 最良の場合、同様のメソッドとその長いデバッグを処理する必要がない場合、幸運です。 Queryを呼び出すことによるこれらの副作用は、システムがどのように機能するかを理解するのが難しいため、しばしば落胆させられます。



CQSの原則を使用し、メソッドをコマンドとクエリに分割すると、次のコードが取得されます。

1. パブリッククラス User
2. {
3. パブリックストリングメール{ get ; プライベートセット ; }
5. public bool IsEmailValid（ string email） //クエリ
6. {
7. Return Regex .IsMatch（ "email pattern" 、email）;
8. }
10. public void ChangeEmail（ string email） //コマンド
11. {
12. if （IsEmailValid（email）== false ）
13. throw新しい ArgumentOutOfRangeException （電子メール）;
15. メール=メール;
16. }
17. }

これで、クラスのユーザーはIsEmailValidを呼び出したときに状態の変化を見ることがなくなり、結果が得られるだけです-電子メールが有効かどうか。 また、ChangeEmailメソッドを呼び出すと、ユーザーはオブジェクトの状態を明示的に変更します。



クエリには、CQSに1つの機能があります。 Queryはオブジェクトの状態を一切変更しないため、Queryタイプのメソッドを並列化して、読み取り操作に起因する負荷を分離できます。



CQSがメソッドで動作する場合、CQRSはオブジェクトのレベルまで上昇します。 Commandクラスはシステムの状態を変更するために作成され、 Queryクラスはデータを取得するために使用されます。 したがって、システムの状態を変更するオブジェクトのセットと、データを返すオブジェクトのセットを取得します。



UI、ビジネスロジック、データベースがある典型的なシステム設計：







CQRSは、CommandオブジェクトとQueryオブジェクトを混在させる必要はなく、明示的に選択する必要があると述べています。 このように分割されたシステムは、すでに次のようになっています。







CQRSが追求する分離は、あるレベルでクエリ操作をグループ化し、別のレベルでチームをグループ化することによって実現されます。 各レベルには独自のデータモデル、独自のサービスセットがあり、独自のテンプレートとテクノロジーの組み合わせを使用して作成されます。 さらに重要なことに、これらの2つのレベルは2つの異なる階層に配置することもでき、相互に影響を与えることなく個別に最適化できます。



コマンドとクエリが2つの異なるものであることを理解するだけで、ソフトウェアアーキテクチャに大きな影響があります。 たとえば、サブジェクトエリアの各レベルを予測およびエンコードすることが突然容易になります。 コマンドスタックのドメインレイヤーに必要なのは、タスクを完了するためのデータ、ビジネスルール、およびセキュリティルールのみです。 一方、クエリスタックのドメインレベルは、直接SQLクエリよりも複雑になることはありません。

CQRSを使用する場合の開始点

1.チームスタック



CQRSでは、アプリケーションの状態を変更するタスクのみがコマンドスタックに割り当てられます。 チームには次のプロパティがあります。

• システムの状態を変更します。
• 何も返しません。
• コマンドコンテキストには、その実行に必要なデータが格納されます。

コマンドの宣言と使用は、条件付きで3つの部分に分けることができます。

• データを表すコマンドクラス。
• コマンドハンドラクラス。
• 入力コマンドを受け取り、このタイプのコマンドを実装するハンドラーを正確に呼び出すメソッドを含むクラス。

コマンドとクエリの本質は、それらを結合できる共通の機能を備えていることです。 言い換えれば、それらは共通のタイプを持っています。 コマンドの場合、次のようになります。

1. パブリックインターフェイス ICommand
2. {
3. }

最初のステップは、原則として何も含まないインターフェースを宣言することです。 これはパラメーターとして使用され、サーバー側でユーザーインターフェイス（UI）から直接取得するか、別の方法で形成してコマンドハンドラーに送信できます。



次に、コマンドハンドラインターフェイスが宣言されます。

1. パブリックインターフェイス ICommandHandler < in TCommand> where TCommand： ICommand
2. {
3. void Execute（TCommandコマンド）;
4. }

前に宣言されたインターフェイスタイプのデータを受け入れるメソッドが1つだけ含まれています。



その後、送信されたコマンド（ICommand）の特定のタイプに応じて、コマンドハンドラーを一元的に呼び出す方法を決定します。 この役割は、サービスバスまたはディスパッチャによって実行できます。

1. パブリックインターフェイス ICommandDispatcher
2. {
3. void Execute < TCommand >（ TCommand command） where TCommand ：ICommand;
4. }

ニーズに応じて、1つ以上のメソッドを使用できます。 単純なケースでは、1つのメソッドで十分な場合があり、そのタスクは、渡されるパラメーターのタイプによって、呼び出すコマンドハンドラーの実装を決定することです。 したがって、ユーザーはこれを手動で行う必要はありません。



コマンド例 。 オンラインストアがあるとします。倉庫に商品を作成するチームを作成する必要があるためです。 まず、名前でこのコマンドが実行するアクションを示すクラスを作成します。

1. パブリッククラス CreateInventoryItem ： ICommand
2. {
3. public Guid InventoryItemid { get ; }
4. パブリックストリング Name { get ; }
6. public CreateInventoryItem （ GUID InventoryItemld 、 文字列名）
7. {
8. InventoryItemId = inventoryItemId;
9. 名前=名前;
10. }
11. }

ICommandを実装するすべてのクラスには、データ（初期化中に値を設定するプロパティとコンストラクター）が含まれていますが、それ以上のものはありません。



ハンドラーの実装、つまりコマンド自体への直接的な実装は、かなり単純なアクションになります。ICommandHandlerインターフェイスを実装するクラスが作成されます。 type引数は、以前に宣言されたコマンドを示します。

1. パブリッククラス InventoryCommandHandler ： ICommandHandler < CreateInventoryItem >
2. {
3. プライベート読み取り専用 IRepository < InventoryItem > _repository;
5. public InventoryCommandHandlers（IRepository < InventoryItem > repository）
6. {
7. _repository =リポジトリ;
8. }
10. public void Execute（ CreateInventoryItemメッセージ）
11. {
12. var item = new InventoryItem （message.InventoryItemld、message.Name）;
13. _repository.Save（アイテム）;
14. }
16. // ...
17. }

したがって、このコマンドを入力として受け取り、送信されたデータに基づいて実行するアクションを示すメソッドを実装します。 コマンドハンドラーを論理的に組み合わせて、そのようなクラスのさまざまなタイプのコマンドで複数のICommandHandlerインターフェイスを実装できます。 これにより、メソッドがオーバーロードされ、Executeメソッドが呼び出されると、適切なコマンドタイプが選択されます。



ここで、適切なコマンドハンドラーを呼び出すには、ICommandDispatcherインターフェイスを実装するクラスを作成する必要があります。 最後の2つとは異なり、このクラスは一度作成され、コマンドハンドラーの登録と呼び出しの戦略に応じて異なる実装を持つ場合があります。

1. パブリッククラス CommandDispatcher ： ICommandDispatcher
2. {
3. プライベート読み取り専用 IDependencyResolver _resolver;
5. public CommandDispatcher （IDependencyResolverリゾルバー）
6. {
7. _resolver =レゾルバ;
8. }
10. public void Execute < TCommand >（ TCommand command） where TCommand ：ICommand
11. {
12. if （command == null ） throw ArgumentNullException （ "command" ）;
14. var handler = _resolver.Resolve < ICommandHandler < TCommand >>（）;
16. if （handler == null ） throw new CommandHandlerNotFoundException （ typeof （ TCommand ））;
18. handler.Execute（コマンド）;
19. }
20. }

目的のコマンドハンドラーを呼び出す1つの方法は、すべてのハンドラー実装が登録されているDIコンテナーを使用することです。 送信されたコマンドに応じて、このタイプのコマンドを処理するインスタンスが作成されます。 次に、ディスパッチャは単にExecuteメソッドを呼び出します。



2.クエリスタック



クエリスタックは、データ抽出のみを処理します。 要求では、プレゼンテーションレベルで使用されるデータに最も一致するデータモデルが使用されます。 ビジネスルールはほとんど必要ありません。通常、状態を変更するチームに適用されます。



リクエストには次のプロパティがあります。

• システムの状態を変更しません。
• 要求コンテキストには、その実行に必要なデータ（ページング、フィルターなど）が格納されます。
• 結果を返します。

リクエストのアナウンスと使用は、条件付きで3つの部分に分けることもできます。

• 要求クラス。返された結果のタイプを含むデータ。
• リクエストハンドラークラス
• 入力の要求を受け入れ、このタイプの要求を実装するハンドラーを正確に呼び出すメソッドを含むクラス。

コマンドと同様に、リクエストに対して同様のインターフェースが宣言されています。 唯一の違いは、返される内容を示すことです。

1. パブリックインターフェイス IQuery < TResult >
2. {
3. }

ここでは、返されるデータのタイプがタイプ引数として示されます。 これは、stringまたはint []などの任意のタイプにすることができます。



次に、戻り値の型も示されている要求ハンドラが宣言されます。

1. パブリックインターフェイス IQueryHandler < in TQuery、 out TResult > where TQuery：IQuery < TResult >
2. {
3. TResult Execute（TQueryクエリ）;
4. }

コマンドと同様に、ディスパッチャはリクエストハンドラを呼び出すように宣言されます。

1. パブリックインターフェイス IQueryDispatcher
2. {
3. TResult Execute < TQuery 、 TResult >（ TQuery query） where TQuery ：IQuery < TResult >;
4. }

リクエストの例。 検索条件によってユーザーを返すクエリを作成するとします。 ここでは、意味のあるクラス名を使用して、どのような種類の要求が行われるかを示します。

1. パブリッククラス FindUsersBySearchTextQuery ： IQuery < ユーザー []>
2. {
3. パブリックストリング SearchText { get ; }
4. public bool InactiveUsers { get ; }
6. パブリック FindUsersBySearchTextQuery （ 文字列 searchText、 bool inactiveUsers）
7. {
8. SearchText = searchText;
9. InactiveUsers = inactiveUsers;
10. }
11. }

次に、クエリの型と戻り値の型の引数を使用してIQueryHandlerを実装するハンドラーを作成します。

1. パブリッククラス UserQueryHandler ： IQueryHandler < FindUsersBySearchTextQuery 、 User []>
2. {
3. private readonly IRepository < User > _repository;
5. パブリック UserQueryHandler（IRepository < ユーザー >リポジトリ）
6. {
7. _repository =リポジトリ;
8. }
10. public User [] Execute（ FindUsersBySearchTextQueryクエリ）
11. {
12. var users = _repository.GetAll（）;
13. return users.Where（user => user.Name.Contains（query.SearchText））。ToArray（）;
14. }
15. }

その後、リクエストハンドラを呼び出すクラスを作成します。

1. パブリッククラス QueryDispatcher ： IQueryDispatcher
2. {
3. プライベート読み取り専用 IDependencyResolver _resolver;
5. パブリック QueryDispatcher （IDependencyResolverリゾルバー）
6. {
7. _resolver =レゾルバ;
8. }
10. public TResult Execute < TQuery 、 TResult >（ TQuery query） where TQuery ：IQuery < TResult >
11. {
12. if （query == null ） throw新しい ArgumentNullException （ "query" ）;
14. var handler = _resolver.Resolve < IQueryHandler < TQuery 、 TResult >>（）;
16. if （handler == null ） throw new QueryHandlerNotFoundException （ typeof （ TQuery ））;
18. return handler.Execute（クエリ）;
19. }
20. }

コマンドとクエリを呼び出す

コマンドとクエリを呼び出すには、適切なディスパッチャを使用して、特定のオブジェクトを必要なデータとともに転送するだけで十分です。 たとえば、次のようになります。

1. パブリッククラス UserController ： Controller
2. {
3. private IQueryDispatcher _queryDispatcher;
5. パブリック UserController （IQueryDispatcher queryDispatcher）
6. {
7. _queryDispatcher = queryDispatcher;
8. }
10. パブリック ActionResult SearchUsers（ 文字列 searchString）
11. {
12. var query = new FindUsersBySearchTextQuery （searchString）;
14. ユーザー [] users = _queryDispatcher.Execute（クエリ）;
16. 戻りビュー（ユーザー）;
17. }
18. }

ユーザー要求を処理するためのコントローラーがあれば、目的のディスパッチャーのオブジェクトを依存関係として転送し、要求またはコマンドオブジェクトを作成して、それを紛争メソッドExecuteに渡すだけで十分です。



そのため、システム関数の数を増やして依存関係を絶えず増やし、潜在的なエラーの数を減らす必要性を取り除きます。



ハンドラー登録



ハンドラーはさまざまな方法で登録できます。 DIコンテナを使用して、個別に登録するか、目的のタイプのアセンブリを自動的にスキャンできます。 2番目のオプションは次のようになります。

using SimpleInjector;



var container = new Container ();



container.Register( typeof (ICommandHandler<>), AppDomain .CurrentDomain.GetAssemblies());



container.Register( typeof (IQueryHandler<,>), AppDomain .CurrentDomain.GetAssemblies());



これはSimpleInjectorコンテナを使用します 。 Registerメソッドを使用してハンドラーを登録する場合、最初の引数はコマンドハンドラーと要求ハンドラーのインターフェイスのタイプを指定し、2番目はこれらのインターフェイスを実装するクラスが検索されるアセンブリを指定します。 したがって、特定のハンドラーを指定する必要はなく、共通のインターフェースのみを指定する必要があり、非常に便利です。



コマンド/クエリを呼び出すときに、アクセス許可を確認したり、ログに情報を書き込んだりする必要がある場合はどうなりますか？

一元化された呼び出しにより、ハンドラーを実行する前または実行した後、アクションを変更することなく追加できます。 ディスパッチャー自体に変更を加えるか、DIコンテナーを介して元の実装を置き換えるデコレーターを作成するだけで十分です（このようなデコレーターの例については、SimpleInjectorのドキュメントで詳しく説明されています）。







CQRSの利点

• 各クラスの依存関係が少ない。
• 単独責任の尊重（SRP）;
• ほとんどどこにでも適しています。
• 交換とテストが簡単です。
• 機能がより簡単に拡張されます。

CQRSの制限

• CQRSを使用すると、多くの小さなクラスが表示されます。
• 単純なCQRS実装を使用する場合、単一のトランザクションでコマンドのグループを使用することは困難です。
• コマンドとクエリに共通のロジックが表示される場合、継承または構成を使用する必要があります。 これはシステムの設計を複雑にしますが、経験豊富な開発者にとって障害にはなりません。
• CQSとCQRSに完全に固執することは困難です。 最も簡単な例は、スタックからデータを取得する方法です。 データの取得はクエリですが、状態を変更し、スタックサイズを-1にする必要があります。 実際には、原則の厳格な遵守と生産の必要性との間のバランスを求めます。
• CRUDアプリケーションに悪影響を及ぼす。

適さない場所

• 小規模なアプリケーション/システムの場合。
• 主にCRUDアプリケーション。

おわりに

アプリケーションが真に効果的であるためには、ビジネスの要件に適応する必要があります。 CQRSベースのアーキテクチャは、ビジネスワークフローの拡張と変更を大幅に簡素化し、新しいシナリオをサポートします。 拡張機能を完全に分離して管理できます。 これを行うには、新しいハンドラーを追加して登録し、必要なタイプのメッセージのみを処理する方法を彼に伝えます。 新しいコンポーネントは、メッセージが表示されたときにのみ自動的に呼び出され、システムの他の部分と並んで機能します。 簡単、シンプル、効果的。



CQRSを使用すると、コマンドとクエリのパイプラインを任意の方法で最適化できます。 同時に、1つのコンベヤーの最適化により、別のコンベヤーの動作が中断されることはありません。 CQRSの最も基本的な形式では、1つの共通データベースが使用され、アプリケーション層からの読み取りおよび書き込み操作のために異なるモジュールが呼び出されます。



ソース

→ Alexander Byndyuのブログ-CQRSの実践

→ 最前線-通常のアプリケーションのCQRS

→ DDD、CQRS、イベントソーシングの試行方法と結論

→ グレッグヤングによるCQRSドキュメント

→ 簡単なCQRSの例

→ DDDD、CQRS、およびその他のエンタープライズ開発のバズワード