我为一家全国性公司工作,因此我们开发的软件规模很大。
我们的核心系统是基于网络的,包括webservices
。我们目前正在重新设计整个项目,并且是启动项目结构的时刻。
我们有7个网络模块,包括基于Struts2
和Spring 3.1
的网络项目。基于Webservice
和JAX-WS
Spring 3.1
核心
我的问题是为这样的项目设计项目结构和模块化的最佳实践是什么:
如果需要,我们肯定会使用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
这是我个人的想法,但我们正在寻找更好模块化的东西,以便我们可以在不影响其他模块和主项目WebModule1.jar
的情况下工作和部署WebProject.war
。此外,我们希望专业团队只拥有其项目的代码,因此如果团队必须仅在Service2.jar
中使用IDE
,那么他们将只拥有Service2.jar
的代码和已编译其他项目的资源项目。
由于
答案 0 :(得分:8)
模块化的关键方面是您的模块尽可能少地了解它,以便它可以在许多不同的上下文中重用。只有在违反假设时才会出现错误,最小化假设是最大的错误杀手。 OSGi提供了像μservices这样的工具,它们非常适合允许假设保持在本地。
你的布局看起来非常像一个网络项目,因为我们必须自己开发的大多数代码都应该独立于用于呈现它的技术。由于Web应用程序正迅速转向浏览器,所有这些技术很可能在不久的将来发生变化,浏览器再次成为胖客户端。即如果您看到纯消息传递正在做什么,那么非常现代的REST接口已经感觉非常老式。所有这些波动性意味着您希望尽可能地使模块分离。
因此,我永远不会将任何域代码耦合到与耦合到Web技术的库相关联的任何内容。这些传递依赖会在(近)未来伤害你。构建小型有粘性的非耦合模块,然后将它们用作乐高积木来构建您的应用程序。
答案 1 :(得分:6)
我强烈建议您阅读Kirk Knoernschild的"Java Application Architecture: Modularity Patterns with Examples Using OSGi"。您可以在迁移到OSGi之前模块化应用程序(如果您还没有它,我肯定会投资于良好的测试覆盖率)。
如果您正在使用servlet规范3.0,那么请查看使用网络片段。
就你所显示的结构而言,我会说不嵌套任何东西(除了网络片段),WAR可以成为WAB(Web应用程序包 - 基本上是一个瘦的WAR)。也尽可能地利用OSGi的μServices - 这就是乐趣开始的地方=)
像Karaf和Virgo这样的企业OSGi框架提供了大量的支持,而你跨越了JEE-OSGi的鸿沟(Equinox和Felix本身只是一点点准系统)。
答案 2 :(得分:1)
根据您的项目要求,如独立模块开发和运行时更新,Maven是最佳解决方案。它提供了对依赖项和插件的强大支持,看起来您项目所需的一切已经可用:
的OSGi。如果您想使用它,您必须仔细查看当前的设计并尝试将其调整为μServices。通常,您将拥有API,API使用者和API提供者的模块。它可以帮助您更多地在团队之间拆分开发(例如,一个开发API使用者模块,另一个开发API提供者模块)。如果需要,可以将API使用者/提供者模块拆分为2个以上的OSGi包(即Maven模块)。
答案 3 :(得分:0)
你的结构对我来说确实很好,这是大多数项目的典型结构 - 我给出的一个建议是对你的依赖项进行版本化,所以对于例如,让你的webproject.war依赖于webmodule1-1.3说,这样可能不同的最终项目可能具有不同版本的从属罐。
使用maven肯定会简化管理这些依赖关系
如果您的要求是在运行时替换依赖项,那么您必须使用OSGI之类的技术,但是如果它不是您正在寻找的运行时模块化,我建议不要从OSGi开始并保持堆叠更简单。
答案 4 :(得分:-1)
在稍微处理OSGi并获得一些痛苦之后,我们为Spring开发了无模块化的模块化https://github.com/griddynamics/banshun你很受欢迎!