マイクロサービスが多すぎることなく、独立した論理ブロックを開発するにはどうすればよいですか？
論理コードのさまざまなindependent小さな「ブロック」で構成されるサービスがあります。ブロックは、BlockRequestパラメータを取得してBlockResponseパラメータを返す「実行」関数を含むインターフェース「IBlock」を実装するクラスを表します。通常、各論理ブロックは次のことを行います。DBからデータを取得し、API呼び出しを行い、データに対する特定の単純なロジックを実行し、正規化された応答を返します。
このサービスの目的は、要求に応じて動的にブロックを実行することにより、外部オーケストレーター（異なるサービス）にサービスを提供することです。サービスはビジネスフローを認識せず、オンデマンドで特定のブロックを実行することのみを認識します。基本的に、サービスは、独立した論理ブロックの一種のリポジトリです。
サービスは、キューを介して要求メッセージを受信し、要求（特定のブロック）に応じていくつかのロジックを実行し、応答メッセージを別のキューにパブリッシュすることによって応答を返します。
ブロックの実行以外では、サービス自体はかなり無駄がなく、ほとんどロジックがありません。ほとんどの場合、リクエストの検証、ロギング、DBへの書き込み、レスポンスのパブリッシュバックです。ただし、多くの「論理ブロック」があり、このサービスを使い続けると数が増えるだけです。
論理ブロックが多すぎて維持が難しくなり、新しいブロックの形の小さなロジックが追加されるたびにソリューションに別のクラスを追加することを意味します-
新しいブロックまたは小さな変更をサポートするために、サービス全体をテストし、すべてを再度展開する必要があります。
ブロックをさまざまなサービスに分離すると、各ブロックを個別にデプロイして保守できるため、役立つ可能性がありますが、最終的には、多くのサービスを維持および追跡するのが難しくなるため、これは不十分なソリューションになります。
このサービスを適切に構築するのに役立つ中間パターン\技術\デザインはありますか？
神話をやめましょう。ブロックが独立しているという事実自体がマイクロサービスを正当化するものではありません。
見つかるバランスがあります：
- 独立してデプロイ可能なマイクロサービスを使用することの利点と複雑さが増すことの不便さの間。
- メンテナンスの利点とサービス間通信のパフォーマンスオーバーヘッドの間。
いずれにしてもオーケストレーションアーキテクチャにはサービス間通信が必要なため、2番目のポイントは問題ではありません。
最初の点については、議論の余地があります。マイクロサービスの望ましい細分性についての多くの誤解を考慮して、マイクロサービスの第一人者であるChris Richardsonが 新しい経験則 をリリースしました。
チームの自律性と疎結合を確保するには十分であり、サービスを追加するたびに複雑さとオーバーヘッドが増えるため、チームは理想的には1つのサービスのみを所有する必要があります。チームは、具体的な問題を解決する場合にのみ、そのコードを複数のサービスとして展開する必要があります（...）
私にはアドバイスするのに十分な要素はありませんが、あなたの目標は何か、そして各「ブロック」を個別に解放することが本当に有益かどうかを自問してください。
たとえば、独立したブロックはいくつかの共有コードに依存しますか？そのコードはどのくらいの頻度で変更され、将来このような変更にどのように対処しますか？それとも、リクエストで交換されるデータについての期待のために、いくつかの隠れた結合があるのでしょうか？
代わりに、すべてのブロックを提供するサービスを検討しましたか？粗い粒度のサービスをいくつか実行して、水平方向のスケーラビリティを実現することもできます。
さて、自分のアイデアに挑戦した後で、マイクロサービスが適切なソリューションであると結論付けたら、それを試してください:-)