マイクロサービスアーキテクチャの共有ドメインモデル

マイクロサービスアーキテクチャを使用するSpring Bootアプリケーションがあると仮定しましょう。各サービスには独自のドメインモデルがありますが、各サービスはユーザードメインオブジェクトを参照する必要があります。この問題を解決する最善の方法は何でしょうか？各サービスが単にuserIdを持ち、必要に応じてユーザーの詳細をユーザーサービスに問い合わせる方が良いでしょうか、それともすべてのマイクロサービス用の共有ドメインライブラリを持つ方が良いでしょうか？

スケーラビリティ、疎結合、各サービスの簡単な独立した変更の恩恵を受けるためにマイクロサービスを利用した場合は、可能な限り最大限に固執する必要があります。

全体的なアーキテクチャ

最善のアプローチは次のようになると思います。

• 一般的なユーザー情報管理のためのマイクロサービスがあります。
• マイクロサービス固有のユーザー情報（プロファイル、承認、設定など）を各マイクロサービスに保持します（一般IDのリファレンを使用）

追加の読み物：

• この記事では、この種のアーキテクチャと理論的根拠を、認可の特定のケースとともに非常によく説明しています。
• この記事では、すべてのサービスが同じリポジトリにアクセスしないようにするための、ユーザーID管理の課題と解決策について説明します。
• この記事では、JWTを使用してサービス間でユーザーのIDを渡す方法について説明します（IDトークンで基本的な情報を提供できるため、少なくとも非常に基本的な場合は、ログイン後にユーザーサービスを再度照会する必要がなくなります）情報）。

コードシェア

上記のソリューションに同意する場合、ユーザーマイクロサービス（ユーザーのドメインモデルをカプセル化）があり、他のすべてのサービスは同じマイクロサービスのコンシューマーです。質問は、あなたが望むかどうかを知ることです：

• 柔軟で明確なリリースサイクルを可能にする強力な分離の教義に従って、各マイクロサービスが消費者コードを再発明するか、
• または、この基本的な情報が「シャーシ」インフラストラクチャパターンの拡張であることを考慮して、ライブラリの一部としてコンシューマコードを共有します。

このコード共有トピックに関する意見争いがあり、客観的な立場をとる立場にあるとは思わないため、明確な立場をとることはしません。すでにいくつかの追加の読み物があります：

• この記事では、最善の解決策はないと考えており、それはすべて目的に依存します
• この記事の位置は、強力な結合を作成する場合にのみコード共有が悪いことであり、コード共有は相乗効果をもたらす可能性があるということです。
• この記事（大規模にマイクロサービスを実装した人々）は、別個のビルドが必要であり、古いコードの潜在的な廃止の問題を主張しています。以下のための共有ライブラリを持つ消費する固体バージョン管理では、これらの優れた慣行を防ぐことはできません。

私自身の意見では、密結合を避けるために、ユーザープロバイダーとユーザーコンシューマーの間でコードを共有しないでください。ただし、強力なバージョン管理を実施している場合は、消費者間でユーザー消費コードを共有できます。このアプローチにはいくつかの利点があります。

• 異なるユーザー消費マイクロサービスは、異なるバージョンの共有ユーザー消費コードを使用してビルドできます（バージョンが独立したユーザープロバイダーと互換性がある場合）。車輪の再発明と同じ柔軟性ですが、生産性が向上します。
• 消費者に影響を与えることなく、ユーザープロバイダーサービスを個別に変更できます。
• 消費側でバグが見つかった場合、それを一度修正して、すべての消費者を最適な方法で展開できます（バージョン管理のおかげです）。これにより、サービス品質が向上する可能性さえあります。
• 何らかの理由でユーザープロバイダーAPIを更新する必要がある場合は、更新されたユーザー消費をより迅速に展開できます。移行中に古いプロバイダーサービスと新しいプロバイダーサービスをアクティブに保つと、この共有の可能性により、コンシューマープロバイダーの古いバージョンをより迅速に廃止できます。

可能な限り共有ライブラリを避けたい。各サービスに必要なユーザーのプロパティは何ですか？多くの場合、ユーザーを取り巻く動作のほとんどが存在するコアドメインがあり、サポートドメインは多くの場合userIdのみを必要とします。

サービスがユーザーに関するその他の詳細を必要とする場合は、そのような状況に対処する方法に関するいくつかの提案を参照してください。