我在共享数据库中有两个微服务。例如用户管理服务和组织管理服务。两种服务都有自己的实体。
现在的问题是我必须管理组织与用户之间的一对多关系，我几乎没有疑问的解决方案。
解决方案：
我可以在两个服务中复制实体（但是如果实体中有任何更改（例如添加或删除属性），我必须注意 所有服务）。
我可以为实体创建一个共享jar（但是如果实体发生更改，则必须重新启动两个服务）
我可以触发纯
SQL查询。
任何其他建议或帮助都会挽救我的生活。
请给我建议一个更好的解决方案！
答案 0 :(得分：2)
您似乎尝试遵循（好的）建议，即微服务应维护自己的数据并尽可能与其他服务独立。以此为前提的领域驱动设计可提供有用的建议。
您的微服务管理一个（或一组）聚合。集合是实例的集群
每个聚合只有一个聚合根。它的组件只能通过“聚合根”方法进行访问。这使聚合根可以确保一致性。
聚集的组合最终只会保持一致，即它们在给定的时间点可能不一致，但最终会变得一致。这样可以使聚合保持简单，因为它们无需担心其他聚合的状态。为了允许聚合仅通过id相互引用。
这就是您将其应用于实际情况的方式。
如果您为微服务设计Person实体，则可能会发现它们没有相同的属性。例如，用户管理服务可能需要Person的散列密码。组织管理服务可能具有其他属性，甚至可能除了ID之外根本没有其他属性。
因此，您应该为此设置单独的类。现在，有两种不同的方法可以将这两种聚合结合起来，具体取决于它们的设计方式。让我们从最简单的开始：
如果Person完全归一项服务所有，则其他所有内容都只需要ID。在Web应用程序中，您可以（可能应该）仅包含人员资源的链接，并使用Person的拥有服务加载要显示的任何详细信息。您也可以在后端执行此操作，但这是另一天的决定。
如果两个服务都具有共同的属性（例如，您可能希望在组织管理服务中包括诸如name之类的基本信息，那么即使其他服务不可用，您也可以显示易于阅读的内容。
在这种情况下，您可以使用事件来通知服务它们需要应用于其实体版本的更改。
请注意，您希望将所有事件处理与其余服务分离开来，以便于此。
a）事件基础结构出现问题不会导致服务尝试发布事件的问题。
b）您有一个适当的流程来在事件基础结构一段时间不可用时同步信息。
要维护的一个重要属性是，每个属性只能由一项服务更改。如果您不坚持认为，如果属性值出现差异，则很难找出哪个是正确的变体。