回答:
Microservicesアーキテクチャでは、それぞれが完全に独立しており、内部実装の詳細を隠す必要があります。
モデルを共有すると、マイクロサービスを結合し、各チームが制限なしにマイクロサービスを開発でき、他のマイクロサービスをどのように進化させるかを知る必要があるという最大の利点の1つを失います。各言語で異なる言語を使用することもできることに注意してください。マイクロサービスを結合し始めると、これは困難になるでしょう。
それらがあまりにも関連している場合は、@ soruが言うように実際には1つです。
関連する質問：
2つのサービスが十分に絡み合っており、DTOや他のモデルオブジェクトを共有せずにそれらを実装するのが苦痛になる場合は、2つのサービスを使用すべきではないという強い兆候です。
確かに、この例は2つのサービスとしてほとんど意味がありません。「ユーザー管理」の仕様が非常に複雑であるため、チーム全体が認証を行う時間がないほど忙しくなりすぎると想像するのは困難です。
何らかの理由でそれらが存在する場合、OAuth 2.0のように、基本的に任意の文字列を使用して通信します。
それらは、2つの別個の境界コンテキスト（ドメイン駆動設計用語）として考えることができます。認証コンテキストの「ユーザー」を他のコンテキストの「ユーザー」と相関させるために使用されるIDを除き、両者間でデータを共有しないでください。彼らはそれぞれ、「ユーザー」が何であるかの独自の表現と、ビジネス責任を実行するために必要な情報だけである独自のドメインモデルを持つことができます。
ドメインモデルは実世界の「もの」をモデル化しようとするのではなく、特定のコンテキスト（Identity / Authorization Management、Human Resourcesなど）にあるものをモデル化することを忘れないでください。
どちらもユーザーの概念を持ち、お互いの呼び出しを通じてユーザーについて話します。
@soruが言ったことにも同意します。あるサービスが別のサービスのデータを必要とする場合、それらの境界は間違っています。
素晴らしい解決策は、@ pnschofieldが思いついたことです-サービスを境界付きコンテキストとして扱うことです。
主題について話すと、簡単に言えば、共有ドメインモデルはサービスの自律性を破壊し、マイクロサービスシステムを分散モノリスに変えます。これは明らかにモノリスよりもさらに悪いです。
したがって、未解決の一般的な疑問が残っています。サービスまたはコンテキストの境界を定義する方法です。それにより、高い凝集力と疎結合の良さで繁栄します。
コンテキストをビジネス能力として扱うためのソリューションを思いつきました。より高いレベルのビジネス責任、ビジネス機能であり、全体的なビジネス目標に貢献します。これらは、組織がビジネス価値を得るために歩く必要があるステップと考えることができます。
サービスの境界を識別するときに行う典型的な一連の手順は次のとおりです。
おそらく、このテクニックの例はあなたにとって興味があるでしょう。このアプローチは非常に有益であることがわかったので、遠慮なくあなたの意見をお聞かせください。確かにそれはあなたのためにうまくいくことができます。
マイクロサービスとは「何も共有しない」ことではなく、「可能な限り共有しないこと」です。ほとんどの場合、「ユーザー」は本当に一般的なエンティティです（ユーザーが何らかの共有識別子（userId / email / phone）によって識別されるという理由だけで）。定義により共有されるこの種のエンティティ。ユーザーモデルは、1つのマイクロサービスの範囲外です。そのため、User（最も一般的なフィールド）を配置するグローバルスキーマが必要です。厳密な場合、idのみです。