不同微服务之间的共享域模型

想象一下两种不同的微服务的场景。一个负责处理服务中的身份验证，另一个负责用户管理。他们都有用户的概念，并且会通过相互调用来谈论用户。

但是，“用户”的域模型将属于哪里？它们在数据库级别上对用户的身份都有不同的表示吗？当我们有一个UserDTO可以用于API调用时，它们各自的API是否都有一个呢？

对于这种架构问题，公认的解决方案是什么？

在微服务架构中，每个架构都绝对彼此独立，并且必须隐藏内部实现的细节。

如果共享模型，那么您将耦合微服务并失去最大的优势之一，即每个团队都可以不受限制地开发微服务，并且无需了解如何发展其他微服务。请记住，您甚至可以在每种语言中使用不同的语言，如果您开始使用微服务，这将很困难。

如果他们之间的联系太紧密，也许他们真的像@soru说的那样。

相关问题：

• 从另一个微服务“拥有”的数据库中读取数据为何如此糟糕
• 您如何处理微服务架构中的共享概念？

如果两个服务充分地交织在一起，以至于在不共享DTO和其他模型对象的情况下实现它们是很痛苦的，那就是一个很好的信号，您不应该拥有两个服务。

当然，该示例作为两个服务没有多大意义。很难想像“用户管理”的规范如此复杂，以至于整个团队都非常忙，以至于他们没有时间进行身份验证。

如果由于某些原因，那么它们将使用基本上是任意字符串的通信方式，如OAuth 2.0中那样。

您可以将它们视为两个单独的有界上下文（以域驱动设计的话来说）。除了用于将身份验证上下文的“用户”与另一个上下文的“用户”相关联的ID外，它们之间不应共享任何数据。他们每个人都可以拥有自己的“用户”代表以及自己的域模型，这些模型只是履行其业务职责所需的信息。

请记住，域模型并不是试图为现实世界的“事物”建模，而是要在特定的上下文中（例如身份/授权管理或人力资源等）建模。

他们都有用户的概念，并且会通过相互调用来谈论用户。

我也同意@soru所说的话。如果一项服务需要另一项服务的数据，那么它们的界限就是错误的。

@pnschofield提出了一个很好的解决方案-将您的服务视为有界上下文。

简短地谈论这个主题：共享域模型扼杀了服务自治，将您的微服务系统变成了分布式整体。显然，这甚至比整体而言还要糟糕。

因此，仍然存在一个尚未解决的一般性问题-如何定义服务或上下文边界，以使它们在高内聚性和松散的耦合优势下蓬勃发展。

我想出了一种解决方案，将我的环境视为业务能力。这是更高级别的业务责任，业务功能，对总体业务目标做出了贡献。您可以将它们视为您的组织为了获得业务价值而需要采取的步骤。

在确定服务边界时，我通常采取的步骤如下：

1. 识别更高级别的业务能力。通常，它们来自相同域的组织之间是相似的。您可以了解一下波特的价值链模型。
2. 在每个功能中，进行更深入的研究并确定子功能。
3. 注意功能之间的通信。查看组织的工作。通常，沟通是集中在能力范围内的，然后将其工作结果通知其余人员。因此，在实施技术体系结构时，您的服务也应该通过事件进行通信。这有多重积极的后果。通过这种方法，您的服务是自治的和凝聚力的。他们不需要同步通信和分布式事务。

您可能会对这种技术的一个示例感兴趣。不要犹豫，让我知道您的想法，因为我发现这种方法确实有利可图。当然，它也可以为您解决。

微服务不是关于“什么都不共享”，而是“尽可能少地共享”。在大多数情况下，“用户”实际上是常见的实体（只是因为用户是由某些共享标识符-userId / email / phone标识的）。这种实体按定义共享。用户模型不在微服务范围之内。因此，您必须具有一些全局架构，应该在其中放置U​​ser（只是他们最常用的字段）。在严格的情况下，仅是id。