整潔架構粗略介紹

下圖為整潔架構最原始的結構圖：

Entities/Models：實體層，官方說法就是封裝了企業(yè)里最通用的一部分邏輯，也可以叫 Models, 可能是只包含數(shù)據(jù)字段的對象，也可能包含方法，具有一部分業(yè)務邏輯。更加深入就是領域驅動（DDD）開發(fā)相關的內容。
Use Case/Service：包含核心業(yè)務邏輯。
Interface Adapter：適配層/膠水層，負責內圈的 entity 和 use case 同外圈的 external interfaces 之間的數(shù)據(jù)轉化。需要把外層服務的數(shù)據(jù)轉化成內層 entity 和 usecase 可以消費的數(shù)據(jù)，反之亦然。
External Interfaces：依賴的外部服務，第三方框架，以及需要糊的頁面 UI 都歸屬在這一層，這一層完全不感知內圈的任何邏輯，所以無論這一層怎么變( 組件庫由 Element UI 改為 Ant Design Vue ，數(shù)據(jù)庫由 MySQL 改為 PostgreSQL )，都不應該影響到內圈。

這不就是后端的 mvc 嗎?

好處

更好的做單元測試：業(yè)務邏輯可以在沒有 UI、數(shù)據(jù)庫、Web 服務器或任何其他外部基礎設施的情況下被測試。
減少對UI框架的依賴：跨端開發(fā)，業(yè)務邏輯層可以直接復用，只需要做 UI 層的適配。
基礎設施無關性：內層業(yè)務邏輯不需要關心數(shù)據(jù)來自哪里，提交到哪里，比如 LocalStroage、IndexedDB、Web SQL、JSbridge、HTTP、WebSocket。

轉化為適用于前端工程的結構

Service，Model 都為純 JS 類/對象，與框架無關。

基礎服務虛線表示并不是直接調用相應的 API，而是封裝在工具庫或者函數(shù)中。

如何真正的落地？

presenter/controller 創(chuàng)建 model，service 實例，并且將 model 注入 service 中。service 中使用 model 做業(yè)務邏輯計算。同時 presenter/controller 內調用 service 方法處理 view 事件，同時將 model 返回到 view 層中做數(shù)據(jù)綁定

問題：model 是純 JS 對象，如何讓 model 數(shù)據(jù)變更的時候觸發(fā) view 的更新？

mobx，@formily/reactive 將 model 變成響應式的；造輪子 - 發(fā)布訂閱模式