看完这篇，别人的开源项目结构应该能看懂了，kafka 入门与实践百度云

终端显示层

Web 层

Service 层

Manager 层

DAO 层

外部接口或第三方平台

由于书中的篇幅关系，它这地方讲得比较笼统了，估计初学者看了还是会懵，所以接下来结合实际项目代码结构，来唠一唠具体的项目结构和代码分层。

通常的项目结构

首先说在前面的是：这东西并没有一套通用的标准，不同公司或者团队的使用习惯和规范也不尽相同。

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

【一线大厂Java面试题解析+核心总结学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取

分为三大层：

• 项目根目录/src/main/java：放置项目 Java 源代码

• 项目根目录/src/main/resources：放置项目静态资源和配置文件

• 项目根目录/src/test/java：放置项目测试用例代码

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

各个目录详细介绍：

然后接下来/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 包里了。

项目结构划分总结

如果从一个用户访问一个网站的情况来看，对应着上面的项目代码结构来分析，可以贯穿整个代码分层：

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

我想，应该看得比较清楚了吧。