Maven多模块切割

Question

我们正在为我们软件的组件使用多模块项目。子模块扩展到 api 和实现。优点是其他maven项目只能导入API部分，而不会看到实现类。

这是最佳做法吗？它不是很精细，最终可能导致我们大包装。我更喜欢分层方法，这意味着客户端，逻辑，持久性等模块。每个都可以有一个不同的 api 和一个实现模块。那会不会太多，因为这意味着有6个模块而不是2个？

Answer 1

将界面作为一个单独的模块对我来说似乎是一个很好的方法。它使您的依赖项更加清晰，并且可以帮助您的代码避免与实现类的不适当的耦合。如果你正在做动态类实例化这样的事情，你可能仍然需要对实现的运行时依赖性，但是这样更宽松，所以你不会在那里遇到那么多麻烦。

我认为没有理由试图保持模块的数量很少;它们只是引入的结构，以使其更清楚地发生了什么，并强制执行可与之交互的内容。您甚至可以使用多个模块，这些模块可以在特定的rôles中使用，这样您就可以（例如）支持持久层中特定数据库的怪癖，实际使用的模块由正在使用的Maven配置文件决定。 （在我的代码中，我使用它来从大多数独立于平台的部分中分离出代码的几个特定于平台的部分。）

Answer 2

6个模块应该不是问题。我从事一个有50多个模块的项目，没有模块数量引起的问题。

更改模块之间的范围和依赖关系可能会让人感到有些困惑，当你只使用java包加上ruled来获得JDepend或Structure101等工具强制执行的允许依赖时，这会更容易（但不容易）。

因此，我会为我想要部署或不独立于其他内容部署的内容创建一个模块。

我不会创建模块只是为了防止应用程序各部分之间的依赖关系，而是使用其他工具。

Answer 3

我们在使用大约200个模块（捆绑包）的osgi项目的几年中学到的是基于类似的UseCases（登录 - 会计 - 存储）而不是逻辑层（前端 - 逻辑 - 持久性）更好地切割捆绑包

如果某个模块开始有重复代码（比如jdbc / orm stuff），那么我们添加一个新的“技术”模块，完全不了解我们的业务（而不是持久层），我们将它导入到持久层需要它的模块。

Answer 4

目前尚不清楚为什么要从应用程序的所有层导出API。通常在3层GUI中 - ＆gt;服务 - ＆gt; DAO结构（这与您的客户有关 - ＆gt;逻辑 - ＆gt;持久性？），您可能希望将服务层导出为其他应用程序的编程API，但GUI可能太过耦合到实现值得有一个单独的API。