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