任何设计师都会告诉你，结构设计是设计过程中最重要的步骤。创造开始的前几笔，承载着其余部分的命运。— Christopher Alexander
我们开始看一个程序的第一步是什么？就是它的目录结构。一起从结构开始，程序好坏，从结构上大致就能分辨出来。
最佳实践
以下示例可以作为 Java 项目的一种最佳实践，核心思想来源于一个博主的视频和最近看的一些文章。
project-name .github // 可选，Github 配置文件，如有需要 .ci // 推荐，存放 CI 相关的配置文件 design // 推荐，存放设计文档 adr // 推荐，架构设计决策记录，详情请查询 ADR adr-0001... docs // 推荐，存放项目文档，一般是 README 写不下的部分，或者文档需要的图片等资源 scripts // 可选，存放项目使用的脚本，如果有的话 src // Java 国际规范，源代码目录 main // Java 国际规范，源代码主程序目录 java // Java 国际规范 com.example // 包名 customer // 领域划分，建议将领域中对象整合，方便未来管理、拆分和重构 Customer // 领域对象模型 CustomerConfig // 领域配置 CustomerController // 领域路由控制器 CustomerDAO // 领域传输对象模型 CustomerService // 领域服务 db // 可选，DB 相关 exception // 可选，异常类型 ApiError order // 其他领域示例 Order... shared // 公共类、工具类 FileUtils Application // 程序主函数入口 resources // Java 国际规范，程序资源目录 application.yml application-dev.yml application-uat.yml application-prd.yml test // Java 国际规范，程序测试目录 java customer CustomerServiceTest // 测试类应按被测对象结构整理 resources .gitignore// 推荐，git ignore 配置 pom.xml // Maven 配置文件，在 Gradle 也有等同配置 LICENSE // 推荐，版权文件，开源项目都应该有 README.md // 推荐，项目介绍，一个项目的第一印象，非常重要
在 IDEA 中示例如下：
按包而不是按层封装
主要有以下好处：
- 更好的模块化，这样才可能达到高内聚低耦合的目的
- 找代码更容易，大多时候我们不是在写代码，而是在翻代码，如果找起来方便就是效率提升
- 更高层次的抽象，按业务划分更强调业务而不是实现细节，文档自动化后也会轻松许多
- 最小化影响范围，假设后期需要对项目重构或者拆分，按包封装的结构将更容易处理
- 更容易扩展，如果某个业务以后变的很复杂，这还是在这个包内操作，那时可以再在包内分层
举一些例子
想象一辆汽车，在汽车的实现里，如果按功能可能是这样划分的：
- 安全系统
- 引擎系统
- 操控系统
- 燃油系统 等等
但如果按层划分会是怎么样的呢？
- 机械系统
- 液压系统
- 电气系统 等等
当然这样理解和组合问题没错，但其实现的复杂度和耦合度是很难估量的。
再想象一下一个公司的结构，如果按包划分，可能是这样的（等同于按部门划分）：
- 前台
- 后台
- 会计
- 人事
如果按层划分，大概会是这样（等同于按组织结构划分）：
- 董事会
- 高级经理
- 员工
按层划分之后，对象会有交集吗？可能吧。他们是同一类人，也许会在一起开会讨论。但是他们能直接对业务产生效果吗？并不会，真正业务的结果还是来自于各个部门，部门内部的交流和耦合才更加有效。这些人其实就是每个部门的接口类。
那为什么很多人还是喜欢按层的方式来组织代码呢？可能只是一个需要改掉的坏习惯吧。按层思考更省力气，但或许是对业务理解的不够透彻。
参考链接：
- Java 项目结构最近实践： https://www.youtube.com/watch?v=DoK3-9V5HRE
- Maven 标准项目结构 https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
- 按包而不是按层划分项目功能 http://www.javapractices.com/topic/TopicAction.do?Id=205