我们正在使用不同的架构层（例如域、接口、基础架构和应用程序）构建一个小型应用程序。这遵循洋葱 DDD 模型。现在我想知道将应用程序拆分为多模块 Maven 项目是否有任何好处。据我现在所见，这似乎使事情变得比需要的更困难。整个应用程序将作为单个 WAR 文件部署到 Tomcat 容器中。
【问题讨论】：
标签： java web-applications maven multi-module
使用多个模块会迫使您拥有依赖关系的层次结构。您有一个独立的模块，不依赖于您的任何其他模块。您还有另一个仅取决于此。它可能看起来比允许任何东西依赖于其他任何东西更难，但这种方法会导致一团糟的依赖关系，以后很难修复。
如果您尝试遵循分层模型，我建议您将每一层放在不同的模块中。这将确保您不会试图破坏模型。
【讨论】：
如果您想在另一个项目中重用您的类，或者如果您的项目部署在不同的配置中，则将您的项目拆分为多个 maven 项目非常有用。
也许考虑一个 web 服务 - 如果您托管服务器，您可以为您的域类（模型）和您的端点接口构建一个可供服务器和客户端使用的项目。服务器将是构建到 WAR 的另一个项目。
为了开发更多客户，也可以使用第一个项目。
使用父项目对常见项目（如日志记录）以及不同的配置文件和构建配置进行依赖管理。
【讨论】：
拆分您的应用程序对以下情况有意义：
当项目的某个部分需要新功能或错误修复时，您可以简单地专注于该模块并为其运行测试。编译所有代码的一小部分并仅运行相关测试可以加快您的工作速度。
您可以在不同的项目中重复使用模块中的代码。假设您的项目包含一些编写良好且足够通用的邮件发送代码。如果您以后有另一个需要邮件发送功能的项目，您可以简单地重用现有模块或在其上构建（通过将其添加为依赖项在另一个模块中）。
从长远来看更易于维护。也许现在它看起来像一个小项目。几个月后情况可能会有所不同，然后您需要进行更多重构以将其拆分为逻辑单元（模块）。
概念清晰（由 Adriaan Koster 添加）。
关于 WAR：您可以有一个组装模块，它将所有东西放在一起并从所有相关模块生成最终的 WAR 文件。
最初，这似乎需要更多工作，但从长远来看，模块化项目更易于使用和维护。大多数理智的开发人员更喜欢这种方法。
【讨论】：
据我所知，Maven 对 WAR 依赖项帮助不大。正如你所说的单一 WAR，这绝不应该是一个问题。
您可以将 java 类分成几个“jar”子模块，但如果您将 WAR 项目拆分为几个较小的 WAR，使用某种“重叠”的打包方式会变得复杂。
只是信息，我们的一个项目，它包含的网页太多，所以我们决定将其拆分为几个 WAR 子模块，但是，会话不会在部署的不同 WAR 之间共享，我们不会使用 Kerberos 的东西.最后，我们修改了很多 Glassfish、Jetty、MyFaces 等的源代码，使它们能够解析 JAR 中的 web.xml 内容。并将整个项目转换为Facelets 2.0（避免依赖JDK tools.jar和自定义资源处理程序），唯一的原因是将WAR子模块更改为JAR子模块，并将所有webapp/pages移动到类资源中。所以结论是，Maven 对 JAR 依赖项做得很好，但没有 WAR 或单个 WAR。
编辑您可以将applicationContext.xml 放在基本子模块之一中，并通过classpath:com/example/applicationContext.xml 导入它。 Spring 3.0 也有注解支持，你可以让 spring 自动扫描它们而不是在 xml 中声明它们。
【讨论】：
简短的回答：今天它很小，明天它会变得更大，维护、重用、扩展、与其他系统集成等更复杂
【讨论】：