创建项目命令模板：

mvn archetype:generate -DarchetypeGroupId=org.antframework.template -DarchetypeArtifactId=template-archetype -DarchetypeVersion=2.7.4 -DgroupId="被创建项目的groupId" -DartifactId="被创建项目的artifactId" -Dversion="被创建项目的版本号"

参数说明：

-DgroupId 指定被创建项目的groupId
-DartifactId 指定项目名
-Dversion 指定项目版本号

例如：

mvn archetype:generate -DarchetypeGroupId=org.antframework.template -DarchetypeArtifactId=template-archetype -DarchetypeVersion=2.7.4 -DgroupId=org.antframework.demo -DartifactId=demo -Dversion=1.0-SNAPSHOT

各模块依赖关系：

• test --> assembly --> web --> biz --> dal --> facade
• dal --> common
• biz --> integration --> common

以下介绍每个模块的作用，从底层模块到高层模块顺序介绍：

facade层，本模块是本系统对上层系统的api，是设计模式的【门面模式】，遵从设计模式的【最少知识原则】，对外屏蔽内部实现细节。

我们一些系统提供出去的接口就像insertXXX、updateXXX这样，入参呢就是表对应的实体（PO）， 这样提供出去的根本就不是服务，更像是把自己系统的mapper提供出去了，这样会导致系统的业务价值极低，系统更像是一个存储单元，而没有自己的业务逻辑，这样会导致本该属于本系统的业务逻辑，却出现在了上层系统中，而上层系统则会去关心底层系统的实现，导致上层系统越来越臃肿，可读性、可维护性越来越差。所以设计好本系统对上层系统的api是关键，把本系统不该暴露出去的细节，坚决不暴露出去。

公共层，本模块存放项目公共性的工具和公共性的依赖

数据访问层，dal即是Data Access Layer，所有对数据库的访问操作均是通过本层进行，比如mybatis、jpa操作的DAO都应该定义在这个模块，好处就是方便维护，比如以后要更换ORM框架，则只需要改动这层代码就行，其他代码几乎不用动。

集成层，需要调用其他系统的服务在本模块编写。一个系统不光会被其他系统调用，它还可能会调用其他系统，那么调用其他的系统的代码应该集中在这一层，好处就是在这层统一管理对其他系统的调用，本系统依赖了哪些系统的哪些服务，可以一目了然在这层看出，便于维护。需要调用的其他系统的facade在本模块引入。

biz层，biz是Business的谐音缩写，即是业务逻辑层。本层实现template-facade提供出去的接口，它是一个系统的重中之重，主要的业务逻辑都是在这层实现。

web层，处理与网页相关的逻辑。而且web层只应该处理网页相关的逻辑，比如操作session、权限校验、用户页面输入的参数处理、返回结果展示。而业务逻辑处理不应该放在web层，而应该放在biz层，web层应该通过调用facade层的api提供出来的服务间接调用biz层，来达到业务处理目的，这样做的好处就是web层和biz层进行了解耦。

不知你有没有这种体验：由于需求变更给用户展示的页面需要修改，导致系统内部一大片需要跟着改，这就是web层和biz层耦合太深了，导致牵一发而动全身，而且页面这种直接和用户交互的东西是最容易会发生变化的，所以我们应该独立出web层，将这种易变性从我们的核心biz层剥离出来。

装配层，本模块会聚合本系统的其他模块组装成最终的执行程序（jar包或war包）。同时本模块还提供环境相关配置，比如各种properties、yaml文件。

测试层，所有模块的单元测试代码应该写在本模块中，好处就是将测试代码从其他模块隔离出来，便于查看和管理；消除其他模块pom对测试的依赖，净化pom；本模块有其他所有模块的依赖，也便于单元测试。