我有一个带有多个Spring服务的web应用程序(它们每个都有自己的ear和web控制器)，它们通过REST调用相互通信。有些不同的服务使用相同的数据pojo。现有的代码只是在不同的服务中有这些数据对象的副本。
例如，我的/users服务有一个myApp.users.UserData对象，我的/emails服务调用/users/{userId}并将结果保存为myApp.emails.UserData对象。这两个对象是相同的
这里的问题是我必须保持myApp.emails.UserData和myApp.users.UserData同步，因为实际上它们表示相同的信息，并且意味着"相同"。类。如果我在emails.UserData中更新了一个字段的名称，我最好记得在users.UserData中更新它，否则事情会破裂。
我知道我可以创建一个名为SharedDataObjects的共享依赖，在那里定义myApp.sharedDataObjects.UserData，然后让两个版本都引用它。然而，出于某种原因，我的直觉是，这不是一个好的解决方案……(也许是这样?)
发现重复(或几乎重复)的代码并尝试消除重复总是很诱人的。在这个方向上，一个明显的路径是创建一个共享库(或模块)，并让不同的服务(或应用程序)依赖于它。
然而，这样做会增加服务/应用程序/模块之间的耦合，这在许多上下文中有其自身的一组缺点。特别是在微服务架构*中，这种耦合常常会导致令人头疼的问题。它甚至会导致失去使用微服务*的价值。如果两个服务*应该是独立但集成的，则它们具有某种集成协议。例如，对于REST服务，几乎总是HTTP和JSON**。通过引入共享库，您以二进制方式将它们耦合起来，与HTTP和JSON分开(并且比HTTP和JSON绑定更多)。情况不太好;经验给了我们许多人痛苦的教训。
相反，应该关注每个服务公开的公共接口，并在需要时使用适当的版本控制来改进这些接口。不要担心一些看起来重复的类，特别是如果它们是贫血的pojo;与应该是独立的紧密耦合的服务集相比，这是一个次要的问题。
并不是说共享代码库本质上是不好的，它们不是，它们在很多方面都有真正的价值。相反，我的观点是，您需要确保每个服务都维护自己对重要事物的定义，以便每个服务尽可能保持独立，并尽可能独立发展。顺便说一下，这在某种程度上与有界上下文的概念有关;如果你正在使用微服务，你可能需要阅读更多关于它的内容*.
*或任何你称为独立管理的服务/模块/应用程序的架构
**也可以是某种消息传递/排队平台，作为另一个例子