https://github.com/music4kid/Data-Driven-Architecture-Swift

數據驅動是一種思想，數據驅動型編程是一種編程範式。基於數據驅動的編程，基於事件的編程，以及近幾年業界關註的響應式編程，本質其實都是觀察者模型。數據驅動定義了data和acton之間的關系，傳統的思維方式是從action開始，一個action到新的action，不同的action裏面可能會觸發data的修改。數據驅動則是反其道而行之，以data的變化為起點，data的變化觸發新的action，action改變data之後再觸發另一個action。如果data觸發action的邏輯夠健壯，編程的時候就只需要更多的去關註data的變化。思考問題的起點不同，效率和產出也不同。

Data-Driven-Architecture

2.分層架構

我們將DDA的架構分為三層：

這三層每一層都向下依賴，每一層之間通過面相接口編程的方式產生關聯。

Application Layer

在CDD的討論裏已經詳細的介紹過應用層（Application Layer）的實現方式和數據流向。DDA裏應用層的實現差不多，只不過實現語言換成了Swift。這一層主要由我們熟悉的UIViewController組成，工作職責包括采集用戶數據和展示UI。采集數據是指數據從Application Layer流向Service Layer，展示UI是指觀察Service Layer流入的數據變化並改變UI。可以假設這樣一個業務場景來說明Application Layer的工作：用戶在SettingController裏改變自己的用戶名。

數據的流出（采集數據）

用戶在SettingController的輸入框裏輸入新的用戶名，產生newName: String，newName需要傳輸到Server，收到成功回執之後再改變Controller當中的展示。這個完整的流程當中newName就是我們所關心的業務數據，在newName流向Service Layer之前我們可能需要進行校驗（名字是否為空或超過了最大長度），這部分的邏輯更貼近界面的工作，且不涉及任何網絡和DataBase操作，所以可以放在應用層。如果通過了校驗，下一步就是將newName通過請求告訴Server，所有的網絡和DataBase操作都發生在Service Layer，所以我們只需要將newName傳輸到Service Layer，到這一步就完成了數據的流出。

數據的流入（改變UI）

Application Layer將newName輸出到Service Layer之後，接下來只需要作為觀察者監控user: UserProfile這個model當中name property的變化。user model是一個viewModel，使用上和MVVM當中的ViewModel概念一致，ViewModel定義在應用層，但會通過事件觀察者的方式綁定到Service Layer當中的RawModel。ViewModel負責把RawModel當中的數據轉化成View所需要的樣式，View在完成UI的配置之後就不需要維護其它的業務邏輯了。

Service Layer

Servicec Layer負責所有的網絡請求實現，DataBase操作實現，以及一些公用的系統資源使用接口（比如GPS，相冊權限，Push權限等）。對於Application Layer來說Service Layer就像是一個0ms延遲的Server，所有的服務都通過protocol的方式暴露給Application Layer。Service Layer和Data Access Layer（DAL）使用相同的RawModel定義，RawModel定義在DAL，從sqlite當中讀出數據之後就會被馬上轉化成RawModel。RawModel不要和View進行直接綁定，通過ViewModel中轉可以將數據改變的核心邏輯放在同一的地方管理，調試的時候會很有用。上面修改用戶名的例子傳入的newName，在這一層通過ModifyUserNameRequest通知Server。ModifyUserNameRequest成功回調之後將user model的name property修改為最新值。name一修改Application Layer對應的View立刻會收到數據改變的事件並展示新的name。Service Layer接下來需要把newName保存到數據庫當中，涉及到和sqlite的交互。所有和sqlite直接打交道的工作都是交給Data Access Layer來做。

Data Access Layer（DAL）

DAL層對下負責和數據庫直接交互，對上通過protocol的方式提供數據操作的接口給Service Layer。數據庫我們使用sqlite。DAL層不涉及任何具體的業務邏輯，只提供基礎的CRUD接口，這樣一旦DAL層穩定下來，項目中後期出現業務bug基本就可以省去在DAL層調試。RawModel也定義在DAL，有些項目會在Service Layer和DAL各自定義自己的model，但每多一層model定義，就多了一次轉換和維護的邏輯，對於大部分的項目來說其實沒這個必要。DAL除了提供CRUD之外，還需要搭建線程模型，讀寫要分線程，而且需要同時提供同步異步兩套接口。

這樣初步進行職責劃分後，我們可以得到一個細一點的層次圖。

DDA架構學習總結