我正在构建一个分布式应用程序，它基于前端（阅读：面向网络）HTTP API，它调用底层（阅读：非面向网络）Thrift 服务。
例如，我可能有：
所有单独的服务都依赖于核心服务，HTTP 面向 Web 的 API 也是如此。我现在将其作为一个多模块项目，但我希望每个项目都是分开的（并在他们自己的存储库中进行跟踪 - 尽管我知道我仍然可以通过多模块构建来做到这一点）。
tl;博士-
拥有一个单独构建然后推送到 maven 存储库（然后作为 jar 包含在其他项目中）的模块（核心服务）是一种常见的构建实践，还是在这种情况下做一个更好多模块项目？
就我个人而言，我尽量避免使用多模块项目，因为如果您使用的是Maven 发布插件，那么您将被锁定为一起发布所有模块。
虽然这听起来很方便，但当您需要对其中一个模块进行错误修复发布时，就会出现问题 - 您最终会发布所有模块，而不仅仅是带有错误修复的模块，即使它们没有发布也会增加它们的版本改变了。
如果你在多模块项目中运行 CI，你也会受到打击——你的构建通常会运行你根 pom 中的所有模块，但如果你在一个特定的模块中工作，你最终会受到构建这些模块的影响这并没有改变，实际上失去了模块化本应提供的一些好处。
所以，使用独立的模块，但是，这是重要的一点，创建每个使用的通用“依赖”pom。
“依赖” pom 是标准化项目中所有依赖项的 pom，不同之处在于这些依赖项是在dependencyManagement部分而不是dependencies部分中指定的（它还设置标准插件配置等）。这允许您的项目 pom 将依赖项 pom 指定为其父项，然后声明他们需要的依赖项减去版本，这些版本是从“依赖项”pom 中提取的，因此在您的项目中标准化。
如果您仍然担心能够构建所有内容，这可以通过一个简单的批处理文件来实现。
我会说多模块项目更好。如果将核心服务放在存储库中，开发人员应该关心版本。Developer1 需要旧服务，但 Developer2 更新服务。
多个分支也可能是一个问题。
当所有单独的模块彼此具有相同的生命周期时，应该支持多模块构建......换句话说，当它们总是一起发布时，它们的版本号一起增加等等。
OSS 世界中一个很好的例子是apache camel 项目。例如，所有捆绑的组件作为单独的模块存在，可以单独包含在您的项目中，但与骆驼核心发行版的生命周期相关联。
Maven 多模块构建在将项目放入 CI 或将它们加载到 IDE 中时提供了一些便利，但一般来说，如果所有单独的模块不共享相同的生命周期，那么多模块项目不太合适
原则上，最好让您的项目尽可能独立地发展。然而，这更像是一个组织问题，而不是技术问题。说到底，你的项目结构应该与你的组织保持一致。
这归结为保持项目独立，并让依赖项目通过本地存储库管理器管理依赖关系，如果它们由不同的人维护，或者在不同时间发布它们是有意义的。否则，使用多模块项目结构可能会更好。
在我们的项目中，我们进行了一种中间选择：我们确实有一个多模块结构，但所有项目都位于独立的 Subversion 存储库中，因此它们可以单独分支，我们使用聚合器项目来选择如何混合和匹配来自不同分支的项目，svn:externals以便为特定客户创建定制版本。
缺点是维护类似的结构既复杂又耗时。我们开发了大量脚本来部分自动化这些任务。这是特别繁重的，因为Maven release plugin它无法处理通过 Subversion 外部挂接的模块。