场景：
“分天下为三十六郡，郡置守，尉，监” —— 《史记·秦始皇本纪》
所有用Maven管理的真实的项目都应该是分模块的，每个模块都对应着一个pom.xml。它们之间通过继承和聚合（也称作多模块，multi-module）相互关联。那么，为什么要这么做呢？我们明明在开发一个项目，划分模块后，导入Eclipse变成了N个项目，这会带来复杂度，给开发带来不便。
为了解释原因，假设有这样一个项目，很常见的Java Web应用。在这个应用中，我们分了几层：
对应的，在一个项目中，我们会看到一些包名：
这样整个项目的框架就清晰了，但随着项目的进行，你可能会遇到如下问题：
某个模块，比如util，你只想让一些经验丰富的人来维护，可是，现在这种情况，每个开发者都能修改，这导致关键模块的代码质量不能达到你的要求。
我们会发现，其实这里实际上没有遵守一个设计模式原则：“高内聚，低耦合”。虽然我们通过包名划分了层次，并且你还会说，这些包的依赖都是单向的，没有包的环依赖。这很好，但还不够，因为就构建层次来说，所有东西都被耦合在一起了。因此我们需要使用Maven划分模块。
环境:
Eclipse Luna package +apache-maven-3.2.5
实际操作:
一个简单的Maven模块结构是这样的：
—- app-parent
|– pom.xml (pom)
|
|– app-util
| |– pom.xml (jar)
|
|– app-dao
| |– pom.xml (jar)
|
|– app-service
| |– pom.xml (jar)
|
|– app-web
|– pom.xml (war)
上述简单示意图中，有一个父项目(app-parent)聚合很多子项目（app-util, app-dao, app-service, app-web）。每个项目，不管是父子，都含有一个pom.xml文件。而且要注意的是，小括号中标出了每个项目的打包类型。父项目是pom,也只能是pom。子项目有jar，或者war。根据它包含的内容具体考虑。
这些模块的依赖关系如下：
app-dao –> app-util
app-service –> app-dao
app-web –> app-service
注意依赖的传递性（大部分情况是传递的，除非你配置了特殊的依赖scope），，app-dao依赖于app-util，app-service依赖于app-dao，于是app-service也依赖于app-util。同理，app-web依赖于app-dao,app-util。
用项目层次的划分替代包层次的划分能给我们带来如下好处：
项目截图:
真凉爽啊！青山绿水映入我的眼中，景色怡人啊！
