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层进行输出或展示。