程式設計源於生活

程式設計是什麼？我們寫的業務程式碼是什麼？它和我們的現實世界有什麼關係？ 我之前一直在想這個問題。現在我覺得，程式碼是對現實世界的一種抽象，源於生活又高於生活，他通過資料的方式來抽象現實世界的一些過程，可能是一次商業活動，可能是一次運動的過程等等。 資料是最基礎的東西，資料來源於自動採集的和使用者輸入的。我們做業務開發首先要建立起你所關心的業務對應的資料模型，然後基於這個資料模型做各種資料的管理以及分析等各種之上的操作，讓這個業務過程以及資料本身產生商業價值。 ###資料的流動 資料模型設計好了，他落實到物理儲存可能是各種資料庫，關係型、物件型、文件型、圖型等等，根據資料模型的特點選擇不同的方式來儲存。之後服務端會連結到資料庫，然後在服務端建立起對應的資料模型，比如用java的orm框架hibernate，mybatis等，然後對資料模型的各種操作就是業務的過程，各種業務邏輯在這裡來做，這是model層，暴露的是對資料模型各種操作的介面。之後介面暴露出去，通過http、websocket、rpc、訊息佇列等各種方式，這一層算是服務端的view層，view層和model層之間是多對多的關係，之間複雜的呼叫關係一般單獨一層，叫做controller層，這一層一般很薄，不含任何業務邏輯。 之前的前端屬於服務端view層的一部分，沒有任何的資料，只是純粹渲染，有了ajax以後，慢慢發展到現在的單頁應用，前端需要在本地維護一套資料模型，然後同時也要暴露基於這個資料模型的各種介面，之後業務邏輯單獨封裝一層，提供給view層的元件呼叫。

各層次的資料模型和業務邏輯

從大方面來看，分為 資料庫、 服務端、前端（客戶端）。 涉及到3個數據模型和對應的管理資料模型的介面，他們各有特點：

1. 資料庫：

資料庫只有資料模型和資料，沒有任何邏輯，向外暴露了管理資料模型的介面，就是sql或者是類似mongodb的js引擎等。

2：服務端：

服務端主要是管理資料庫中的資料，完成各種業務邏輯，同時提供資料給客戶端。服務端的資料模型是同步的資料庫中的，通過一定的對映關係建立對應的資料模型，然後提供對資料模型操作的介面，完成各種業務邏輯，最終通過各種協議（http、ws、rpc、訊息佇列等）暴露出去。

3. 前端（客戶端）：

前端也需要維護一個本地的資料模型，然後通過和服務端的介面通訊來保持資料模型的同步，同時提供了對資料模型操作的介面。比如用redux來管理state，那麼對應的reducer就是操作他的介面，之後基於這些管理資料模型的介面來完成一些業務邏輯，同時提供給元件來渲染，元件屬於view層，資料模型、操作資料模型的介面、業務邏輯的service屬於model層，之間多對多的對映關係其實就是元件裡事件繫結和各種方法呼叫，這樣的話元件屬於view + controller（因為實現了mvvm，所以controller更薄了）。

資料庫的資料模型、後端的資料模型、前端的資料模型，這些都應該是後者依賴前者的，所以需要通訊和同步的過程，同時為了優化一些效能，會做一些快取，當然實時性要求高的不會做快取。 除了三個層次一致的資料模型之外，也有一些不需要同步的狀態，比如前端的一些ui的狀態，比如服務端的一些上下文的資料等。 除此以外，前端的view層觸及到了人，會涉及到一些使用者心理學，設計學，會涉及到互動和設計方面的東西，這是另一門學問。

總結

總體來看的話， 其實最兩端的是 資料庫的資料模型 和 ui。 然後中間每一層都有獨立維護的資料模型， 以及基於這些模型各自的架構和介面，當然之間需要同步，同步的方式就是通過 socket，sql，http等。

當然後端到了一定的規模，會做分散式、微服務等等，資料庫也會分庫分表，這是類似的思路。比如安卓通過多程序的方式來拆分複雜度等。

總之，建立起資料模型，和前後端對應的架構。之後就是使用者的各種互動，產生的各種資料在整個系統之間流動了。