前端架構

1、 數據模型

1.領域模型
領域模型是業務數據，每每要持久化到數據庫或localStorage中，屬於可跨模塊複用的公共數據
減小了代碼重複問題，減小網絡請求，跨模塊數據同步問題不復存在

2.應用狀態模型
視圖相關的狀態數據

2、視圖層組件
1.展現型組件
保持職責單一，僅作視圖呈現和最基本交互行爲，經過props接收數據和回調函數輸出結果，
若是展現型組件粒度切分能很好的遵循高內聚低耦合和職責單一原則的話，能夠沉澱出不少可複用的通用業務組件。

3、公共服務
全部的HTTP請求放在一塊兒統一管理
日誌服務、本地存儲服務、錯誤監控、Mock服務等統一存放在公共服務層；

4、跨模塊通訊
爲避免模塊間相互耦合、確保架構長期乾淨可維護：
不在一個模塊內部直接調用其餘模塊的Dispatch方法（寫操做、變動其餘模塊的state）
不在一個模塊內部直接讀取其餘模塊的state方法（讀操做）
建議將跨模塊通訊的邏輯代碼放在父模塊中，或者在一個叫作Mediator層中單獨維護

5、數據流管理
Redux單向數據流，Redux架構的設計核心是單向數據流
1. Action
用戶操做行爲：click drag input ...
服務端返回數據後續的行爲

2. Reducer
每一個Action都會對應一個數據處理函數，即Reducer。特別強調，Reducer必須是純函數（pure function），這個規定帶來一個很是大的好處，數據處理層代碼變的很是容易寫單元測試。
純函數的特徵是入參相同的狀況下，返回值恆等，舉個栗子🌰：
純函數：
function add(a, b) { return a + b; }
非純函數：
function now() { let now = new Date(); return now; }
函數中若是包含 Math.random，new Date(), 異步請求等內容，且影響到最終結果的返回，即爲非純函數。

3. Store
Store 數據存放的地方，store保存從進入頁面開始全部Action操做生成的數據狀態（state），每次Action引起的數據變動都必須生成一個新的state對象，且確保舊的state對象不被修改。這樣作能夠保證
應用的狀態的可預測、可追溯，也方便設計Redo/Undo功能。
使用輕量級的immutable方案immutability-helper，相比徹底拷貝一份（deep clone）性能更優、存儲空間利用率更高。

總結：
嚴格遵循架構規範和單向數據流規範，能夠保證咱們的前端應用在比較粗的粒度上的可維護性和擴展性