为什么要Maven多模块
我们知道，一个服务端项目通常使用MVC分层结构，保证职责单一，流向分明，便于维护。很多项目都是通过文件夹的形式进行分层的，但这样做，对于团队项目来说会带来一些不便之处，具体如下：
- 不利于复用，如你的应用可能需要有jsp页面渲染、内部api、开放api等多个项目，如果service、dao、util等没有采用Maven模块管理，复用代码只能复制粘贴，而采用了模块，则可以很好的复用service、dao、util等模块。
- 每次运行都需要对全部代码编译打包，项目变大后等待时间会变得越来越长，采用Maven模块管理后，未更改的模块不需要重复打包，缩减时间。
- MVC层级的调用关系可能会造成混乱，试想如果没有区分模块，一个开发新人可能会跳过service直接调用dao，但这样的调用会造成层级混乱，是不被允许的。
- 模块权限控制，如不同Maven模块由不同开发人员负责，此时就可以对单个模块进行权限控制，其他开发人员无权干涉没有权限的模块
- 别人提交的代码不小心导致build失败的时候，只能等那人把代码修复才能继续运行。
依赖管理最佳实践
Maven多模块项目相对于单模块项目而言，依赖是不共享的，但父模块为我们提供了全局共享依赖的功能，我们可以针对不同模块所需要依赖的包进行分模块引入，具体如下：
- 所有子模块都依赖的包，如
junit可以统一由父模块中<dependencies>设置依赖 - 多个子模块但非全部子模块依赖的包，可以在父模块中的
<dependencyManagement>中统一管理依赖版本，再由每个子模块自主引入依赖，这样设置可以达到项目中多个子模块依赖的包版本统一的目的。 - 单个子模块依赖的包，可以直接交由这个子模块引入即可。但有时候我们出于对后续可能添加子模块考虑，即使当前只有一个子模块依赖的包，也可以统一交由父模块的
<dependencyManagement>统一管理，而如果确认后续不会再加子模块的，可以按前者进行处理。
在父模块中，可通过
<properties>统一管理依赖包的版本，让共享包也更加统一管理。
