spring boot微服务maven体系结构

我目前正在用微服务架构构建一个spring引导应用程序。 我正在寻找干净的方法来重用代码

我的想法是提取共享模块中的公共代码。 （例如，微服务中的模型类继承自的基类、在任何mvc控制器中重用的接口、对每个绑定上下文相同的域代码）。 具体实现和仅服务的模型类等位于子模块（微服务）级别

我正在用maven构建东西，同时也在管理依赖关系。我的问题是如何在这样的设置中构造maven模块和依赖项

共享库到哪里去了？如何以及何时通过依赖关系构建和引用它们？ 使用BOM来管理依赖项，并且只在需要时覆盖MicroService中的特定版本，这样好吗？ bom是如何包含的？它是如何和何时建成的

我可以想出一种我并不喜欢的处理方法：

拥有一个（超级父级）maven pom，该pom处理依赖关系管理，可以包含在具有导入范围的子模块（微服务）中。（物料清单）

微服务POM构建其所有依赖项（包括BOM和共享模块）

问题：

当为构建依赖项声明子模块时，pom也必须是pom类型，因此对于每个微服务模块，我还需要一个父pom

如果超级父级或BOM包含声明所有子模块（微服务）的模块部分，我无法从ms级别构建它，因为会存在循环依赖关系

为什么我还要在bom表中声明子模块？因为在一些IDE（如Intellij）中，maven插件/支持在结构概述中包含子模块

你能不能给我一些好的建议，让我以一种可靠和干净的方式处理maven架构的微服务？（尽可能减少代码/配置重复、性能构建等）

---

谢谢

对于微服务体系结构，您首先应该关心的是服务之间的隔离。这意味着你应该尽可能少地分享

在过去的6-7年里，我尝试了不同的方法，我可以自信地说

• 不要将父pom用于不同的微服务。每个微服务都可以根据自己的需要使用相同库的不同版本。拥有父pom最初听起来可能很方便，但从长远来看，它会为隔离带来重大问题

• 永远不要试图关注微服务之间的代码重用。这并不意味着您不能使用实用程序库等，但共享模型类等将使微服务相互绑定，这将严重损害自由/隔离。相反，您应该依赖于微服务之间的适当契约

---

我看到您的方法主要是为了实现方便，但随着时间的推移，还有其他一些事情您应该更加关注，比如部署/发布、维护、，测试可能因缺乏适当隔离而受到损害的组件。

对于微服务体系结构，您应该首先关注的是服务之间的隔离。这意味着你应该尽可能少地分享

在过去的6-7年里，我尝试了不同的方法，我可以自信地说

• 不要将父pom用于不同的微服务。每个微服务都可以根据自己的需要使用相同库的不同版本。拥有父pom最初听起来可能很方便，但从长远来看，它会为隔离带来重大问题

• 永远不要试图关注微服务之间的代码重用。这并不意味着您不能使用实用程序库等，但共享模型类等将使微服务相互绑定，这将严重损害自由/隔离。相反，您应该依赖于微服务之间的适当契约

---

我看到您的方法主要是为了实现方便，但随着时间的推移，您还应该更多地关注其他事情，如部署/发布、维护、组件测试，这些都可能因缺乏适当的隔离而受到损害。

我理解共享模型类（或基类）和继承意味着耦合。我现在面临的主要问题是，我需要在它们之间共享一些部分，例如在任何mvc组件中重用的业务逻辑接口等。因此，对于您所称的“实用程序库”。。。如何在microservice maven多模块设置中管理此依赖关系？我是否必须构建完全隔离的工件，并将其推送到例如artifactory，还是将其构建为每个所需微服务的依赖项是可靠的？您所说的“业务逻辑重用”是什么意思？当我提到实用程序库时，我的意思是要有一些特定的实用程序函数，这些函数不包含任何业务相关的东西，只用于非常一般的问题。如果你也是这个意思，那么你提出的方法是好的。如果您谈论的是一个库，它包含与业务相关的内容，作为不同微服务之间的合同，那么我会说这会引起几个问题。在微服务中共享业务逻辑的正确方法是根本不共享它，让负责的微服务来处理它并提供结果。是的，我指的是业务逻辑中使用的通用东西。很抱歉给你带来了困惑。您将如何使用maven处理这样一个库的构建和依赖关系管理？我是否应该将它作为一个独立的项目完全解压缩？构建和部署过程将需要更多的开销。在短期内，我希望避免这种情况。是的，您应该像在apache commons库中一样将其作为一个单独的库。但是从你的问题来看，我仍然觉得你想在两个不同的版本中更改这个库的依赖关系