大家好，EluxJS是一套基于“微模塊”和“模型驅動”的跨平臺、跨框架『同構方案』，歡迎了解...
可怕的巨石怪
作業中最可怕的是什么？是遇到業務復雜且亂作一團的巨石應用，改一發而動全身，無法漸進式重構，也沒人敢對歷史包袱進行優化，欠下的代碼債只能像滾雪球一樣越積越多，終于到某天玩不下去，大佬選擇了跑路??...
不管多么優秀的團隊，都不可能一蹴而就的構建好應用，精品一定是在不斷優化與重構中打磨成熟的，而這一切的前提是你得擁有一個松散、解耦的工程結構，能把不同領域的問題控制在一定范圍內，而不是動不動就全身檢查動刀，
把巨石怪橫向切開：分層而治
蛋糕橫向切開：巧克力層、奶油層、蛋糕層、水果夾心層...
如果我們把一個應用橫向切開，也應當是一層一層的邏輯和代碼：
為什么要分層？
除了讓專注的領域更專注，更可以避免穩定代碼受到多變代碼的頻繁騷擾，避免通用的邏輯被特定UI庫與運行平臺所綁架，
- 剝離了業務邏輯，UI層變得更純粹，它只是負責展示、互動和傳遞用戶事件，
- 剝離了UI邏輯，業務層不再受到各種生命周期和糖衣語法的干擾，更純凈透明，
- 分層而治，增加了代碼的可復用性和可移植性，
跨專案、跨平臺、跨UI框架復用業務邏輯，業務通用、UI各表：
模型驅動
應用的核心的邏輯是什么？是業務邏輯（游戲規則）而非UI互動邏輯，UI的職能只有2個：輸入與輸出，僅此而已，
UI只是指令的收集者、傳達者、反饋者，而不應當成為指令的執行者，
所以不要再把所有邏輯都一股腦的寫在React/Vue Component組件中了（業務邏輯與UI框架深度捆綁），而應當站在更高層次謀求抽象的頂層設計，這也是近年來流行所謂的“領域驅動”理念，
雖然視圖驅動所見即所得，是最直觀也是最簡單的一種思維模式，但是我們不僅要解決問題，還要思考如何優雅的解決問題，這也好比是排版和設計的區別，
把巨石怪縱向切開：業務模塊化
蛋糕不僅能橫向切層，更能縱向切塊，滿足更多人享用...
同樣對于一個巨石應用，我們也應當對不同的業務功能進行切塊：按照不同的業務功能，不同的業務領域進行模塊化，在Elux工程中稱之為微模塊，
自治與組合
這些被切成一塊一塊的蛋糕，每塊都包含巧克力層、奶油層、蛋糕層、水果夾心層...
每一個前端“微模塊”，類似于后端“微服務”，各自負責業務中某子領域的具體事務，它們謀求獨立自治（有各自獨立的UI層、Model層、服務層...麻雀雖小、五臟俱全），并且可以像積木一樣組合成不同產品，
也可以跨工程共享業務代碼：
視圖插槽
前端微模塊和后端微服務都是一些彼此松散的個體，平時不相往來，向后端發送一個API請求，就可以把不同鏈路上的各種微服務串聯起來，共同完成一個業務動作，
而串聯前端各種微模塊的手段則是視圖插槽：
各個微模塊的UI層彼此聚合嵌套在一起，共同組合成應用的UI界面：
被肢解的巨石怪
經過橫劈豎斬，可怕的巨石應用已經被徹底的肢解了：
現在每個領域問題都有了自己明顯的邊界，你再也不用擔心牽一發而動全身了，有空就挑一塊出來進行區域重構吧，重構完再放回去，持續重構持續集成...
最后歡迎大佬們共同探討，不舍賜教，更多想法參見官網：https://eluxjs.com/
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/538067.html
標籤：其他