《垂直代码库:告别按类型分层,拥抱按业务域组织》

标签:#前端 #代码组织 #架构设计 #Monorepo #React #软件工程

总结:

本文主张前端代码库应从"水平分层"(按 components/hooks/utils 技术类型划分)转向"垂直切片"(按业务域/功能域组织)。作者以 Sentry 代码库十年演进为例,指出水平分层会导致代码分散、认知负荷高、耦合混乱;而垂直组织将同一业务域的组件、工具、类型内聚到一起,配合 Monorepo 的显式边界(exports/eslint-plugin-boundaries),能显著提升可维护性。虽然确定正确的垂直划分需要更多团队沟通,但这是支撑代码库长期演进的必要投资。

文章要点:

- 水平分层的隐患:把代码按 components / hooks / utils / types 分类虽然上手简单,但随着项目膨胀,同一业务逻辑会被拆得七零八落——比如 PageFilters 的组件、类型、工具函数散落在三个目录,改一个小需求要跳来跳去, cognitive load 直接拉满
- 垂直切片的核心思想:不按"技术类型"而按"业务域"分组,把同一个功能域(如 dashboard、profiling、billing)相关的组件、Hook、工具、类型全部收进一个目录;就像当年我们把 HTML/CSS/JS 从三层文件合并成组件一样,这次是更高维度的"关注点内聚"
- 与团队结构天然对齐:现代产品团队通常是端到端的功能团队(dashboard 团队、replay 团队),垂直代码结构让 CODEOWNERS 和包边界直接对应团队职责,谁负责什么一目了然
- 解决跨域复用焦虑:不是所有代码都严格属于某个页面,像 PageFilters 这种被多页面使用的通用能力,完全可以作为独立垂直域存在;关键是按"逻辑关联"而非"物理位置"来划分
- 用边界守护架构:垂直化后还需降低耦合,推荐通过 Monorepo + package.json#exports 显式暴露公共 API,或借助 eslint-plugin-boundaries 禁止深路径导入,把"私有实现"真正保护起来
- 没有银弹,但值得投入:确定合理的垂直域确实比"丢进 utils"更难,也可能出现不同团队重复造轮子;但作者认为这恰恰促进了团队沟通,而沟通本就是软件工程最难也最重要的部分

文章URL:

https://tkdodo.eu/blog/the-vertical-codebase The Vertical Codebase
 
 
Back to Top