通常的项目结构
各个目录详细介绍：
然后接下来/src/main/resources目录，里面主要存放静态配置文件和页面静态资源等东西：
当然，这地方估计有一个很多人都会纠结的关于DTO/VO/DO等数据模型定义的区分。
这在《阿里巴巴Java开发手册》中倒是做了一个所谓的严格区分，那本书上是这样去定义的：
DO（Data Object）：与数据库表结构一一对应，通过DAO层向上传输数据源对象。DTO（Data Transfer Object）：数据传输对象，Service或Manager向外传输的对象。BO（Business Object）：业务对象。由Service层输出的封装业务逻辑的对象。AO（Application Object）：应用对象。在Web层与Service层之间抽象的复用对象模型，极为贴近展示层，复用度不高。VO（View Object）：显示层对象，通常是Web向模板渲染引擎层传输的对象。Query：数据查询对象，各层接收上层的查询请求。注意超过2个参数的查询封装，禁止使用Map类来传输。
老实讲，看到这么多对象的定义，我也是很蒙的。实际项目开发时，我觉得没有必要刻意照搬去定义这么多层对象，这样后续做对象转换工作都能烦skr人。
出于简单起见，我个人觉得，只要保证业务逻辑层Service和数据库DAO层的操作对象严格划分出来，确保互相不渗透，不混用，问题应该就不大。
Service层处理的对象都定义在了dto包里，而DAO层处理的对象都放在了entity包里了。
一些注意事项
1、Contorller层参数传递建议不要使用HashMap，建议使用数据模型定义
2、Controller层里可以做参数校验、异常抛出等操作，但建议不要放太多业务逻辑，业务逻辑尽量放到Service层代码中去做
3、Service层做实际业务逻辑，可以按照功能模块做好定义和区分，相互可以调用
4、功能模块Service之间引用时，建议不要渗透到DAO层（或者mapper层），基于Service层进行调用和复用比较合理
5、业务逻辑层Service和数据库DAO层的操作对象不要混用。Controller层的数据对象不要直接渗透到DAO层（或者mapper层）；同理数据表实体对象Entity也不要直接传到Controller层进行输出或展示。
来源：https://www.cnblogs.com/exce-ben/p/12602772.html