我有兩種微服務，一種是用戶服務，另一種是產(chǎn)品服務，兩者都有自己的數(shù)據(jù)庫產(chǎn)品服務數(shù)據(jù)庫表user_products（id，user_id，product_id）產(chǎn)品（編號，名稱）用戶服務數(shù)據(jù)庫表User(id, name, ..)用戶與產(chǎn)品有著多對多的關系。由于user_products是僅在產(chǎn)品服務中存在的聯(lián)接表。我不確定如何為產(chǎn)品服務表創(chuàng)建休眠模型對象，以便獲得：屬于特定用戶的所有產(chǎn)品的列表產(chǎn)品所有所有者的列表不確定如何在上面兩個表的上方定義@ManyToMany關系
2 回答
哆啦的時光機
TA貢獻1779條經(jīng)驗 獲得超6個贊
分析您的問題，您是否不認為產(chǎn)品和所有者之間沒有多對多的關系。一個產(chǎn)品如何由兩個不同的所有者（用戶）擁有？通常，電子商務系統(tǒng)中的產(chǎn)品ID標識1個唯一的物理實體。即使有超過1種相似產(chǎn)品（這是實際生產(chǎn)情況），IMO每種產(chǎn)品也將具有不同的產(chǎn)品ID。
但是，讓我們考慮一下兩個實體相互依賴的不同情況。在這里，出現(xiàn)在圖中的概念是有限的上下文。
每個服務都應擁有其數(shù)據(jù)，并應對其完整性和可變性負責。每個服務應獨立存在，即具有更改和移入和移出運行時環(huán)境的能力，而不會對其他服務產(chǎn)生副作用。
讓我們舉一個更清晰的公司示例，該公司需要在其員工之間管理Project。我們可以在這里看到兩個不同的上下文（現(xiàn)在忽略所有其他與公司相關的處理）
項目
員工
如圖所示，我們無法在Project實體中直接引用Employee實體。
合適的解決方案是：假設將對象模型映射到關系數(shù)據(jù)源，而不是Project Service必須映射Employee類型，則它僅必須映射employee id屬性。
Project_Resource模型的基礎映射表不會從數(shù)據(jù)庫中實現(xiàn)Employee對象。為了獲得或變異雇員，您將利用來自雇員上下文的雇員服務API調(diào)用。
因此，必須引入更多機制來支持這種隔離。具體來說，當通過員工服務刪除員工時，其他服務如何知道這種刪除？員工服務同步調(diào)用產(chǎn)品服務將導致高度耦合。在這種情況下，應該使用異步模式來解耦其他服務（更多地用于發(fā)布事件，另一個服務可以決定是否必須采取措施）
下面的博客很好地解釋了其他用例和其他解決方案，它們描述了Bounded上下文的使用，并注意了低耦合和促進內(nèi)聚。 https://hackernoon.com/microservices-bounded-context-cohesion-what-do-they-have-in-common-1107b70342b3
添加回答
舉報
0/150
提交
取消