マイクロサービスアーキテクチャの共有ドメインモデル
マイクロサービスアーキテクチャを使用するSpring Bootアプリケーションがあるとします。各サービスには独自のドメインモデルがありますが、各サービスはユーザードメインオブジェクトを参照する必要があります。この問題を解決する最善の方法は何ですか？各サービスが単にuserIdを保持し、必要に応じてユーザーサービスにユーザーの詳細を要求するのが良いのでしょうか、それともすべてのマイクロサービスに共有ドメインライブラリがあるのが良いのでしょうか？
マイクロサービスがスケーラビリティ、疎結合、および各サービスの簡単な独立した修正の恩恵を受けるために行った場合は、可能な限り最大限に固執する必要があります。
全体的なアーキテクチャ
私は最良のアプローチは次のようになると思います：
- 一般的なユーザー情報を管理するためのマイクロサービスがあります。
- マイクロサービス固有のユーザー情報（プロファイル、承認、設定など）を各マイクロサービスに保持します（一般的なIDの参照を使用）
追加の読み：
- この記事 は、この種のアーキテクチャと理論的根拠を、承認の具体的なケースとともに非常によく説明しています。
- この記事 は、すべてのサービスが同じリポジトリにアクセスすることを回避するための、ユーザーID管理の課題と解決策を説明しています。
- この記事 は、JWTを使用してサービス間でユーザーのIDを渡す方法を説明しています（idトークンでいくつかの基本情報を提供できるため、ユーザーサービスの後にクエリを繰り返す必要がなくなります）ログイン、少なくとも非常に基本的な情報）。
コード共有
上記のソリューションに同意すると、ユーザーマイクロサービス（ユーザーのカプセル化ドメインモデル）があり、他のすべてのサービスは同じマイクロサービスのコンシューマーです。問題はあなたが望むかどうかを知ることです：
- 各マイクロサービスがコンシューマーコードを再発明し、柔軟で明確なリリースサイクルを可能にする強力な分離の教義に従って、
- または、この基本情報が "chassis"インフラストラクチャパターン の拡張であることを考慮して、ライブラリの一部としてコンシューマコードを共有します。
このコード共有のトピックについては、オピニオンされたオピニオンウォーがあり、私は客観的な立場を取る立場にはないと私は考えています。すでにいくつかの追加の読み物があります：
- この記事 は最善の解決策はないと考えており、それはすべて目的に依存します
- この記事 位置は、それが強い結合を作成する場合にのみコード共有が悪いということであり、コード共有はいくつかの相乗効果をもたらすことができます
- この記事 （マイクロサービスを大規模に実装した人々の）は、個別のビルドが必要であり、古いコードの廃止の問題が発生する可能性があると主張しています。確実なバージョン管理で消費のための共有ライブラリがあっても、これらの優れた慣行は妨げられません。
これについての私見では、密結合を避けるために、ユーザープロバイダーとユーザーコンシューマーの間でコードを共有しないでください。ただし、強力なバージョン管理を実施している場合は、ユーザー消費コードをコンシューマー間で共有できます。このアプローチにはいくつかの利点があります。
- 異なるユーザー消費マイクロサービスは、共有ユーザー消費コードの異なるバージョンで構築できます（バージョンが独立したユーザープロバイダーと互換性がある限り）。ホイールの再発明と同じ柔軟性ですが、生産性が向上します。
- コンシューマーに影響を与えることなく、ユーザープロバイダーサービスを個別に変更できます。
- 消費側でバグが見つかった場合は、一度修正して、すべてのコンシューマを最適なバージョンとして展開できます（バージョン管理のおかげ）。これにより、サービスの品質が向上する可能性もあります。
- 何らかの理由でユーザープロバイダーAPIを更新する義務がある場合は、更新されたユーザー消費をより迅速に展開できます。移行中に新旧のプロバイダーサービスをアクティブにしておくと、この共有の可能性により、古いバージョンのコンシューマープロバイダーをより迅速に廃止することができます。
できれば共有ライブラリは避けます。各サービスに必要なユーザーのプロパティは何ですか？多くの場合、ユーザーを取り巻くほとんどの動作が存在するコアドメインがあり、サポートドメインは多くの場合userIdのみを必要とします。
サービスでユーザーに関するその他の詳細が必要な場合は、そのような状況に対処する方法に関するいくつかの提案 here を参照してください。