我們正在將一個巨大的單一電子商務應用程序分解爲微服務。 （我們計劃使用Java，Spring，Hibernate）我們在單一應用程序中有履行項目和持久項目的概念。我們的計劃主要是將履行項目CRUD操作和持久項目CRUD操作分解爲兩個獨立的API。但是我們有一些共同的實體/表，這兩個API都將最終需要。處理這種情況的最佳方法是什麼？微服務的共享實體/表設計
當前在表上打開的一個選項是讓一個微服務擁有實體/表，並在其他微服務中擁有READ ONLY對象引用。這有什麼缺點嗎？
取決於您的部署策略。如果打算將兩個API捆綁/打包成一個，那麼它們就可以共享相同的實體（事實上，你不應該複製實體）。我希望將所有實體和存儲庫/ DAO合併爲一個公共的bundle /包，以便公開用於crud操作的各種API（沒有任何其他業務邏輯）。然後，我的其他組件將使用這些API並將具有業務邏輯。
確實沒有太多的缺點，除非微服務不能在下最終一致性下運行。即使在這些情況下，您也可以隨時添加非常用微服務的依賴關係，以瞭解如何在必要時查詢常用微服務以獲取相關更新，儘管這並不理想。
雖然您可能需要爲您的用例引入某種形式的中介機制。像JMS經紀人這樣的理想選擇，將允許一個微服務向其他感興趣的微服務通知發生了什麼事情，以便他們各自以他們自己的方式處理事件。
例如，可以提出一個CustomerMessage包含客戶的ID，名稱，地址，也許信用限制和一個微服務可能只關心身份證和名稱，而另一個可能也有興趣的地址和信用限額。