マイクロサービスアーキテクチャで複数のクライアントを使用するアグリゲーターパターンは有効ですか？
2つのマイクロサービスが製品の情報を提供するとします。1つは一般情報（A）を提供し、もう1つは製品イメージ（B）を提供します。 ゲートウェイ集約パターン で説明されているアーキテクチャと同様に、これらのサービスAとBの間に集約ゲートウェイを作成します。
下の画像のように複数のアプリケーションがその集約ゲートウェイにアクセスする場合、それはマイクロサービスアーキテクチャと競合しますか？
このパターンは、「フロントエンドのバックエンド」のようなミニフォーマットでよく見られると思います。しかし、私はdoは反パターンのビットだと思います。
私が見ている問題は、Aggregatorが非常に薄くなる可能性があることです。アプリケーション、またはフロントエンドに直接実装できない追加機能を追加しない。
ただし、Aggregateが追加する追加の制約、追加のボックス、ネットワーク、追加のボトルネック、追加のコードを削除することはできません。
たとえば、あなたの例では、マイクロサービスアプローチの利点の1つは、画像を取得できない場合でも製品リストを取得できることであり、一部が壊れてもアプリケーションは完全には壊れません。
または、画像が遅いことがわかった場合は、画像サービスを水平方向にスケーリングできます。
彼のアグリゲーターはこれらのことを不可能にしていませんが、「独自のロジック/データを持っているが他のマイクロサービスに依存しているサービス」から「単にメッセージを渡すゲートウェイ」へのあいまいな移行があります。私の感じは、あなたはMicroServiceとそのコンシューマーの間のフロー導入要素に反対しているということです。
循環型の依存関係や他の厄介なアンチパターンを形成しない限り、階層型サービスに問題はないと思います。
すべてのクライアントに搭載してサーバーのCPUを節約する方が便利か、サーバーに搭載してアップグレードとテストを簡素化するほうが便利かを分析するだけです。