在微服务架构下，我要实现2种不同的微应用程序：一个用于用户管理，另一个用于任务管理。
用户微服务：
在此微型应用程序下，我定义了一个User模型，该模型将数据库中所有用户对象的信息保存在其中。
任务微服务：
在此微型应用程序下，我定义了一个Task模型，该模型将数据库中任务对象的所有信息以及任务中的用户引用保存在其中。
由于该应用程序是在微服务架构下开发的，因此User和Task模型将驻留在两个不同的微服务中，并且鉴于任何任务都包含用户引用，因此我有义务在Task微服务中也定义用户模型，这与松散耦合的概念相矛盾，并且对于整个应用程序的可维护性来说是一种不好的方法。
答案 0 :(得分：2)
在工作时，您将根据某些准则（将业务驱动或逻辑实体放在一起）将应用程序分为服务，这将导致与您提到的问题类似的问题。 我的看法是，当您使用服务时，您想控制您对该服务的看法。用户服务可以自由选择看起来合适的任务，您可以按原样使用用户，也可以更改适合于任务服务的用户模型。重要的是要决定（当然要与用户服务保持一致）。它们是用户的真理之源，而您是任务的真理。
您的用户视图是根据用户服务中所说的内容构建的，但是您可以按照自己的方式进行构建。 因此，您必须定义用户模型，但它并不紧密耦合。对您来说重要的是确保您永远不要与外界共享用户模型。始终是参考。
用户服务可以自由地向用户模型添加任何内容（如果其他人没有使用，则删除用户服务；如果其他人没有使用，则用户服务违反了合同） 而且，您可以自由选择从用户服务获得的用户响应中进行选择。
这就是两个如何解耦的方法。 如果您谈论代码冗余，那么在不同的服务中必须在哪个位置创建用户模型并进行api调用并处理故障，那是一个不同的问题，您可以通过要求服务公开带有模型和基本调用的程序包来缓解这种情况。