maven最佳实践之模块划分

我们平常做的java项目模块划分可能是这样：

controller为控制器层；service为业务逻辑实现层；dao和数据库交互；util放些工具类；constant放常量类。

这样的模块划分很常见，但是有很多弊端：

1、当随着项目版本迭代，需求不断增加，代码结构越来越庞大，为后期的维护增大成本。比如说，我们改了一个controller类，就得整个项目全部编译。

2、比如说项目的util包里封装了很多通用工具类，当前项目可以用，其他项目也可以用，如果是上面的划分模式，就得依赖项目war，这变得非常的恶心，因为在maven中配置对war的依赖远不如依赖jar那样简单明了。

其实这种划分没有遵守一个设计模式原则：“高内聚，低耦合”。虽然我们通过包名划分了层次，这很好，但还不够，因为就构建层次来说，所有东西都被耦合在一起了。因此我们需要使用Maven划分模块（module）

如下图：

artmuseum-parent为所有module的父类，打包类型为pom，只有一个pom.xml文件用于管理module；

artmuseum-common被artmuseum-parent管理，该工程用于封装工具类、常量，打包类型为jar；

artmuseum-manage同样被artmuseum-parent管理，为该项目主要module，用于管理controller、service、dao、pojo这四个module，打包类型为pom；

module之间依赖关系如下：

artmuseum-manage-controller ->

artmuseum-manage-service ->

artmuseum-manage-dao ->

artmuseum-manage-pojo ->

artmuseum-common

这种划分就解决了上面的弊端：

1、方便重用，如果需要把common包中的工具类等用到其他项目组件，只需要

把common这个module执行mvn install后，依赖生成的jar即可；

2、利于扩展和维护，修改了controller层的代码，只需要mvn install这个module即可。

基于此，今天撸了一个聚合工程出来，用到了SSM框架并实现了一个发布项目的接口（简单的入库）。

工程结构如下：

接口测试如下：

入库成功如下：