后端技术栈：优秀的项目代码是怎么分层的

2021-08-17

技术笔记 / 后端技术栈

字数统计: 1.5k | 阅读时长≈ 5 分钟

阿里手册是怎么约定的

阿里巴巴 Java 开发手册（https://kangroo.gitee.io/ajcg/#/）

开放接口层：可直接封装 Service 方法暴露成 RPC 接口；通过 Web 封装成 http 接口；进行网关安全控制、流量控制等。
终端显示层：各个端的模板渲染并执行显示的层。当前主要是 velocity 渲染，JS 渲染， JSP 渲染，移动端展示等。
Web 层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。
Service 层：相对具体的业务逻辑服务层。
Manager 层：通用业务处理层，它有如下特征：
对第三方平台封装的层，预处理返回结果及转化异常信息；
对 Service 层通用能力的下沉，如缓存方案、中间件通用处理；
与 DAO 层交互，对多个 DAO 的组合复用。
DAO 层：数据访问层，与底层 MySQL、Oracle、Hbase 等进行数据交互。
外部接口或第三方平台：包括其它部门 RPC 开放接口，基础平台，其它公司的 HTTP 接口。

应用分层

通常的项目结构

就以当下非常火热的 Spring Boot 典型项目结构为例，创建出来的项目应该总体分为三大层：

项目根目录/src/main/java：放置项目 Java 源代码
项目根目录/src/main/resources：放置项目静态资源和配置文件
项目根目录/src/test/java：放置项目测试用例代码

而位于 /src/main/java 目录下的 Java 源代码的组织结构大家比较关心，这地方也只能给出一个通常典型的结构，毕竟不同项目和团队实践不一样，稍许有区别，但整体安排应该差不多。而且如果是多模块的项目的话，下面的结构应该只对应其中一个模块，其他模块的代码组织也大致差不多。

Java 源代码的组织结构

各个目录详细介绍：

|_annotation：放置项目自定义注解
|_aspect：放置切面代码
|_config：放置配置类
|_constant：放置常量、枚举等定义
   |__constnt：存放常量定义
   |__enums：存放枚举定义
|_controller：放置控制器代码
|_filter：放置一些过滤、拦截相关的代码
|_mapper：放置数据访问层代码接口
|_model：放置数据模型代码
   |__entity：放置数据库实体对象定义
   |__dto：存放数据传输对象定义
   |__vo：存放显示层对象定义
|_service：放置具体的业务逻辑代码（接口和实现分离）
   |__intf：存放业务逻辑接口定义
   |__impl：存放业务逻辑实际实现
|_utils：放置工具类和辅助代码

然后接下来 /src/main/resources 目录，里面主要存放静态配置文件和页面静态资源等东西：

|_mapper：存放 mybatis 的 XML 映射文件（如果是 mybatis 项目）
|_static：存放网页静态资源，比如下面的 js/css/img
   |__js：
   |__css：
   |__img：
   |__font：
   |__等等
|_template：存放网页模板，比如 thymeleaf/freemarker 模板等
   |__header
   |__sidebar
   |__bottom
   |__XXX.html 等等
|_application.yml       基本配置文件
|_application-dev.yml   开发环境配置文件
|_application-test.yml  测试环境配置文件
|_application-prod.yml  生产环境配置文件

当然，这地方估计有一个很多人都会纠结的关于 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 包里了。

项目结构划分总结

对应代码目录的流转逻辑就是：
代码逻辑

一些注意事项

Contorller 层参数传递建议不要使用 HashMap，建议使用数据模型定义；
Controller 层里可以做参数校验、异常抛出等操作，但建议不要放太多业务逻辑，业务逻辑尽量放到 Service 层代码中去做；
Service 层做实际业务逻辑，可以按照功能模块做好定义和区分，相互可以调用；
功能模块 Service 之间引用时，建议不要渗透到 DAO 层（或者 mapper 层），基于 Service 层进行调用和复用比较合理；
业务逻辑层 Service 和数据库 DAO 层的操作对象不要混用。 Controller 层的数据对象不要直接渗透到 DAO 层（或者 mapper 层）；同理数据表实体对象 Entity 也不要直接传到 Controller 层进行输出或展示。

参考：

打赏