前端项目结构设计最佳实践

《如何写出高质量的前端代码》学习笔记

问题背景

在前端项目开发中，经常遇到以下困扰：

1. 文件放置困惑：新增文件时，不知道该放在哪个目录。
2. 公共组件位置：公共组件被多个页面使用，但不确定是否应该放在公共目录。
3. 文件查找困难：修改bug时，难以快速定位到相关文件。

评价标准

一个好的项目结构应该满足以下标准：

• 增: 创建文件时不会纠结，文件位置唯一确定
• 删: 可以轻松删除功能模块，不会和其他模块有过多耦合
• 改/查: 可以快速定位到文件，如同访问哈希表而非遍历链表

核心设计原则

1. MECE法则

MECE (Mutually Exclusive, Collectively Exhaustive) 即"相互独立，完全穷尽"。

实现方法：

• 二分法：如代码/非代码；

• 要素法：按照属性分类，如将common目录划分为组件components、工具库utils、常量const、配置config、api服务service、样式style、指令directive、中间件middleware、 资源assets；

• 流程分析法：按照流程顺序分解，如

  1. 开发前准备工作（接口mock、打包配置build）；
  2. 业务开发（一般源码放在src目录）；
  3. 测试（test目录存放测试用例）；
  4. 部署（deployer目录存放部署脚本或CI/CD配置）；
  5. 上线（doc目录存放帮助文档）。

• 矩阵分析法：使用矩阵划分问题

2. 分层思维

前端项目可以分为以下层次：

    .
    ├── 通用组件层    // 业务无关的基础组件
    ├── 项目基础组件层 // 项目通用但非业务组件
    ├── 业务组件层    // 特定业务模块组件
    └── 页面组件层    // 与路由对应的页面组件

    .
    ├── base               //公共资源目录
    │    └── components    //项目基础组件
    │       ├── MyTable    //通用table组件
    │       ├── MyForm     //通用Form组件
    │       └── MyDialog   //通用弹窗组件
    └── src
        ├── components    //业务组件
        │   └── user
        │       ├── UserSelect
        │       └── UserList
        └── pages        //页面组件
            ├── user-list   //页面组件引用业务组件和基础组件
            └── user-detail

调用原则：高层可以调用底层，底层绝不能调用高层。

3. 领域驱动设计(DDD)

领域驱动设计（DDD，Domain-Driven Design）是一种软件开发方法论，旨在通过对业务领域的深入理解和建模来指导软件设计和开发。DDD的核心思想是将业务逻辑和领域知识紧密结合，以便更好地反映业务需求和变化。

建立领域层存放业务实体的核心设计：

    └── domain         
         ├── user          // 用户模型
         │  ├── const      // 常量配置
         │  ├── service.js // 接口调用
         │  ├── components // 组件
         │  ├── config.js  // 配置
         │  └── utils.js   // 工具函数
         └── product       // 产品模型
            ├── const    
            ├── components 
            └── ...

4. 就近原则

• 逻辑相近的资源应该放在一起
• 同一个修改原因影响的文件应该放在相近位置
• 避免功能分散在多个目录

5. 一致原则

• 目录/文件命名保持一致的规范
• 目录内容要和目录名称相符
• 组件命名要和路由路径保持一致

实践方案

完整思维导图如下：

完整的项目结构示例：

    ├── dev         // 工程代码
    │    ├── mock      // mock数据
    │    ├── build     // 编译配置
    │    └── test      // 测试文件 
    ├── deployer    // 部署文件
    │    ├── Dockerfile      
    │    └── nginx     
    ├── doc         // 文档
    │    └── help.md     
    ├── domain      // 领域层
    │    ├── user         
    │    │  ├── const          
    │    │  ├── service.js     
    │    │  ├── components     
    │    │  ├── config.js      
    │    │  └── utils.js       
    │    └── product       
    │       ├── const    
    │       ├── components 
    │       └── ...
    ├── src         // 应用层
    │    ├── assets     // 资源文件  
    │    ├── layout     // 布局文件  
    │    ├── router     // 路由配置  
    │    ├── store      // 共享数据  
    │    └── pages      // 页面组件
    └── base        // 基础层
         ├── const      // 常量配置
         ├── styles     // 公共样式
         ├── utils      // 公共库
         └── components // 基础组件

关键收益

• 目录职责清晰，边界明确
• 文件位置唯一确定，避免纠结
• 快速定位文件位置
• 便于功能模块的增删改查
• 降低团队协作成本
• 提高代码可维护性

最佳实践建议

1. 在项目初期就制定清晰的目录规范
2. 严格遵循分层原则，避免循环依赖
3. 使用领域驱动设计组织业务代码
4. 保持命名规范的一致性
5. 定期进行目录结构的优化和重构

总结

好的项目结构需要在设计时充分考虑MECE法则、分层思维、领域驱动设计、就近原则和一致原则。没有绝对的标准答案，但只要遵循这些原则，就能设计出清晰、易维护的项目结构。最重要的是要根据团队和项目的具体情况，选择最适合的组织方式。