若看了上篇笔记，眼尖的铁汁们应该发现，最终的重构成果并未出现目录结构调整方案提到的 domain 文件夹。

这是因为领域建模是个相对较难且需要长期去做的事情，所以我们不急，慢慢来，要用心地思考与处理——从本篇笔记开始就会涉及到相关内容啦！

在进行实际的铲演练之前，这篇笔记先来讲解下 domain 文件夹的重要性，请各位铁汁搬来小板凳坐坐好，用小拇指清理下听我说——

在我所设计的「模块化」目录结构划分模式中，包含了 shared、domain 和 entry 这三个核心的顶级文件夹，作用分别为：

domain 文件夹是这个模式的重中之重——整个应用的绝大部分逻辑都在这，重要性不言而喻；正因如此，它所含的代码量是重量级的，相比之下另外俩文件夹十分轻量，尤其是 entry 文件夹。

由于我接手的官网项目用了 Next.js，受限于它的机制，以规定的 app 文件夹担任 entry 文件夹的角色。

很多前端开发人员对「模块化」理解不够深入，以为将某段代码存到另外一个文件中被其他文件引用就算「模块化」了，如封装个工具函数、UI 组件之类。

这种「模块化」有效果，但在做应用开发时没太大效果，「模块化」业务逻辑才能最大限度地发挥作用——领域建模——这也是很多前端开发人员所欠缺的能力。

domain 文件夹下的子文件夹存放的就是一个个抽象好的业务模块，每个模块绝对遵守「高内聚，低耦合」——只有本模块相关代码，对其他业务模块的依赖要有明确的语义声明。

一个业务模块的目录结构大致为：

若像绝大多数项目那样使用「野生」模式不分青红皂白地把文件往全局的 services、components 等文件夹中一甩的话，所遇到的最直观的问题就是——

做业务时得在它们下面的众多文件夹中识别出要修改的文件，每次切换不同类别的文件夹都需重复此过程，关注点无法聚焦，十分影响效率！

这是因为按文件类别划分的思路强行打散了从业务角度更为紧密相连的文件，真可谓是「棒打鸳鸯」啊！

因没有按业务去抽象并复用模块，UI 组件、页面中的依赖关系极容易变得万分混乱，最终会演变成难以解开的结，进一步影响开发效率与应用质量。

我设计的「模块化」模式中的 domain 文件夹就是这个顽疾的特效药，就像不同颜色的束线带一般能够很好地整理并约束好那些「线」的走向，让整个应用变得井井有条！

除此之外，理想状态下，domain 文件夹下的每个业务模块还能按需要用在不同的应用中——跟那些用 npm 包安装的通用模块一毛一样！

咋样？「模块化」模式的好处和 domain 文件夹的重要性，铁汁们感受到了吗？

本文其他阅读地址：小红书｜微信公众号