java项目目录结构规范

　　1、背景
　　项目结构这东西一般并没什么非常严格的标准，业内所使用的习惯和规范也不尽相同。《阿里巴巴Java开发手册》中也有提到关于工程结构和应用分层相关的内容，如下：
　　它这里面讲的内容大概就是：关于一个正常的企业项目里一种 通用的项目结构和代码层级划分 的指导意见。
　　按这本书上说的，一般分为如下几层： 开放接口层 终端显示层 Web 层 Service 层 Manager 层 DAO 层 外部接口或第三方平台
　　接下来，我们结合实际项目代码结构，来制订一下关于公司内部的项目结构和代码分层 2、项目结构2.1 总体结构
　　项目根目录/src/main/java ：放置项目Java源代码 项目根目录/src/main/resources ：放置项目静态资源和配置文件 项目根目录/src/test/java ：放置项目测试用例代码 2.2 server结构
　　各个目录详细介绍：
　　2.2.1 位于 /src/main/java 目录下的Java源代码的组织结构
　　java
　　|_annotation：放置项目自定义注解
　　|_aop：放置切面代码
　　|_config：放置配置类
　　|_constant：放置常量、枚举等定义
　　|__constants：存放常量定义
　　|__enums：存放枚举定义
　　|_repository：放置与数据库交互的实现类与接口
　　|_mapper：放置数据访问层代码接口，一般是MapStruct的类
　　|_mq：放置消息中间件相关的代码
　　|__producer：放置与MQ的生产者代码
　　|__consumer：放置与MQ的消费者代码
　　|_model：放置数据模型代码
　　|__entity：放置数据库实体对象定义
　　|__dto：存放数据传输对象定义
　　|__vo：存放显示层对象定义
　　|_service：放置具体的业务逻辑代码（接口和实现分离）
　　|__intf：存放业务逻辑接口定义
　　|__impl：存放业务逻辑实际实现
　　|_util：放置工具类和辅助代码
　　|_web：放置Web相关的代码
　　|__ interceptor：放置Web的拦截器代码
　　|__security：放置与Web认证相关的代码
　　|__filter：放置一些过滤器相关的代码
　　|__controller：放置控制器代码
　　关于 DTO/VO/DO 等 数据模型定义 的区分，Entity与DTO有强制要求，其它并无强制使用，下面定义供参考： Entity ：与数据库表结构一一对应，通过DAO层向上传输数据源对象，与表名保持一致，不需要加后缀。 DTO（Data Transfer Object） ：数据传输对象，Service或Manager向外传输的对象。 BO（Business Object） ：业务对象。由Service层输出的封装业务逻辑的对象。 AO（Application Object） ：应用对象。在Web层与Service层之间抽象的复用对象模型，极为贴近展示层，复用度不高。 VO（View Object） ：显示层对象，通常是Web向模板渲染引擎层传输的对象。 Query ：数据查询对象，各层接收上层的查询请求。注意超过2个参数的查询封装，禁止使用Map类来传输。
　　2.2.2 位于 /src/main/resources 目录，里面主要存放静态配置文件和页面静态资源等东西：
　　resources
　　|_i18n：国际化语言资源文件夹
　　|_application.yml：通用的应用配置
　　|_application-dev.yml：开发环境的配置
　　|_application-test.yml：测试 环境的配置
　　|_application-prod.yml：生产环境的配置
　　|_banner.txt：Banner文字
　　|_bootstrap.yml：项目启动时的配置，记录nacos的地址
　　|_logback.yml：日志格式配置 2.3 api接口项目结构
　　各个目录详细介绍：
　　2.3.1 位于 /src/main/java 目录下的Java源代码的组织结构
　　java
　　|_config：放置配置类
　　|_api：FeignClient对外接口定义
　　|_model：放置数据模型代码
　　|_ao：应用对象
　　|_bo：业务对象
　　|_query：数据查询对象
　　|_vo：显示层对象
　　|_response：响应对象
　　2.3.2 位于 /src/main/resources 目录，里面主要存放静态配置文件：
　　resources
　　|_META-INF：
　　|_spring.factories：自动装配类的定义 3、服务间调用关系
　　4、项目内部请求关系
　　4、一些注意事项
　　1、 Contorller 层参数传递建议不要使用 HashMap ，建议使用数据模型定义
　　2、 Controller 层里可以做参数校验、异常抛出等操作，但建议不要放太多业务逻辑，业务逻辑尽量放到 Service 层代码中去做
　　3、 Service 层做实际业务逻辑，可以按照功能模块做好定义和区分，相互可以调用
　　4、功能模块 Service 之间引用时，建议不要渗透到 Repository 层，基于 Service 层进行调用和复用比较合理
　　5、业务逻辑层 Service 和数据库 DAO 层的操作对象不要混用。 Controller 层的数据对象不要直接渗透到 Repository 层；同理数据表实体对象 Entity 也不要直接传到 Controller 层进行输出或展示。