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