微服务架构中的Hibernate Join表

Question

我有两种微服务，一种是用户服务，另一种是产品服务，两者都有自己的数据库

产品服务数据库表

user_products（id，user_id，product_id）产品（编号，名称）

用户服务数据库表

User(id, name, ..)

用户与产品有着多对多的关系。由于user_products是仅在产品服务中存在的联接表。我不确定如何为产品服务表创建休眠模型对象，以便获得：

1. 属于特定用户的所有产品的列表

2. 产品所有所有者的列表

不确定如何在上面两个表的上方定义@ManyToMany关系

Answer 1

分析您的问题，您是否不认为产品和所有者之间没有多对多的关系。一个产品如何由两个不同的所有者（用户）拥有？通常，电子商务系统中的产品ID标识1个唯一的物理实体。即使有超过1种相似产品（这是实际生产情况），IMO每种产品也将具有不同的产品ID。但是，让我们考虑一下两个实体相互依赖的不同情况。在这里，出现在图中的概念是有限的上下文。每个服务都应拥有其数据，并应对其完整性和可变性负责。每个服务应独立存在，即具有更改和移入和移出运行时环境的能力，而不会对其他服务产生副作用。让我们举一个更清晰的公司示例，该公司需要在其员工之间管理Project。我们可以在这里看到两个不同的上下文（现在忽略所有其他与公司相关的处理）项目员工如图所示，我们无法在Project实体中直接引用Employee实体。合适的解决方案是：假设将对象模型映射到关系数据源，而不是Project Service必须映射Employee类型，则它仅必须映射employee id属性。Project_Resource模型的基础映射表不会从数据库中实现Employee对象。为了获得或变异雇员，您将利用来自雇员上下文的雇员服务API调用。因此，必须引入更多机制来支持这种隔离。具体来说，当通过员工服务删除员工时，其他服务如何知道这种删除？员工服务同步调用产品服务将导致高度耦合。在这种情况下，应该使用异步模式来解耦其他服务（更多地用于发布事件，另一个服务可以决定是否必须采取措施）下面的博客很好地解释了其他用例和其他解决方案，它们描述了Bounded上下文的使用，并注意了低耦合和促进内聚。 https://hackernoon.com/microservices-bounded-context-cohesion-what-do-they-have-in-common-1107b70342b3