微服务架构共享域模型

假设我们有一个使用微服务架构的Spring Boot应用程序。每个服务都有其自己的域模型，但是每个服务必须引用一个User域对象。解决该问题的最佳方法是什么？为每个服务仅拥有一个userId会更好，然后在需要时向用户服务询问用户详细信息，或者为所有微服务都拥有一个共享域库会更好吗？

如果您确实希望微服务能够从可伸缩性，松散耦合以及对每个服务的轻松独立修改中受益，那么您应该在最大程度上坚持使用微服务。

整体架构

我认为最好的方法是：

• 具有用于一般用户信息管理的微服务；
• 在每个微服务中保留特定于微服务的用户信息（例如，配置文件，授权，首选项）（使用通用ID的参照）

补充阅读：

• 本文很好地描述了这种体系结构和基本原理，以及授权的具体情况。
• 本文介绍了用于用户身份管理的挑战和解决方案，以避免所有服务访问同一存储库。
• 本文介绍了如何使用JWT在服务之间传递用户身份（注意，可以在id令牌中提供一些基本信息，这避免了在登录后再次查询用户服务，至少对于非常基本的用户而言）信息）。

代码共享

现在，如果您同意上述解决方案，则我们有一个用户微服务（为用户封装域模型），所有其他服务都是同一微服务的使用者。然后的问题是要知道是否要：

• 遵循强分离的教条以允许灵活和不同的发布周期，每个微服务都可以重塑消费者代码
• 或考虑将用户代码作为库的一部分共享，因为此基本信息是“机箱”基础结构模式的扩展。

我不会对此持明确立场，因为在此代码共享主题上有意见不明的意见战，而且我认为我无法采取客观立场。这里已经是一些其他阅读内容：

• 本文认为没有最佳的解决方案，这完全取决于您的目标
• 本文的立场是，代码共享只有建立牢固的耦合才是不好的，并且代码共享可以带来一些协同作用
• 本文（针对大规模实施微服务的人员）坚持认为必须拥有单独的构建，以及旧代码的潜在退役问题。具有用于共享库消费与固体形式的管理并不能阻止这些好的做法。

我个人的观点是，您不应在用户提供者和用户-消费者之间共享代码，以避免紧密的耦合。但是，如果您具有强大的版本管理功能，则可以在使用者之间共享用户使用代码。这种方法将具有一些优点：

• 可以使用共享用户消费代码的不同版本来构建不同的用户消费微服务（只要这些版本与独立的用户提供程序兼容）。重塑轮子的灵活性相同，但生产率更高。
• 您可以独立更改用户提供者的服务，而不会影响消费者。
• 如果在使用方发现了一个错误，则可以对其进行更正一次，并以最合适的方式部署所有使用方（这要感谢版本管理）。这甚至可能导致更高的服务质量。
• 如果由于某种原因您必须更新用户提供者API，则可以更快速地部署更新的用户消耗。如果您在过渡期间使新旧提供者服务保持活动状态，则这种共享可能性可以使较早版本的消费者提供者更快地停用。

如果可能，我会避免使用共享库。问问自己每个服务需要哪些用户属性？通常，存在一个核心域，围绕着用户的大多数行为将生活在其中，而支持域通常只需要一个userId。

如果您的服务需要有关用户的其他详细信息，请查看此处有关如何处理此类情况的一些建议