開発中のアプリケーションのアーキテクチャパターンを調査しており、マイクロサービスアプローチが適切な選択のように思えますが、サービス間の相互作用を処理する方法はわかりません。
このアプリケーションは主に、ユーザー、ユーザーが所有するプロファイル、写真、および写真内の1つから多数のプロファイルを表すタグを扱います。ユーザーがアップロードした写真を返す方法、特定のタグ付きプロファイルを含む写真を返す方法などが考えられます。
これはマイクロサービスベースのアーキテクチャを設計する最初の試みであり、モノリシックなドメインモデルに触発された歴史から来ています。その世界では、コントローラーはこれらのドメインオブジェクトをつなぎ合わせますが、これがマイクロサービスの方法でどのように機能するかについて頭を包むのに苦労しています。
回答:
通常、サービスは、データにアクセスする必要があるときに他のサービスを呼び出します。データの各部分は、このデータにアクセスして変更するための唯一のエントリポイントとなる特定のサービスに属している必要があります。一部のサービスはシンプルで、通常はドメインモデルに密接に対応します（ユーザーを処理するサービスなど）。他のサービスは高レベルで他のサービスのデータを使用します（例：写真のリストとそれらをアップロードしたユーザーに関する情報の表示） ）。
ユースケースでは、外部から開始し、APIを介してユーザーに利用できるようにする操作（バックエンドサービスの場合）、またはWebアプリケーションの場合にGUIで利用できる操作を検討する必要があります。GUIパーツは多くの場合、独自のコントローラーを備えた通常のアプリケーションです：操作はRESTを介して呼び出される場合があります（AngularJSのように）が、これらのエンドポイントはGUIアプリケーションの使用のみを目的としており、常識的なマイクロサービスではありません。
写真をアップローダーに関する情報とともに表示するとします。ユーザーのIDを指定してユーザーに関する情報を返すユーザーサービスと、写真を一覧表示できる写真サービス（たとえば、いくつかの条件で検索する）を使用できます。写真のリストには、写真ごとにアップロードするユーザーのIDが含まれます。この方法では、これら2つのサービスは結合されません。写真サービスはユーザーIDのみを認識し、ユーザーデータ自体は認識しません。これらの2つのサービスに加えて、「アップローダーに関する情報を写真に一覧表示する」などの操作で3番目のサービスを作成し、他の2つのサービスを呼び出して、返されるデータを結合できます。または、この操作はサービスの代わりにWebアプリケーションによって実行できます。
このアプリケーションは主に、ユーザー、ユーザーが所有するプロファイル、写真、および写真内の1つから多数のプロファイルを表すタグを扱います。ユーザーがアップロードした写真を返す方法、特定のタグ付きプロファイルを含む写真を返す方法などが考えられます。
まあ、プロファイルサービスはユーザーオブジェクトで動作しないはずです。データを返すように求められているユーザーのIDのみを知っている場合があります。この方法では、ユーザーサービスとプロファイルサービス間の対話は必要ありません。
それでも問題が解決しない場合は、対処している正確な状況を説明して明確にしてください。