Command自体のメソッドを処理するのではなく、Handle（）でクラスCommandHandlerを分離する理由

次のようなS＃arpアーキテクチャを使用して実装されたCQRSパターンの一部があります。

public class MyCommand
{
    public CustomerId { get; set; }

    // some other fields
}

public class MyCommandHandler<MyCommand> : ICommandHandler<MyCommand, CommandResult>
{
    Handle(MyCommand command)
    {
        // some code for saving Customer entity

        return CommandResult.Success;
    }
}

なぜCommandデータと処理メソッドの両方を含むクラスを持たないのでしょうか？コマンド処理ロジックをコマンドプロパティとは別にテストする必要がある場合、一種のテスト容易性の利点ですか？または、さまざまな実装で1つのコマンドを処理する必要がある、頻繁なビジネス要件ICommandHandler<MyCommand, CommandResult>ですか？

面白いことに、この質問は、私が取り組んでいたコミュニケーションライブラリについて、エンジニアの1人とまったく同じ会話を思い出したことです。

コマンドの代わりに、Requestクラスがあり、その後RequestHandlerがありました。デザインは、あなたが説明しているものと非常に似ていました。あなたが持っている混乱の一部は、英語の「コマンド」という言葉を見て、即座に「動詞、行動...など」と考えることだと思います。

しかし、この設計では、コマンド（またはリクエスト）を文字と考えてください。または、郵便サービスとは何かを知らない人のために、電子メールを考えてください。それは単にコンテンツであり、そのコンテンツがどのように行動されるべきかから切り離されています。

なぜこれをするのですか？Command Patternのほとんどの単純なケースでは、理由はなく、このクラスに直接作業を実行させることができます。ただし、アクション/コマンド/リクエストがある程度の距離を移動する必要がある場合、設計のようにデカップリングを行うことは理にかなっています。たとえば、接続、ソケット、パイプ、またはドメインとインフラストラクチャ間。または、アーキテクチャ内でコマンドを永続化する必要があるかもしれません（たとえば、コマンドハンドラーは一度に1つのコマンドを実行できます。一部のシステムイベントにより、200コマンドが到着し、最初の40プロセスがシャットダウンした後）。その場合、単純なメッセージのみのクラスを使用すると、メッセージ部分だけをJSON / XML / binary / whateverにシリアル化し、コマンドハンドラーで処理できるようになるまでパイプラインに渡すことが非常に簡単になります。

CommandHandlerからCommandを切り離すことのもう1つの利点は、並列継承階層のオプションが用意されたことです。たとえば、すべてのコマンドは、シリアル化をサポートする基本コマンドクラスから派生できます。また、20個のコマンドハンドラのうち4個が非常に類似していて、来たハンドラの基本クラスから派生できる可能性があります。1つのクラスでデータとコマンドを処理する場合、このタイプの関係はすぐに制御不能になります。

分離の別の例は、コマンドが非常に小さな入力（2つの整数と文字列）を必要とするが、その処理ロジックがデータを中間メンバー変数に格納するのに十分複雑な場合です。50個のコマンドをキューに入れる場合、その中間ストレージすべてにメモリを割り当てたくないため、CommandHandlerからCommandを分離します。これで、50個の軽量データ構造をキューに入れ、より複雑なデータストレージが、コマンドを処理しているCommandHandlerによって1回のみ（または、N個のハンドラーがある場合はN回）割り当てられます。

通常のコマンドパターンは、単一のクラスでデータと動作を保持することです。この種の「コマンド/ハンドラパターン」はわずかに異なります。通常のパターンと比較した唯一の利点は、コマンドがフレームワークに依存しないという追加の利点です。たとえば、コマンドにはDBアクセスが必要な場合があるため、何らかのDBコンテキストまたはセッションが必要です。つまり、フレームワークに依存しています。ただし、このコマンドはドメインの一部である可能性があるため、Dependency Inversion Principleに従ってフレームワークに依存することは望ましくありません。入力パラメータと出力パラメータを動作から分離し、それらを結び付けるディスパッチャを用意することでこれを修正できます。

一方、コマンドの継承と構成の両方の利点を失うことになります。それが本当の力だと思います。

また、マイナーなピック。名前にCommandが含まれているからといって、CQRSの一部にはなりません。それはもっと基本的なことです。この種の構造は、コマンドとしてもクエリとしても同時に使用できます。