做企业管理软件，最怕的不是功能做不完，而是做到一半，代码乱到连自己都找不到北。这讲我们继续《看潮企业管理软件》项目开发的第三篇，章节编号03-008，主题是项目结构的第一部分（3-1）。这套系列一直强调“编程与数学”的结合，实际上在搭项目骨架这件事上，数学思维能帮上大忙——因为你正在做的，本质上是把一个复杂的业务空间，分解成一堆互相约束、彼此协作的子模块。先别急着写代码，把这层思路理清楚，后面所有开发工作都会顺畅得多。
这一讲的目标很明确：从零搭建一套企业管理软件的标准目录骨架，把前端、后端、数据库脚本、文档、测试、部署脚本各归其位。无论后续功能怎么加，这套骨架都能接得住。适合正在做企业级管理系统的团队参考，也适合刚入门想搞清楚“大项目目录到底长什么样”的开发者。
1. 项目结构设计的整体思路拆解
1.1 从分层到分模块：工程结构的数学本质
学过离散数学的朋友，对“集合划分”应该不陌生。给定一个全集U，把它划分成若干个子集，要求这些子集互不相交、并且并集刚好等于U。项目结构设计本质上就是这个过程——全集是系统的全部代码与资源，划分依据是职责边界。
企业管理软件通常包含用户管理、组织架构、权限控制、审批流、基础数据、业务单据、报表统计等模块。这些模块之间存在着依赖关系，比如审批流一定依赖用户与组织架构，报表统计一定依赖业务单据。如果目录结构划分不当，A模块的代码直接塞进B模块的目录里，后续维护代价会指数级上升。
在《看潮》项目里，我采用的是经典的前后端分离结构，加上后端内部的模块化分包。层级结构可以看作一棵多叉树：根目录是项目仓库，往下分为前端目录、后端目录、数据库目录、部署目录、文档目录。后端目录再按业务模块横向切分，每个业务模块内部再按技术职责纵向切分（控制层、服务层、数据访问层）。横向和纵向两个维度的交叉，正好对应数学上的笛卡尔积——每个业务模块都有完整的技术栈分层，每一层又服务于多个业务模块。理清这层关系，你就知道为什么有些项目看着目录挺整齐，实际上改起代码来浑身难受——因为纵向分层和横向分模块，只做了一半。
1.2 Web项目结构演进的三个时代
既然是做企业管理软件，Web项目是绝对的主流形态。Web项目的目录结构经历了三个明显阶段，理解这个演进过程，能帮你判断自己项目里的结构问题到底出在哪。
早期单体JSP项目，目录结构极度扁平，页面、Java类、配置文件全部混在一起，通常就是WebRoot下面堆一堆JSP，src下面堆一堆Java。这种结构下，模块边界完全靠开发者的自觉来维持，时间一长，就变成一锅粥。
后来SSM和早期Spring Boot普及，项目进入了分层分包时代。大家开始按controller / service / mapper分层，这一招比大锅饭先进很多，但也容易造成另一种混乱——“按层分包”会让业务模块的代码被拆得七零八落。比如用户模块的Controller在controller包里，Service又在service包里，当你想一眼看完整个用户模块时，得在十几个包之间来回跳跃。
第三个时代就是当下，也是《看潮》采用的方式——先按业务模块分包，再在模块内部按技术层分包。这种结构的核心优势在于高内聚：用户模块的代码从控制器到数据库访问，全部在同一个package里，改动一个功能不需要跨目录跳跃，也大幅降低模块间的代码牵连。
1.3 数学思维在结构设计中的关键启发
为什么说数学思维能帮你做项目结构？举三个实际能落地的例子。
第一，依赖关系是图，不是树。很多初级工程师以为模块依赖是像目录一样的树形结构，其实不然——A模块可能依赖B，B又依赖C，但A也想直接调用C。这种跨层级依赖在图论里是常态。在设计目录结构时，你得把依赖规则写清楚，比如“模块之间禁止跨层调用”，否则就会产生隐性的环路依赖。
第二，命名的本质是函数命名。在数学里，函数f(x) = y，要求定义域、值域清晰，同一函数在不同集合上不能有歧义。在项目里，类名、方法名、目录名都是“函数名”，一个好的命名应该让人不用查看源码，就能推测出它的依赖是哪些、返回值是什么。我们后文会说具体的命名规范。
第三，模块划分要满足正交性。两个模块最好是“正交”的——修改其中一个，不影响另一个。这在概率论里是独立事件，在软件工程里就是低耦合。数学上追求分解到最简，项目结构上也应当追求模块边界的清晰到不能再清晰。
2. 企业管理系统标准目录骨架：从根目录到内部细节
2.1 根目录的整体划分：七大目录各司其职
直接上我在《看潮企业管理软件》中实际使用的标准骨架，这是提炼过多个企业级项目后的通用形态。先看目录树的顶层结构：
kanchao-erp/ ├── frontend/ # 前端工程（Vue 3 + Vite + Element Plus） ├── backend/ # 后端工程（Spring Boot 3 + MyBatis-Plus） ├── database/ # 数据库脚本与初始化数据 ├── docs/ # 项目文档与设计文档 ├── deploy/ # 部署脚本与环境配置 ├── test/ # 端到端测试与压力测试脚本 └── scripts/ # 项目管理辅助脚本这七个目录各司其职，缺一不可。核心项目代码放在frontend和backend中，database保存所有SQL脚本，docs沉淀设计文档，deploy解决部署问题，test存放端到端测试，scripts存放一些开发辅助用的Python或Shell脚本。
为什么把database独立出来，而不是塞进backend里？这是企业管理软件的特殊性决定的。企业级系统上线后，数据库通常由独立的DBA团队或运维团队管理，他们未必关注后端Java代码在哪里，但一定关心SQL脚本的版本变化。把数据库脚本独立成目录，开发团队和运维团队的协作边界会清晰很多。
2.2 后端目录的模块化组织方式
后端是整个系统的核心，目录设计直接影响开发效率。《看潮》后端采用Maven多模块结构，先按技术职责划分顶层模块，再在每个技术模块内部按业务功能切分。这样做的好处是：既实现了代码层面的物理隔离，又保证了编译与部署的灵活性——公共模块可以单独打包，业务模块可以独立迭代。
来看backend内部的目录结构：
backend/ ├── kanchao-common/ # 公共模块：通用工具、统一返回结果、全局异常、常量定义 ├── kanchao-system/ # 系统管理模块：用户、角色、菜单、部门、字典、日志 ├── kanchao-workflow/ # 工作流模块：审批流程、流程定义、待办任务 ├── kanchao-business/ # 业务模块：客户管理、合同管理、订单、回款 ├── kanchao-report/ # 报表模块：统计数据、图表数据、导出中心 └── pom.xml # Maven父工程配置每个子模块内部，再按技术层分包。以kanchao-system为例：
kanchao-system/ ├── pom.xml └── src/ ├── main/ │ ├── java/com/kanchao/system/ │ │ ├── controller/ # HTTP层：接收请求、参数校验、结果封装 │ │ ├── service/ # 业务层：业务流程编排、事务控制 │ │ ├── mapper/ # 数据访问层：MyBatis-Plus的Mapper接口 │ │ ├── entity/ # 数据库实体对象 │ │ ├── dto/ # 前端交互对象：请求和响应体 │ │ └── config/ # 模块安全配置与其他配置 │ └── resources/ │ └── mapper/ # MyBatis XML文件 └── test/java/ # 单元测试与模块间集成测试代码里每个Package的职责必须严格区分。Controller只做参数接收和结果封装，不写具体业务逻辑；Service承载业务规则和事务；Mapper只做数据读写映射。Engineer们经常犯的错是在Controller里直接操作Mapper，短期看代码量少了，长期看整个系统的逻辑全黏在入口层，越改越乱。
2.3 前端目录的模块化组织方式
现代企业管理系统的前端，已经从简单的页面展示，进化成了复杂的状态交互系统。《看潮》前端基于Vue 3，但目录设计思路对React同样适用。前端的模块化程度，决定了一个新功能从需求到落地需要多少行代码改动。
前端目录结构如下：
frontend/ ├── src/ │ ├── api/ # 所有后端接口请求封装 │ ├── assets/ # 静态资源：图片、图标、样式 │ ├── components/ # 公共组件：封装复用UI │ │ ├── Table/ # 通用表格组件 │ │ ├── Form/ # 通用表单组件 │ │ └── Dialog/ # 弹窗类组件 │ ├── composables/ # Vue组合式函数：封装可复用业务逻辑 │ ├── layout/ # 主界面布局组件 │ ├── router/ # 前端路由配置 │ ├── stores/ # 全局状态管理（Pinia） │ ├── styles/ # 全局样式 │ ├── utils/ # 通用工具函数 │ └── views/ # 页面级组件，按业务模块划分 │ ├── system/ # 系统管理相关页面 │ ├── workflow/ # 流程审批相关页面 │ └── business/ # 业务管理相关页面 ├── public/ # 公开静态资源 ├── .env.development # 开发环境配置 ├── .env.production # 生产环境配置 ├── vite.config.js # Vite构建配置 └── package.json # 依赖声明前端目录的两个重点：一是api目录与views目录保持一一对应的模块关系，每个页面调用的接口必须能从api目录中的对应文件找到；二是composables目录往往被很多人忽略，却是前端复用的精髓所在。
简单解释一下composables的价值。假设系统里有三处地方需要实现“下载Excel文件”的功能，如果不用组合式函数，你得复制三份几乎一样的代码；如果用composables/useDownload.js封装好，三处只需要调用同一个函数。数学里的“提取公因式”思路，在前端代码组织里同样适用——把公共逻辑提取出来，集中维护，减少重复。
2.4 数据库与部署：企业管理软件离不开的支撑目录
database和deploy这两个目录，在很多半路出家的团队里往往被忽略，但在正规企业级项目里，这两块甚至比业务代码更重要。
database目录的划分方式：
database/ ├── init/ # 建库建表脚本 │ ├── 01_create_tables.sql # 建表语句 │ ├── 02_init_data.sql # 初始化数据（管理员账号、基础字典） │ └── 03_default_menus.sql # 默认菜单数据 ├── upgrade/ # 升级脚本 │ ├── v1.1.0/ # 按版本号组织 │ │ ├── ddl_changes.sql # 表结构变更 │ │ └── dml_changes.sql # 数据变更 │ └── v1.2.0/ │ └── ... └── backup/ # 备份策略脚本 └── backup_template.sql这里有个原则：开发人员只允许在upgrade目录里加增量脚本，不允许直接修改init目录里的历史版本脚本。否则你在一台新环境上初始化数据库时，会发现“最新的表结构和线上不一致”，这将成为生产事故的导火索。
deploy目录解决的是环境一致性问题。企业项目的交付环境往往不止一套——开发环境、测试环境、预生产环境、生产环境。如果缺乏标准化的部署目录，每次上线都是纯手工操作，很容易出现“测试环境一切正常，生产环境起不来”的经典闹剧。
deploy/ ├── docker-compose.yml # 本地一条命令启动依赖中间件 ├── nginx/ │ ├── nginx.conf # 前端静态资源与反向代理配置 │ └── conf.d/ │ ├── dev.conf │ └── prod.conf ├── sql/ # 数据库初始化挂载目录 └── scripts/ ├── start_backend.sh # 启动后端服务脚本 ├── stop_backend.sh # 停止后端服务脚本 ├── backup_database.sh # 数据库备份脚本 └── init_environment.sh # 一键初始化开发环境3. 关键文件的功能解析与应用场景
3.1 后端核心文件：启动类与配置文件的设计
先看企业级Spring Boot项目的核心配置。后端启动类是入口，但真正控制整个项目走向的是配置文件。在《看潮》项目中，application.yml拆成了三个文件，分别对应开发、测试、生产环境。
# application-dev.yml server: port: 8080 spring: datasource: url: jdbc:mysql://127.0.0.1:3306/kanchao_erp?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 redis: host: 127.0.0.1 port: 6379 database: 0 password: mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml type-aliases-package: com.kanchao.system.entity,com.kanchao.business.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl生产环境配置文件中，数据库密码必须通过环境变量的方式注入，绝不能硬编码在配置文件里。有些企业项目密码用了加密算法加壳存储，但只要密钥也写在配置文件里，就等同于明文。正确做法是使用环境变量或专门的密钥管理工具，在容器启动时动态注入。这一段不需要太多技术含量，但需要足够的安全意识。
MyBatis-Plus的mapper-locations配置决定XML文件的扫描路径。很多人把Mapper XML乱放在resources的任意位置，一旦路径配置错误，启动时就会报“Invalid bound statement”的错误。在标准骨架里，XML的位置固定为resources/mapper/目录，与Java Mapper接口所在的包结构一一对应。这个规则用一句话就能解释清楚：Java接口目录与XML目录在编译后必须保持相同的包路径映射关系。
3.2 前端核心文件：路由与状态管理的作用
前端两个最容易被忽视、也最容易被写乱的地方，是router和stores。
路由配置的核心是“菜单驱动”。企业管理软件通常有动态菜单权限，后端返回菜单列表，前端动态生成路由。如果把路由静态写死，那么权限控制只能在每一个页面里单独判断，既繁琐又容易漏掉判断逻辑。在《看潮》中，路由表分为constantRoutes（公共路由：登录页、404页）和dynamicRoutes（动态路由：根据权限生成）。登录成功后，前端请求用户菜单权限，再根据菜单数据映射出完整的路由表，动态添加进Router实例。这个思路在企业级项目里已经非常成熟。
状态管理负责的是“跨页面共享数据”。最典型的场景是用户信息——用户从登录页跳转到首页后，首页需要展示当前用户名和头像；用户修改头像后，侧边栏和顶栏又需要同步更新。如果没有全局状态管理，只能在每个页面分别请求一次用户接口，浪费流量还产生时差。在Pinia中，stores/user.js维护用户信息和登录状态，stores/app.js维护侧边栏折叠状态、主题配置等UI状态。状态管理不宜过多，往往四到五个Store就能覆盖整个项目的绝大多数共享数据需求。
3.3 公共模块的核心价值：统一响应与全局异常
kanchao-common模块的含金量，是衡量一个企业级项目工程化水平的重要标准。其中有两个核心类值得单独提：统一响应体Result<T>和全局异常处理器。
统一响应体的代码逻辑不复杂，核心是让前端始终能拿到一套一致的响应结构：
public class Result<T> implements Serializable { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("success"); result.setData(data); return result; } public static <T> Result<T> error(Integer code, String message) { Result<T> result = new Result<>(); result.setCode(code); result.setMessage(message); return result; } }很多人觉得统一响应体就是“包一层壳”，没什么技术含量，但它在前后端协作中的价值极大。如果没有这层统一封装，后端某个接口返回对象、某个接口返回字符串、某个接口直接返回null，前端每次对接接口都要单独协商返回值格式，联调效率大打折扣。统一响应体相当于一种协议约定：定义域和值域都清晰，前端只要一次封装，就能解析所有后端的返回。
全局异常处理器的核心是把异常转换为统一响应体。后端代码中常见的业务异常、参数校验异常、数据库异常，都应该由全局异常处理器接管，而不是让异常堆栈直接抛给前端。这样做不仅是出于安全考虑（不让前端看到内部堆栈细节），更是为了给用户友好的提示信息。异常处理本质上是一个映射函数：异常类型映射到响应码与提示信息，映射关系维护在一张异常对照表里。
4. 项目结构规划步骤与实操心得
4.1 从需求到目录：五步完成新项目骨架搭建
这一步给想自己动手从零搭项目骨架的朋友，提供一个可直接照做的流程。无论你用的是Spring Boot还是FastAPI，核心思路都适用。
第一步：列出系统核心业务模块。打开需求文档，把所有功能点归类。以《看潮》为例，客户管理、合同管理、订单管理、回款管理都是业务模块；用户管理、组织架构、角色权限、系统日志则是系统基础模块；审批流是跨业务模块的公共支撑模块。
第二步：明确模块之间的依赖关系。画一张简单的依赖图——注意这里不需要用绘图工具，直接画在白纸上即可。哪个模块依赖哪个模块，标记清楚。依赖关系决定模块划分的粒度——依赖性极强的模块可以考虑合并，独立性极强的模块要坚决分离。
第三步：确定技术树与核心框架。不同技术栈的项目目录结构会有所不同：Spring Boot后端模块优先使用Maven多模块；Python后端推荐用FastAPI配合app包结构；前端项目不管Vue还是React，都建议按业务模块组织views目录。
第四步：编写第一版目录树，落到文档中。这一步不要直接开始写代码，先把目录树发到团队群里让大家评审，确认模块边界清晰、命名规范一致后，再动工写代码。
第五步：建立目录检查规范。在团队规范里明确一条铁律：新增代码必须先确定落在哪个模块的哪个包，禁止出现“临时放这里，之后再挪”的情况。项目结构只有在刚开始就严格执行，后续才不会崩坏。
4.2 目录规划过程中容易踩的三个坑
坑一：过度拆分。有些团队一上来就建了二三十个模块，每个模块就几百行代码。模块拆分太细，管理成本远远大于收益。判断拆得是否合理，有一个简单标准：如果两个模块之间依赖的接口超过五个，说明拆分边界有问题，不如合并。
坑二：命名不统一。后端目录用userManage，前端目录用system/user，数据库表名又变成sys_user。同一个业务在三个地方用三种叫法，团队协作时间一长，光是“找文件”就要花掉不少时间。解决方案是建一个“术语对照表”，把核心业务术语的前后端英文命名统一起来。
坑三：依赖方向失控。底层公共模块反向依赖业务模块，这是最容易被忽视的架构腐败。比如kanchao-common里面出现了一段业务代码，用了订单表的查询，这就破坏了依赖方向。公共模块必须是纯净的、不依赖任何具体业务的底座，否则就是一颗定时炸弹。可以通过架构测试工具（比如ArchUnit）在CI里自动拦截非法依赖。
4.3 命名规范与包名最佳实践
包名和类名的规范说起来简单，做起来难。分享一下我用了一段时间后觉得比较顺手的规范。
后端包名一律小写，以公司域名倒写开头。com.kanchao.system表示系统管理模块，com.kanchao.business表示业务模块。类命名遵循约定：Controller以Controller结尾，Service接口以Service结尾，实现类加Impl后缀，Mapper接口以Mapper结尾，实体类不带后缀，DTO类以DTO或VO结尾区分入参与出参。
特别强调一下DTO与VO的区别。DTO是前端传给后端的请求参数对象，VO是后端返回给前端的响应数据对象。用同一个对象既做入参又做响应，在初期看不出问题，但在大型项目里会造成巨大的迷惑——一个字段到底是从哪传递到哪的，别人读代码时很难理清。把入参和出参分离，本质上是在明确编程中“函数入参”和“返回值”的边界，这与数学中用定义域和值域分开描述函数的思想完全一致。
4.4 项目结构文档的维护技巧
项目结构不是一次写完就固定不变的。随着业务演进，模块和新包会不断出现。如果没有一份“活”的目录结构文档，新成员或者隔了半年的老成员都会迷失在目录的海洋里。
我建议在docs目录下维护一份project-structure.md，文档中放四样东西：目录树的当前完整形态、每个模块的职责说明、模块依赖关系表、命名规范与变更记录。每次目录调整，都要同步更新文档。听起来像额外工作量，但实际做过的人知道，维护文档的代价远小于新人“摸黑找代码”的代价。
另一个小技巧是写脚本检查目录结构。在scripts目录下放一个check_structure.py，扫描后端模块的包结构是否满足预期，扫描api目录是否与views目录一一对应，有偏差就输出警告。用机器代替人工检查约定，项目规范才能真正落地。
5. 常见问题与排查技巧实录
5.1 项目结构引发的高频问题速查表
我在实际项目维护和代码评审中，遇到最多的问题集中在以下几个方面。整理成一张速查表，遇到类似情况可以直接对号入座。
| 问题现象 | 根本原因 | 解决方案 |
|---|---|---|
| 启动报Invalid bound statement | Mapper XML路径配置错误或XML没编译进classes | 检查mapper-locations配置，确认resources下XML目录与Java包路径一致后重新clean |
| 前端接口通通404 | 路由配置缺少页面组件映射，或动态路由未正确拼接 | 检查permission.js中的路由生成逻辑，确认动态路由的component解析正确 |
| 改一个模块的代码，另一个模块报错 | 模块间发生了跨层调用，依赖方向混乱 | 使用ArchUnit添加依赖检查规则，禁止跨模块任意调用 |
| 新环境初始化数据库报错 | 数据库升级脚本缺失或历史脚本被修改 | 检查upgrade目录下的增量脚本是否齐全，禁止修改init目录历史脚本 |
| 多个环境的配置互相影响 | 配置文件没有做环境隔离 | 使用application-{env}.yml拆分，通过启动参数--spring.profiles.active=prod切换环境 |
| 新同事不知道代码放在哪 | 项目结构文档缺失或不到位 | 在docs中补充project-structure.md，简历模块职责清单 |
5.2 一个真实案例：依赖混乱导致的全链路故障
讲一个我实际遇到过的事故。某次项目迭代中，开发同学为了省事，在报表模块的Service里直接调用了订单模块的Mapper，导致业务模块之间形成了一条隐性的数据通路。刚开始一切正常，直到订单模块改了表结构，订单表的一个字段被重命名了，报表模块完全不知情，第二天报表数据全部查询失败。整个排查过程耗费了大半天，最终定位到这一条本不该存在的跨模块依赖。
这个案例说明了三层道理。第一层，依赖方向的约束要靠工具和CI来强制，不能靠自觉。第二层，模块之间的通信必须通过公开的Service接口，不能越层访问Mapper。第三层，公共模块和业务底层模块的变更，需要一种通知机制——类似数学中的“集合事件联动”，底层集合一旦变化，依赖它的上层集合必须同步响应。
修复这个问题的流程很简单，三步搞定：把报表模块直接调用Mapper的代码，改换成调用订单模块提供的Service方法；在订单模块的Service中补一个对外的数据查询方法；加上ArchUnit依赖规则，跑一次CI验证回归。
5.3 新成员快速熟悉项目结构的三步法
如果你是刚加入一个企业管理软件开发团队的新人，面对一个陌生的项目仓库，可以用下面的三步法快速上手。
第一步：先读文档。打开docs/project-structure.md，理解模块划分和依赖关系；没有文档的项目，先看根目录下的README，再看顶层目录树，自己尝试梳理模块关系。
第二步：跑通一个“最小业务链路”。不要急着研究所有代码，选一个最简单的业务功能，比如“用户登录”或“查询客户列表”，从前端发起的接口请求开始，一路追踪到后端Controller、Service、Mapper、SQL，再回到前端页面渲染，把整条链路的代码全部读一遍。一个流程跑通，整个项目结构在你的大脑里就建立起了坐标。
第三步：动手加一个“小而完整”的功能。比如新增一个字典类型的增删改查。这个功能会涉及前端页面、API封装、后端Controller、Service、Mapper、权限配置、菜单配置，是一整套完整的骨架演练。完成这个功能之后，你对项目结构的理解就已经达到了可以直接改业务代码的水平。
6. 后续扩展方向与个人实操体会
6.1 API文档自动化与前后端联合调试
项目结构稳定之后，下一步建议引入API文档自动化工具。Spring Boot项目可以接入SpringDoc，前端项目可以直接通过Swagger地址调试联调接口。这一步的意义在于：把接口定义变成前后端都能实时查看的契约文档，减少“前端等后端写完才能联调”的等待时间。
实际操作中还有一个细节：后端Controller的注释注解要写全，包括参数说明、返回值说明、异常码说明。不要嫌麻烦，注释越全，前后端协作越顺，线上排查问题越省力。工具本身是死的，但注释和规范是活的——好的注释能让接口文档的质量倍增。
6.2 多环境配置与持续集成流水线
在项目骨架已经稳定、接口文档自动化的前提下，就可以把流水线搭建提上日程了。标准的CI流程分为四步：代码提交后触发编译构建，跑单元测试与依赖规则校验，构建镜像并推送镜像仓库，再自动部署到测试环境。每一步之间环环相扣，与项目目录结构保持一致——构建脚本读取backend与frontend目录，测试脚本扫描test目录，部署脚本读取deploy目录。流水线不是独立的工程，从第一天起就要与目录结构绑定。
6.3 我的几点实操建议
《看潮企业管理软件》做到当前阶段，我个人的体会是：项目结构设计最关键的功夫，在动手写第一行代码之前就已经开始了。花两天时间把模块划分和依赖边界讨论清楚，比花两周时间在后期重构目录要划算得多。
另外命名规范这事，越早统一越好。团队里有十个成员，如果每个人各自风格命名，三个月后项目目录就会形成十种风格。命名不是审美问题，是工程效率问题。统一的命名让任何一个成员都能不看文档，直接通过目录名和类名猜到代码的职责。
最后，目录结构不是死板的教条，它是对你业务模型的映射。如果有一天业务模块发生了变化，别怕调整目录结构——前提是调整后的结构比之前更清晰，而不是让文件在目录间反复流浪。好结构永远是持续优化出来的，不是一次设计出来的。
我在实际开发中最喜欢的一个技巧是：每次开始一个新功能前，先花五分钟在目录树里“走一遍”——这个功能涉及哪些模块、需要在哪些包下新增代码、是否会引入新的依赖关系。想清楚这三点再写码，基本不会再遇到“代码写到一半发现放错模块”的尴尬局面。这个习惯也推荐给你。
