Database design 微服务体系结构中模型之间的松耦合

在微服务架构下，我实现了两个不同的微应用程序：一个用于用户管理，另一个用于任务管理

用户微服务：

在这个微型应用程序下，我定义了一个

用户

模型，它保存数据库中用户对象的所有信息

任务微服务：

在这个微型应用程序下，我定义了一个

任务

模型，它保存数据库中任务对象的所有信息，以及任务中的用户引用

---

由于应用程序是在微服务体系结构下开发的，

用户

和

任务

模型将驻留在两个不同的微服务中，并且鉴于任何任务都包含用户引用，我也有义务在任务微服务中定义用户模型，这与松耦合概念相矛盾，对于整个应用程序的可维护性来说是一种糟糕的方法。

当您在工作时，您会根据特定的指导原则将应用程序拆分为服务（无论是业务驱动的还是逻辑实体在一起），这将导致类似的问题，如您所述。 我的看法是，当你在做你的服务时，你想控制你对该服务的看法。用户服务可以自由地定义看起来合适的任务，您可以按原样使用用户，也可以更改适合任务服务的用户模型。重要的是你要做出决定（当然要与用户服务保持一致）。他们是用户真相的来源，你们是任务的来源

您的用户视图是根据用户服务所说的内容构建的，但您可以按照自己的方式来构建它。 所以您必须定义用户模型，但它不是紧密耦合的。对你来说，重要的是确保你永远不会向全世界分享你的用户模型。总是参考

用户服务可以自由地向用户模型添加任何内容（如果其他用户未使用，则删除，如果其他用户正在使用，则用户服务正在破坏合同） 您可以从用户服务获得的用户响应中自由选择

这就是二者是如何解耦的。 如果您谈到代码冗余，不同的服务中必须创建用户模型、进行api调用并处理故障，那么这是另一个问题，您可以通过要求服务公开带有模型和基本调用的包来缓解它