大型企业 Java 应用程序 - 模块化答案

【问题标题】：Large Enterprise Java Application - Modularization大型企业 Java 应用程序 - 模块化
【发布时间】：2012-04-30 08:22:22
【问题描述】：

我在一家全国性的公司工作，所以我们开发的软件规模很大。

我们的核心系统是基于 Web 的，包括 webservices。我们目前正在重新设计整个项目，是时候开始项目结构了。

我们有 7 个网络模块，包括基于 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 的代码和其他资源项目项目已经编译。

谢谢

【问题讨论】：

对您的“全国性公司”感到好奇。哪个国家？？
哈哈！人口少于多米尼加共和国佛罗里达州的国家。

标签： java jakarta-ee web-applications module osgi

【解决方案1】：

模块化的关键方面是您的模块知道的尽可能少，因此它可以在许多不同的上下文中重复使用。错误仅在违反假设时才会出现，最小化假设是最大的错误杀手。 OSGi 提供了诸如 µservices 之类的工具，这些工具在允许假设保持本地化方面非常出色。

您的布局看起来非常像一个网络项目，恕我直言，这是错误的，因为我们必须自己开发的大多数代码都应该独立于用于呈现它的技术。所有这些技术都可能在不久的将来发生变化，因为 Web 应用程序正在迅速转向浏览器，浏览器再次成为胖客户端。 IE。如果您看到纯消息传递正在做什么，那么非常现代的 REST 接口已经感觉非常过时了。所有这些波动性意味着您希望使您的模块尽可能地解耦。

因此，我永远不会将任何域代码与任何与与 Web 技术耦合的库耦合的东西耦合。这些传递依赖将在（不久的）将来伤害你。构建小的内聚解耦模块，然后将它们用作乐高积木来构建您的应用程序。

【讨论】：

【解决方案2】：

我强烈推荐阅读Kirk Knoernschild 的"Java Application Architecture: Modularity Patterns with Examples Using OSGi"。您可以先将应用程序模块化，然后再迁移到 OSGi（如果您还没有，我肯定会投资于良好的测试覆盖率）。

如果您使用的是 servlet 规范 3.0，请考虑使用 web-fragments。

就您所展示的结构而言，我想说不要嵌套任何东西（网络片段除外），WAR 可以变成 WAB（网络应用程序包 - 基本上是一个瘦 WAR）。还尽可能多地利用 OSGi 的 μServices - 这就是乐趣开始的地方 =)

当您跨越 JEE-OSGi 鸿沟时，像 Karaf 和 Virgo 这样的企业 OSGi 框架提供了很多支持（仅 Equinox 和 Felix 就有点接近准系统了）。

【讨论】：

本书链接有这个问题的所有答案，很好的资源，谢谢
@gersonZaragocin，同意 - 我特别喜欢它讨论模块化原则而不强制 OSGi..（但确实指出了 OSGi 是多么棒）

【解决方案3】：

根据您的项目要求，如独立模块开发和运行时更新，Maven 是最佳解决方案。它提供了对依赖项和插件的强大支持，看起来您项目所需的一切都已经可用：

弹簧/Struts/CXF/等。 Maven 工件，
WAR/JAR/等。插件，
应用服务器部署/测试插件等
您可以只为只开发特定模块而不共享所有代码库的团队提供常见的 Maven 工件。
所有持续集成服务器（Hudson/TeamCity 等）都支持 Maven

OSGi。如果您喜欢使用它，您必须仔细查看您当前的设计并尝试使其适应 μServices。通常，您将拥有带有 API、API 消费者和 API 提供者的模块。它可以帮助您更多地在团队之间拆分开发（例如，一个开发 API 消费者模块，另一个 - API 提供者模块）。如果需要，您可以将 API 使用者/提供者模块拆分为 2+ 个 OSGi 包（即 Maven 模块）。

【讨论】：

【解决方案4】：

您的结构在我看来确实不错，这是大多数项目的典型结构 - 我会给出的一个建议是对您的依赖项进行版本控制，例如，让您的 webproject.war 依赖于 webmodule1-1.3，这样说可能不同的最终项目可能有不同版本的依赖 jar。

使用 maven 肯定会简化管理这些依赖项

如果您的要求是在运行时替换依赖项，那么是的，您将不得不使用像 OSGI 这样的技术，但是如果您正在寻找的不是运行时模块化，我建议不要从 OSGi 开始并保留堆栈更简单。

【讨论】：

如果你想让事情变得更简单，我会从 OSGi µservices 开始，而不是包括当今网络领域的巨大堆栈......

【解决方案5】：

在处理了一点 OSGi 并感到有些痛苦之后，我们为 Spring 开发了 osgi-less 模块化 https://github.com/griddynamics/banshun 你好！

【讨论】：