系統化服務構建-軟件工程分層

本文主要探討軟件項目開發中的工程，涉及軟件分層，業務分離等概念。軟件工程一般是說以工程的原理，原則和方法指導軟件開發，以解決軟件危機。

狹義的工程概念

本文中的涉及的工程概念是一個狹義的工程。

這裏對工程作一個定義：軟件開發中組織源代碼的方式，用於實現軟件開發需求，最終交付用於軟件運行。工程與語言無關，或者說每一種語言都會涉及到工程，不一樣的語言根據語言特性會有不一樣的側重。

這篇文章起源於一張圖

圖 1 是《極客時間》一個微課程中的一張 Go 項目工程圖，印證了我這些年開發設計中對於工程建立的一些理念想法，敘述以下。

業務領域模型

首先 Model 是一個業務領域概念，對應的業務模型，而非數據庫字段或者說數據庫字段的映射。這一點在 PHP 中被誤解的尤爲明顯，你們都覺得模型就是數據庫的表映射。爲何在 PHP 從業者眼中 Model 就表明着數據表，說白了就是 PHP 的項目業務簡單到不足以啓用領域模型相關的設計，進而咱們能夠思考 PHP 數據結構中慣用數組而非屬性也是一樣的道理。

思考 這幾個例子，客戶和用戶，帳戶和用戶，通行證和用戶，分別在程序上如何定義,輔以常見的產品說明? 這幾個都是典型的業務域。

分層設計

分層設計是老話題了，軟件設計的核心就是自上而下，分而治之。圖 2 是我以前架構的一個項目，自上而下，分別是應用層 Apps，服務層 Services，倉庫 Repository，公共組件 Core。

理論如此，實踐中的難度在於區分的粒度和度量標準。如下是幾個參考：

數據層與業務層分離

數據抽象爲數據訪問，直接與數據存儲進行交互。業務抽象爲功能模塊，業務組件，直接與用戶交互。數據也就是圖 1 中的 DAO，圖 2 中的 Repository。業務也就是 Model。DAO 與 Model 並不存在嚴格的對應關係。

DAO 主要與數據庫存儲交互，不參與業務邏輯。
對外暴露的接口數據不單單是數據庫字段的單純映射，業務領域應該是用 Model 表示。
數據層和業務層分離的實踐很簡單。遵循兩點：

第一代碼目錄分離

第二數據層獲取數據時，只獲取不處理邏輯，不夾雜大小比較，數據類型判斷等便可，拋給上層。

提及來簡單，知易行難，落實了纔算數。

業務組件與基礎設施層分離

咱們談到基礎設施，更多的會想到雲計算領域的 PAAS，本文中把這個概念狹義的控制在軟件層面的項目範圍內。基礎設施被定義爲能夠被抽象的，相對穩定的，對外提供服務的功能組件，對立，穩定，不易變化。英文單詞 infrastructure。

相反業務組件，圖 3 的 Components，被定義爲可變的，靈活的功能集合。從層次的角度考慮，業務組件高於基礎設施。

複製優於依賴

Alittle copyiing is better than a litter dependcy

有時候不必定要優先追求共享代碼，應該有一部分複製冗餘。公用表明着多處使用，和依賴耦合。複製雖然增長了複製的成本，卻獨立自由。

怎麼理解這句話？

咱們以 YII2 工程爲例，官方推薦的 Advanced 模版中有一個公共工程 common

那咱們是否是應該把項目中能夠共用的數據層都放到 common 裏？

如上圖，passport 和 admin 兩個模塊，若是都涉及同一張 User 表，依據複製優於依賴的原則，沒有必要公用一個 User 類，能夠單獨存放爲兩個 User 類，用命名空間作隔離。更況且由於模塊不同，即便同一個數據表對象，相關的數據操做也會不同。

總結

本文簡要討論了軟件分層相關的經驗和原則，軟件分層，分而治之是軟件工程的核心思想，從 OSI 參考模型，到 TCP/IP 應用模型，到雲計算常見的業務形態，都在踐行着這一思想。

你們有什麼相關的疑問和建議，歡迎留言分享。

end 2019 年 12 月