Microservicesリクエストを処理するためのデザインパターン

Question

私はMicroservicesに基づいたアプリケーションを持っています。 HTTPリクエストを受け取るブローカ/ゲートウェイAPIがあります。次に、サービスAとサービスBの2つのサービスが追加されます。ブローカAPIがメッセージを受信すると、RabbitMQを使用してメッセージがサービスに送信されます。そして、それぞれの中で私はそれを処理し、メッセージに応じて違った処理をするべきです（別のアクションを実行してください）。

これは私が現在のメッセージを処理する方法である：

サービスA

public string ProcessAsync(Message message) 
    { 

     switch (message.EventCode) 
     { 
      case "context 1": 
       return action1(); 
      case "context 2": 
       return action2(); 
      case "context 3": 
       return action3(); 
      case "context 4": 
       return action4(); 
      case "context 5": 
       return action5(); 
      default: 
       throw new Exception("Unknown message event code!"); 
     } 
    } 

私は5以下持っている場合には、switchステートメントを使用することは理にかなっています - 10種類のメッセージタイプを。しかし、私のアプリでは30歳です。そのような大きな条件文を書くことは、維持するには醜く、異なっています。私はアプリケーションからこの問題を取り除く予定のデザインパターンを探しています。あなたはなにか考えはありますか？ステートパターンについてどう思いますか？

Answer 1

CQRSアーキテクチャを試すことができます。

CQRSでは、すべてのコマンドには正確に1つのハンドラがあります。コンポーネントとして、CommandSubscriberを使用してすべてのコマンドを正しいハンドラに送信するCommandDispatcherが必要です。各コマンドが実行されると、1つまたは複数のイベントが生成されます。すべてのイベントは、1つまたは複数のイベントハンドラにもディスパッチされます。

すべてのメッセージが同じクラス（Message）の場合、CommandSubscriberはmessage.EventCodeに基づいてコマンドハンドラを登録する必要があります。すべてのメッセージのクラスが異なる場合（Messageはinterface）、CommandSubscriberはメッセージクラスに基づいてコマンドハンドラを登録する必要があります。このアーキテクチャのスタイルはOpen-close principleを尊重しますが、スイッチベースのスタイルはそうではありません。