按类型与按业务的控制器、路由等目录结构优劣对比及选型建议

一、两种结构定义 #

首先明确两种常见的后端项目目录组织方式：

1. 按功能类型划分（分层结构）：

model/user.js
route/user.js
service/user.js
controller/user.js

2. 按业务模块划分（领域结构）：

user/model.js
user/route.js
user/service.js
user/controller.js

二、按功能类型划分的结构 #

优势 #

• 技术分层清晰：同类型文件集中存放，新开发者能快速定位所有模型、路由、业务逻辑文件，对项目的技术架构一目了然。
• 全局修改高效：当需要统一调整某一类功能的逻辑（比如所有控制器的请求参数校验规则）时，无需跨多个目录，操作更便捷。
• 规范易统一：适合技术驱动的团队或项目初期，便于统一各技术层的编码风格与实现规范。

劣势 #

• 业务关联分散：查找单个业务模块（如用户模块）的全链路代码时，需要在多个目录间来回切换，业务模块越多，跳转成本越高。
• 拆分成本高：若后续要将某个业务模块拆分为独立服务，需从不同目录中收集对应文件，容易遗漏或出错。
• 耦合风险高：业务逻辑分散在不同目录，长期维护中易出现跨模块的不合理耦合，增加维护难度。

三、按业务模块划分的结构 #

优势 #

• 业务独立性强：单个业务模块的所有相关文件集中存放，查找、修改某业务的全链路逻辑时无需跨目录，效率极高。
• 微服务拆分友好：天然适配微服务架构，拆分业务模块为独立服务时，直接复制整个业务目录即可，几乎无需调整路径，成本极低。
• 业务边界清晰：各模块职责明确，团队可按业务线分工协作，减少跨模块的不必要耦合，便于维护业务逻辑的完整性。

劣势 #

• 新手入门门槛高：新开发者无法快速看到项目的整体技术分层，需要逐个模块了解结构，初期上手较慢。
• 重复代码风险：不同业务模块可能出现相似的工具逻辑（如响应格式化、通用校验），若无统一公共层，易产生代码冗余。
• 规范统一难度大：各模块的同类型文件（如控制器）可能出现不同的编码风格，需要额外制定跨模块的技术规范来约束。

四、权衡点与适用场景 #

• 选按功能类型划分：适合业务简单、模块较少的项目初期，或团队更侧重技术架构统一的场景，能快速搭建清晰的技术分层框架。
• 选按业务模块划分：适合业务复杂度高、模块众多的成熟项目，或未来有微服务拆分计划，以及团队按业务线分工协作的场景，能大幅提升业务维护效率，降低拆分成本。
• 折中方案：可结合两种结构，保留全局公共目录（如utils/、config/），核心业务代码按模块组织，兼顾技术规范与业务独立性。

内容的提问来源于stack exchange，提问作者Federico