我在一家全国性的公司工作，所以我们开发的软件规模很大。
我们的核心系统是基于Web的，包括webservices。我们目前正在重新设计整个项目，是时候开始项目结构了。
我们有 7 个 Web 模块，包括基于 Struts2 和 Spring 3.1 的网络项目。基于JAX-WS和Spring 3.1的Webservice核心
我的问题是，为这样的项目设计项目结构和模块化的最佳实践是什么：
如果需要，我们肯定会使用Maven和OSGi。我在想这样的事情
WebProject.war
|---Web.xml
|--- Libs
|
|--- Web Module1.jar
|--- Web Module2.jar
|--- Web Module3.jar
|--- Web Module4.jar
|--- Web Module5.jar
|--- Web Module6.jar
WebService.war
|---Web.xml
|--- Libs
|
|--- Service.jar
|--- Service2.jar
EJBProject.jar
|
|--- module.jar
|--- module2.jar
这是我个人的想法，但我们正在寻找更好的模块化的东西，以便我们可以在不影响其他模块和主项目WebProject.war的情况下工作和部署WebModule1.jar。同样，我们希望专业团队只有他们项目的代码，所以如果一个团队必须只使用他们IDE中的Service2.jar，他们将只有Service2.jar的代码和一个资源项目，其他项目已经编译好。
谢谢
模块化的关键方面是，你的模块知道的尽可能少，以便它可以在许多不同的上下文中重用。错误仅在违反假设时发生，最小化假设是最大的错误杀手。OSGi提供了像μservices这样的工具，这些工具在允许假设保持本地方面非常好。
您的布局看起来非常像一个 Web 项目，恕我直言，这是错误的，因为我们必须自己开发的大多数代码都应该独立于用于呈现它的技术。所有这些技术在不久的将来可能会发生变化，因为Web应用程序正在迅速转移到浏览器，浏览器再次成为胖客户端。也就是说，非常现代的REST接口已经感觉非常老式了，如果你看到纯消息传递正在做什么。所有这些波动性意味着您希望使模块尽可能解耦。
因此，我永远不会将任何域代码耦合到与 Web 技术耦合的库的任何内容。这些传递依赖关系将在（不久的）将来伤害您。构建小型内聚型非耦合模块，然后将它们用作乐高积木来构建您的应用程序。
我强烈建议阅读Kirk Knoernschild的"Java Application Architecture： Modularity Patterns with Example Using OSGi"。 在迁移到OSGi之前，您可以从模块化应用程序开始（如果您还没有它，我肯定会投资良好的测试覆盖率）。
如果您使用的是 servlet spec 3.0，请查看使用 Web 片段。
就您展示的结构而言，我会说不要嵌套任何东西（除了 Web 片段），WAR 可以成为 WAR（Web 应用程序包 - 基本上是一个瘦的 WAR）。 还要尽可能多地利用OSGi的μServices - 这就是乐趣开始的地方=）
像Karaf和Virgo这样的企业OSGi框架在跨越JEE-OSGi鸿沟时提供了很多支持（Equinox和Felix本身就有点准系统）。
根据您的项目要求，例如运行时的独立模块开发和更新，Maven 是最佳解决方案。它提供了对依赖项和插件的强大支持，并且看起来您的项目所需的一切都已经可用：
- 弹簧/支柱/CXF/等 maven 工件，
- 战争/罐子/等插件，
- 应用程序服务器部署/测试插件等。
- 而且，您可以仅为仅开发特定模块而不共享所有代码库的团队提供常见的 maven 工件。
- Maven 由所有持续集成服务器（Hudson/TeamCity 等）提供支持。
OSGi.如果你喜欢使用它，你必须仔细查看你当前的设计，并尝试让它适应μServices。通常，您将拥有包含 API、API 使用者和 API 提供程序的模块。它可以帮助您在团队之间分配开发（例如，一个开发 API 使用者模块，另一个开发 API 提供者模块）。如果需要，您可以将API使用者/提供者模块拆分为2+ OSGi捆绑包（即Maven模块）。
你的结构对我来说看起来不错，这是大多数项目的典型结构 - 我会给出的一个建议是版本化你的依赖项，所以例如，让你的webproject.war依赖于webmodule1-1.3说，这样可能不同的最终项目可能具有不同版本的依赖jar。
使用 maven 肯定会简化这些依赖项的管理
如果你的要求是在运行时替换依赖项，那么是的，你将不得不选择像OSGI这样的技术，但是如果你正在寻找的不是运行时模块化，我建议不要从OSGi开始，并保持堆栈更简单。
在稍微处理了OSGi并感到一些痛苦之后，我们为Spring 开发了无osgi模块化 https://github.com/griddynamics/banshun 你来了！