マイクロサービスに大きなモノリシック電子商取引アプリケーションを導入する途中です。 （Java、Spring、Hibernateを使用する予定です）モノリシックアプリケーションでは、フルフィルメントアイテムと永続アイテムという概念があります。私たちの計画は、充足アイテムCRUD操作と永続アイテムCRUD操作を2つの別々のAPIに分割することです。しかし、両方のAPIが必要となる共通のエンティティ/テーブルがあります。このシナリオを処理する最良の方法は何ですか？マイクロサービスの共有エンティティ/テーブル設計
現在、テーブルで開くオプションの1つは、1つのマイクロサービスがエンティティ/テーブルを所有し、他のマイクロサービスでREAD ONLYオブジェクト参照を持つことです。これには何らかの欠点がありますか？
展開方法に大きく依存します。両方のAPIをバンドル/パッケージ化する場合は、両方が同じエンティティ（実際にはエンティティを複製すべきではありません）を共有しても問題ありません。私はすべてのエンティティとリポジトリ/ DAOを1つの共通のバンドル/パッケージに入れて、クラッシュした操作（他のビジネスロジックなし）のためにさまざまなAPIを公開することを好むでしょう。そして、私の他のコンポーネントはこれらのAPIを消費し、ビジネスロジックを持ちます。
マイクロサービスが最終的な整合性の下で動作できない状況を除いて、本当に欠点はあまりありません。このような場合でも、非共通マイクロサービスの依存関係を追加して、必要に応じて共通のマイクロサービスに関連する更新プログラムを照会する方法を知ることができます。これは理想的ではありません。
あなたのユースケースのメディエータメカニズムのいくつかの形式を導入する必要があります。 JMSブローカーのようなものは、1つのマイクロサービスが他の関心のあるマイクロサービスに何かが発生したことを通知し、それぞれが独自の方法でイベントを処理できるようにする理想的な選択肢です。
たとえば、顧客のID、名前、住所、おそらくは与信限度額を含むCustomerMessageを提出することができます。また、1つのマイクロサービスはIDと名前にのみ関係します。クレジット制限。