java项目,基于maven的模块化开发与微服务架构

自从爱上maven的模块化开发,就不能自拔。

在实际项目中,代码复用是每个公司希望做的一项工作。但在初期,项目紧、任务重的情况下,如何兼顾代码复用(当然,就把复制代码算是最低级的代码复用吧,不过这可就做不到功能抽象的程度)与业务项目开发的确需要一定的构思。

对于单体项目(基本上所有的功能都在一个项目里,最后打包成一个jar或者war),可能规范命名空间(包名、类名),是个不错的选择。——把一个功能封装在一个命名空间里,提供仅有的几个public的API。代码复用以复制文件夹的形式重用,再好点就专门做成一个鱼龙混杂的“基础包”。

maven让你多了一个选择,可以把可重用的功能抽象到一个maven模块里(一般是个jar),在一个项目里积累的maven模块,在可以在项目收尾后进一步抽象为组织过程资产级别的模块。在其他项目里,只需要引入这个jar(maven的pom.xml方式或者ant方式)。

至于业务性质的功能模块(如支付功能,文件上传功能),可以开发为jar,然后被一个war类型的模块引入,一个微服务就出来了。。。。但然也可以根据业务需要,把几个业务jar封装到一个war模块里,一个传统的单体项目也就出来了。。。

当然maven-module模式的架构,需要对maven的应用有一定的了解。不过我相信,站在巨人的肩上,我们能看的更远!

蜗牛,为加班而生~

© 2017, 李德涛博客. 版权所有.

《java项目,基于maven的模块化开发与微服务架构》有2个想法

  1. 至于业务性质的功能模块(如支付功能,文件上传功能),可以开发为jar,然后被一个war类型的模块引入,一个微服务就出来了。。。。但然也可以根据业务需要,把几个业务jar封装到一个war模块里,一个传统的单体项目也就出来了。。。

    这里说的“然后被一个war类型的模块引入,一个微服务就出来了。。。。”是什么意思?给我的理解是:将一个大项目使用maven-module划分出多个模块,然后各个模块之间相互引用,这样就是微服务?实际上我对微服务的理解并不是这样的,微服务指的是将一个大项目划分为完全独立的小应用,每个都是一个项目,每个项目部署启动时都要进行服务发现和服务注册。

    不知道我的理解有没有错呢?请指教。。。

发表评论

电子邮件地址不会被公开。 必填项已用*标注