若看了上篇筆記，眼尖的鐵汁們應該發現，最終的重構成果並未出現目錄結構調整方案提到的 domain 文件夾。

這是因為領域建模是個相對較難且需要長期去做的事情，所以我們不急，慢慢來，要用心地思考與處理——從本篇筆記開始就會涉及到相關內容啦！

在進行實際的鏟💩演練之前，這篇筆記先來講解下 domain 文件夾的重要性，請各位鐵汁搬來小板凳坐坐好，用小拇指清理下👂🏼聽我説——

在我所設計的「模塊化」目錄結構劃分模式中，包含了 shared、domain 和 entry 這三個核心的頂級文件夾，作用分別為：

• shared——無任何業務邏輯的、整個應用通用的圖片、樣式、函數等；
• domain——不受開發框架機制和頁面路由劃分限制的與具體業務關聯的圖片、樣式、函數等；
• entry——受開發框架機制和頁面路由劃分限制的應用初始化與頁面渲染「入口」。

domain 文件夾是這個模式的重中之重——整個應用的絕大部分邏輯都在這，重要性不言而喻；正因如此，它所含的代碼量是重量級的，相比之下另外倆文件夾十分輕量，尤其是 entry 文件夾。

由於我接手的官網項目用了 Next.js，受限於它的機制，以規定的 app 文件夾擔任 entry 文件夾的角色。

很多前端開發人員對「模塊化」理解不夠深入，以為將某段代碼存到另外一個文件中被其他文件引用就算「模塊化」了，如封裝個工具函數、UI 組件之類。

這種「模塊化」有效果，但在做應用開發時沒太大效果，「模塊化」業務邏輯才能最大限度地發揮作用——領域建模——這也是很多前端開發人員所欠缺的能力。

domain 文件夾下的子文件夾存放的就是一個個抽象好的業務模塊，每個模塊絕對遵守「高內聚，低耦合」——只有本模塊相關代碼，對其他業務模塊的依賴要有明確的語義聲明。

一個業務模塊的目錄結構大致為：

若像絕大多數項目那樣使用「野生」模式不分青紅皂白地把文件往全局的 services、components 等文件夾中一甩的話，所遇到的最直觀的問題就是——

做業務時得在它們下面的眾多文件夾中識別出要修改的文件，每次切換不同類別的文件夾都需重複此過程，關注點無法聚焦，十分影響效率！

這是因為按文件類別劃分的思路強行打散了從業務角度更為緊密相連的文件，真可謂是「棒打鴛鴦」啊！

因沒有按業務去抽象並複用模塊，UI 組件、頁面中的依賴關係極容易變得萬分混亂，最終會演變成難以解開的結，進一步影響開發效率與應用質量。

我設計的「模塊化」模式中的 domain 文件夾就是這個頑疾的特效藥，就像不同顏色的束線帶一般能夠很好地整理並約束好那些「線」的走向，讓整個應用變得井井有條！

除此之外，理想狀態下，domain 文件夾下的每個業務模塊還能按需要用在不同的應用中——跟那些用 npm 包安裝的通用模塊一毛一樣！

咋樣？「模塊化」模式的好處和 domain 文件夾的重要性，鐵汁們感受到了嗎？

本文其他閲讀地址：小紅書｜微信公眾號