根據`業務功能`進行模塊化一直以來都是後端的普遍做法，而Web前端則通常都是按照UI界面的視圖區塊`View`來進行模塊化，這樣的模塊實際上只是`Component組件`，不具備獨立自治的能力。究其原因我想是因為在早期Web1.0的時代，前端的職能就是僅僅作為後端API數據的一個Render渲染器，... ...
大家好，我是Eluxjs的作者，Eluxjs是一套基於“微模塊”和“模型驅動”的跨平臺、跨框架『同構方案』，歡迎瞭解...
文前聲明，以下推斷和結論純屬個人探索，鑒於本人知識水平所限，謬誤在所難免，懇請各位大佬不吝賜教...
什麼是前端“微模塊”？
Elux中的『微模塊』是指在Web前端工程中，將代碼和相關資源按照不同的業務功能進行歸類和模塊化。
根據業務功能進行模塊化一直以來都是後端的普遍做法，而Web前端則通常都是按照UI界面的視圖區塊View來進行模塊化，這樣的模塊實際上只是Component組件，不具備獨立自治的能力。究其原因我想是因為在早期Web1.0的時代，前端的職能就是僅僅作為後端API數據的一個Render渲染器，所以前後端的視野和格局出現了分化，也導致很多人說前端根本無架構之說。
然而web生態發展到今天，瀏覽器越來越強大，賦能越來越多，甚至不亞於一個小型操作系統，這時候的Web前端早已不是當初簡單的數據渲染器，狀態管理、會話維持、數據持久化、文件緩存、通信協議...隨著PWA、小程式、快應用的推廣，WebAPP不再是瘦客戶端，漸漸成長為大胖小子。
此時的我們應當跳出“渲染器”的井口，而從一個完整的軟體工程來思考我們的前端架構，Web前端不只是一層View、一個GUI，我們需要回歸到與後端一致的以業務領域為驅動的模塊化視角。
為什麼前端需要“微模塊”？
-
從開發角度來說：我們需要
高內聚、低耦合的鬆散結構體，而不是牽一發而動全身的巨石應用，這不管是對於開發、維護、還是後期漸進式重構，都至關重要。前端Leader：經過一年多的迭代和人員變動，我們代碼已經混亂不堪了，開發越來越吃力，必須要重構，否則玩不下去了！ 產品經理：嗯，我理解，這裡面也有很多是我們需求變更頻繁引起的，我支持你們重構！ 前端Leader：感謝大佬理解，那新需求先停下來，等我們重構好了再迭代吧？ 產品經理：你們重構要多久？ 前端Leader：產品這麼複雜了，估計至少要3個月左右吧。 產品經理被嚇出一身冷汗：大佬，你要3天還可以考慮，停下來3個月估計公司都要關門了... 前端Leader：可是產品這麼複雜，幾天時間完成重構是天方夜譚。 產品經理想了想：這樣把，我每個迭代少安排幾個需求，這樣你們每個月就可以留幾天時間重構了。 前端Leader：這可不是1+1=2的問題，而是0與1的問題，大佬你不瞭解！ 產品經理：誰說我不瞭解，你們就不能漸進式重構嗎？ 前端Leader：...此時如果我們的前端工程是基於“微模塊”，一來可以輕鬆的找到“局部重構”的
邊界，二來也可以通過維持“微模塊”的對外介面來無極替換。 -
從產品角度來說：軟體架構永遠是服務於業務需求的。我們希望我們的產品能像搭積木一樣
按需組合，可以快速包裝出各種靈活多樣的套餐，以滿足客戶越來越精細化的定製需求。某個大型應用包含A,B,C,D,E,F,G等若幹功能，原來一直是整體打包出售... 隨著用戶需求的多樣化，有的用戶僅需要部分功能，於是聰明的前端架構師“小李”利用時下流行的微前端技術， 將應用拆分成了的 3 個子應用： - 【基礎應用】包含功能：A - 【子應用A】包含功能：B,C,D - 【子應用B】包含功能：E,F,G 這樣等於有 3 個套餐可以供客戶選擇： - 套餐A：基礎應用 + 子應用A - 套餐B：基礎應用 + 子應用B - 套餐C：基礎應用 + 子應用A + 子應用B 然而用戶的需求越來越精細化，有的需要ABCD，有的需要ACEG，有的需要ABDF... 而且同一個功能可能還存在需求版本的不同，這讓“小李”無可適從。現在我們利用“微模塊”來幫助小李解決問題：
- 將各種獨立的業務功能封裝成不同的微模塊：A,B,C,D,E,F,G
- 將各種微模塊按需求迭代版本，發佈成NPM包
- 某客戶需要 A,C1(
C功能的某個版本),E2(E功能的某個版本),G 功能，我們單獨為該客戶創建一個聚合工程分支，安裝相應版本的微模塊：npm install A C@1 E@2 G
我們知道世界上有一款建站神器
wordpress，曾經號稱世界上50%的網站都是由它創建的，我認為它的成功秘訣就是社區模版機制和功能插件化，你要什麼功能都總能找到“前端+後端”一起打包安裝的插件，這也類似於“微模塊”的概念。
- 從工程的角度來說：“微模塊”是跨工程、跨項目共用
通用業務代碼的理想決方案，對於跨端、跨平臺復用業務邏輯尤其有用。
前端“微模塊”的劃分原則與邊界
- 擁有
高內聚、低耦合的工程結構。 - 擁有
獨立自治的子域邏輯。
從圖中可以看到，每個微模塊負責定義和維護自己領域內的事務，並且麻雀雖小，五臟俱全，擁有獨立的路由解析、狀態管理、數據模型、控制器、視圖、組件、資源、業務實體、API管理等等...總之，所有與自己領域相關的資源都被內聚到了一起。
以下是某巨石應用的SRC目錄，其特點是以“文件職能”作為一級分類、“功能模塊”作為次級分類：
├─ src
│ ├─ api # API介面管理
│ ├─ assets # 靜態資源文件
│ ├─ components # 全局組件
│ ├─ config # 全局配置項
│ ├─ enums # 項目枚舉
│ ├─ hooks # 常用 Hooks
│ ├─ language # 語言國際化
│ ├─ layout # 框架佈局
│ ├─ routers # 路由管理
│ ├─ store # store
│ ├─ styles # 全局樣式
│ ├─ typings # 全局 ts 聲明
│ ├─ utils # 工具庫
│ ├─ views # 項目所有頁面
│ ├─ App.vue # 入口頁面
│ └─ main.ts # 入口文件
以下是Elux中基於微模塊的SRC目錄，其改進是將“功能模塊”作為一級分類，“文件職能”作為次級分類：
src
├── modules
│ ├── ModuleA
│ │ ├── entities
│ │ ├── assets
│ │ ├── api
│ │ ├── utils
│ │ ├── language
│ │ ├── components
│ │ ├── views
│ │ ├── model.ts
│ │ └── index.ts
│ │
│ ├── ModuleB
│ ├── ModuleC
微模塊的台前與幕後
前端開發最終呈現的是UI界面，但這隻是表象，支撐UI界面渲染和交互的是背後一系列state、model、controller等幕後英雄，它們根據自己所屬不同領域被封裝在各個微模塊中，UI既然與它們唇齒相依，必然也將跟隨它們內聚在一起。
View和Component
本質上說View就是一個Component，但我們從架構的思維來區分它們：
- View：業務視圖，它用來表現業務規則與邏輯，通常能夠較為獨立和完整的解決某一領域問題。
- Component：UI組件，它用來表現渲染規則與交互邏輯，通常不與具體業務直接相關，可復用在各種不同業務場景中。
所以在“微模塊”的架構中，豐富多彩的UI界面由一個個單一職責的View聚合而成，每個View同樣依據自身所解決的領域問題而被分散在各個微模塊中，這裡面有幾個註意點：
- 領域性：View被歸屬到不同
微模塊的原則是其解決的問題領域，而不是視覺上的幾何空間。View可以在視覺上被拆裝、聚合、嵌套，這並不影響它們所屬微模塊。 - 完整性：一個View通常能解決一個較為獨立和完整的問題，View與View之間是較為鬆散的關係，如果2個View之間聯繫緊密，那就不應當拆分它們。
不以視覺延伸和幾何空間作為View的微模塊歸屬原則：如下圖所示，假設有一個View用來展示用戶資料，我們將其放在UserModule這個微模塊中，稱其為UserModule.DetailView，但你發現其中又包含一個該用戶發表文章的列表，你當然可以把這個列表單獨提取出來作為一個新的View。從視覺上來看，它似乎和用戶資料是連在一起的，似乎可以和UserModule.DetailView放在同一個微模塊中；但我們從它解決的問題來看，它屬於文章領域，而與用戶領域關係並不大，所以我們最好將其放在ArticleModule中，稱其為ArticleModule.ListView
前端“微模塊”的實現方案
- 定義和創建微模塊，可藉助於Eluxjs框架，當然你發現了其它框架也可以。
- 管理微模塊，可藉助於NPM倉庫。
- 使用微模塊，可藉助於打包工具：
- 靜態編譯：微模塊作為一個NPM包被安裝到工程中，通過打包工具（如webpack）正常編譯打包即可。這種方式的優點是代碼產物得到打包工具的各種去重和優化；缺點是當某個模塊更新時，需要整體重新打包。
- 動態註入：利用
Module Federation，將微模塊作為子應用獨立部署，與時下流行的微前端類似。這種方式的優點是某子應用中的微模塊更新時，依賴該微模塊的其它應用無需重新編譯，刷新瀏覽器即可動態獲取最新模塊；缺點是沒有打包工具的整體編譯與優化，代碼和資源容易重覆載入或衝突。
微模塊 vs 微前端
從本意上來說，微模塊只是一種工程結構和模塊化方案，而微前端只是它的一種應用場景之一。微模塊架構不僅可以用來構建複雜的單體應用，也可以結合Module Federation實現多子應用獨立部署的“微前端”。
如果單獨就微模塊 + ModuleFederation方式實現的微前端，與傳統意義上的qiankun、icestark等微前端方案相比，微模塊方式勝在粒度更細、更靈活、更輕巧，而傳統方式則勝在隔離性更好。
想到一個非常形象的比喻：
IFrame vs 微前端 vs 微模塊 可類比於 進程 vs 線程 vs 協程
從左至右：越來越輕量化，隔離性逐漸變弱，靈活性逐漸增加。所以魚與熊掌不可兼得，具體哪種方案最適合還得看不同的產品需求。
微模塊之間的通信
- 微模塊之間按照某些規則和約定共用同一個Runtime，強制隔離性較弱，所以它們之間的通信是輕量級的，可以相互引用與調用。
- 建議觀察者模式，或者使用事件匯流排模式來保持微模塊之間的鬆散關係，這是另一個故事，可參考Eluxjs中的
ActionBus。 - 微模塊
高內聚、低耦合的劃分原則，也意味著微模塊之間不會出現特別複雜的互動與交流（互動密切的微模塊應當合併）。
落地與實戰
光練不說傻把式，光說不練假把式，這裡先把思路概念要說的說完，下麵就要開始出實例了。先喝口水，請聽下回分解...
