作者｜張輝清
編輯｜小智
社區裡不是缺少架構圖， 而是缺少確實可參考的架構落地實踐。 大公司的架構看上去總是不明覺厲，
系列文章附錄
以下文章點擊標題即可閱讀
寫在前面
應用分層這件事情看起來很簡單， 但每個程式師都有自己的一套， 哪怕是初學者。 如何讓一家公司的幾百個應用採用統一的分層結構， 並得到大部分程式師的認同， 這可不是件簡單的事情。 有兩個問題與大家一起探討：
服務的調用代碼你覺得放到哪一層好呢？A 表現層；B 業務邏輯層；C 數據層；D 公共層。
如何組織好 VO(View Object 視圖物件)、BO(Business Object 業務物件)、DO(Data Object 資料物件)、DTO(Data Transfer Object 資料傳輸物件) 呢？
不同的人會有不同的答案，
IPO 原理圖
統一邏輯架構
統一應用分層的邏輯架構圖
職責說明：
資料夾分層法：應用分層採用資料夾方式的優點是可大可小、簡單易用、統一規範， 可以包括 5 個項目， 也可以包括 50 個項目， 以滿足所有業務應用的多種不同場景；
調用規約：在開發過程中， 需要遵循分層架構的約束， 禁止跨層次的調用；
下層為上層服務：以使用者為中心， 以目標為導向。 上層（業務邏輯層）需要什麼， 下層（資料訪問層）提供什麼， 而不是下層（資料訪問層）有什麼， 就向上層（業務邏輯層）提供什麼；
實體層規約：DO 是資料表物件， 不是資料訪問層物件， 不是只能給資料訪問層使用；DTO 是網路傳輸物件，
U 型訪問：下行時表現層是 Input， 業務邏輯層是 Process， 資料訪問層是 Output。 上行時資料訪問層是 Input， 業務邏輯層是 Process, 表現層就 Output。
具體規範說明
接下來將借用由本文提供下載的 TripOrderService、TripSellerMVCSite 這兩個 Demo 來進行具體規範的說明， 以下是截圖：
專案名稱的命名規則
專案名稱的命名規則是：{產品線英文名全稱}.{子系統英文名全稱 + 應用名}.{項目職責英文名全稱}，如：Trip.Seller.Business。
業務邏輯層的專案規範
規範說明：
專案名的命名規則：{產品線英文名全稱}.{子系統英文名全稱 + 應用名}.Business，如上圖的 Trip.Order.Business。
類名以 Logic 結尾，如上圖的 OrderLogic.cs。
資料操作專案規範
規範說明：
各資料操作專案名根據使用什麼資料庫進行分類，然後以 DB 為結尾，具體命名規則是：{產品線英文名全稱}.{子系統英文名全稱 + 應用名}.{使用什麼資料庫}DB，如上圖的 Trip.Seller.MSSQLDB。
如果涉及到多個資料庫訪問的，那麼資料操作專案下的類檔需要按資料庫名稱（以 DB 為結尾）創建資料夾分開，如上圖的 TripOrderDB 資料夾。
建議在應用中使用 SQL 語句，不使用存儲過程。在資料庫中不新增存儲過程，但舊的存儲過程可以繼續使用和修改。
分頁建議使用資料庫（如 SQLServer）的最新特性進行分頁，並將每個分頁 SQL 直接寫到應用中。
實體類專案規範
資料物件 DO 規範
規範說明：
DO 專案名的命名規則：{產品線英文名全稱}.{子系統英文名全稱 + 應用名}.Entity，如上圖的 Trip.Seller.Entity；
如果涉及到多個資料庫訪問的，那麼需要按資料庫名稱（以 DB 為結尾）創建資料夾分開，如上圖的 TripOrderDB 資料夾；
表名 +Entity 結尾，如上圖的 OrderEntity.cs；
DO 是資料表物件，供單表 CURD 操作。對於多表查詢請求物件和返回物件，可定義新物件或使用現有物件（DTO/BO）來完成。
業務物件 BO 規範
BO 實體類名以 Model 為結尾：
資料傳輸物件 DTO 規範
規範說明：
DTO 專案名的命名規則：{產品線英文名全稱}.{子系統英文名全稱 + 應用名}.DTO，如上圖的 Trip.Order.DTO。
請求參數 DTO 實體類、回應 DTO 實體類存放規範以及其命名規則：
請求參數 DTO 實體類放在 Request 資料夾下，且命名規則為：以 Request 結尾，如上圖的 SearchOrderRequest.cs。
回應 DTO 實體類放在 Response 資料夾下，且命名規則為：以 Response 結尾，如上圖的 SearchOrderResponse.cs。
如果請求參數 DTO 實體類或回應 DTO 實體類的屬性中有物件或枚舉，那麼這些物件所屬的類、枚舉放在 DTO 專案的 Common 資料夾下。
如果請求參數 DTO 實體類、回應 DTO 實體類有基類要繼承，那麼建議為基類取名為 RequestBase.cs、ResponseBase.cs。且這些基類直接放在 DTO 項目的 Common 資料夾下。
視圖物件 VO 規範
規範說明：
VO 專案名的命名規則：{產品線英文名全稱}.{子系統英文名全稱 + 應用名}.ViewModel，如上圖的 Trip.Seller.ViewModel。
各 VO 實體類，我們用 Controller 名作為資料夾名進行分開，如上圖的 Order 資料夾。
VO 實體類名的命名建議：
請求參數 VO 實體類以 Input/Form/Query 結尾，如上圖的 SearchOrderInput.cs。
回應 VO 實體類以 Output/List/Result 結尾，如上圖的 SearchOrderOutput.cs。
資料庫連接配置規範
規範說明：
資料庫連接的配置必須讀寫分離。
資料庫連接字串建議加密處理。
資料庫連接配置名的命名規則：{以 DB 為結尾的資料庫名稱}_ 讀寫類型，如：TripOrderDB_SELECT、TripOrderDB_INSERT。
設定檔方面的規範
規範說明：
所有設定檔（除 Web.config 檔外）都必須放到 Config 資料夾下。
所有設定檔（除 Web.config 檔外）按不同環境區分開，具體命名規則是：{功能模組英文名}.{環境英文簡稱名}.config，其中本地環境的英文簡稱名是 Dev，測試環境的英文簡稱名是 Test，正式環境的英文簡稱名是 Prod，如上圖的 AppSetting.Dev.config。
保持 Web.config 設定檔的乾淨，只留環境設置節點。
靜態資源檔方面的規範
規範說明：
公共的靜態資源檔（css、js、image 等）放在另外的靜態網站中，統一由前端進行開發和維護。一般，css 檔放在 css 資料夾下，js 文件放在 js 資料夾下，image 圖片檔放在 img 資料夾下。
與某項業務有關的 js 檔可以放到各自業務專案的表現層 PresentationLayer 下，以方便開發人員調試，js 檔可放在專案的 js 資料夾下。
靜態資源檔必須使用版本號管理，以防更新後由於用戶端流覽器緩存而導致網站使用的依然是舊版本的靜態資源檔：
寫在最後
問題回答
問：服務的調用代碼應該放到哪一層呢？
A 表現層、B 業務邏輯層 、C 資料層、D 公共層。
答：我們的規範是統一放到資料資源訪問層即 C。上層提供服務，下層調用服務，中間處理業務邏輯。
問：如何組織好 VO(View Object 視圖物件)、BO(Business Object 業務物件)、DO(Data Object 資料物件)、DTO(Data Transfer Object 資料傳輸物件) 呢？
答：通常有兩種做法，限定訪問範圍和不限定訪問範圍，可根據需要選擇或折中。我們使用後者，將 EntityLayer 作為通用物件放到左側，具體可參考實體層規約：“DO 是資料表物件，不是資料訪問層物件，不是只能給資料訪問層使用；DTO 是網路傳輸物件，不是表現層物件，不是只能給表現層使用；BO 是記憶體計算邏輯物件，不是業務邏輯層物件，不是只能給業務邏輯層使用 。如果僅限定在本層訪問，則導致單個應用內大量沒有價值的物件轉換。以使用者為中心來設計實體類，可以減少無價值重複物件和無用轉換。”
問：應用分層範例代碼在編寫時需要注意些什麼？
答：應用分層範例代碼要想寫好，非常不容易，需要注意三點：
應用分層範例的主要價值是明確層的職責和交互，每個層要幹什麼，哪些要幹，哪些不要幹，以及層與層之間交互；
減少通用幫助類的編寫，如果每一個應用中都有這些類，這在架構層面上是有問題。在我們幾百個線上應用中，也是如此：沒有分頁説明類、資料庫説明類、緩存幫助類、MQ 説明類，沒有日誌説明類，沒有 AOP 幫助類。業務應用的重點是為業務服務，每一個應用都是特別的，大都需要定制，極少有通用的代碼，如果有，那應該是框架或元件；
少即可多。應用的場景特別多，參考人員多，時間長，所以只能做大家都認同的規範、正確的事情，要減少有爭議的代碼範例，否則一個錯誤將會放大百倍，一個爭議的規範將會很落地。
Demo 下載
https://github.com/das2017/LayerDemo
大新聞，倒計時 2 天！
作者介紹張輝清，10 多年的 IT 老兵，曾攜程架構師、古大集團首席架構師、中青易遊 CTO，主導過兩家公司的技術架構升級改造工作。現關注是架構與工程效率，技術與業務的匹配與融合，技術價值與創新。
今日薦文點擊下方圖片即可閱讀
為什麼 Python 發展得如此之快？
專案名稱的命名規則
專案名稱的命名規則是：{產品線英文名全稱}.{子系統英文名全稱 + 應用名}.{項目職責英文名全稱}，如：Trip.Seller.Business。
業務邏輯層的專案規範
規範說明：
專案名的命名規則：{產品線英文名全稱}.{子系統英文名全稱 + 應用名}.Business，如上圖的 Trip.Order.Business。
類名以 Logic 結尾，如上圖的 OrderLogic.cs。
資料操作專案規範
規範說明：
各資料操作專案名根據使用什麼資料庫進行分類，然後以 DB 為結尾，具體命名規則是：{產品線英文名全稱}.{子系統英文名全稱 + 應用名}.{使用什麼資料庫}DB，如上圖的 Trip.Seller.MSSQLDB。
如果涉及到多個資料庫訪問的，那麼資料操作專案下的類檔需要按資料庫名稱（以 DB 為結尾）創建資料夾分開，如上圖的 TripOrderDB 資料夾。
建議在應用中使用 SQL 語句，不使用存儲過程。在資料庫中不新增存儲過程，但舊的存儲過程可以繼續使用和修改。
分頁建議使用資料庫（如 SQLServer）的最新特性進行分頁，並將每個分頁 SQL 直接寫到應用中。
實體類專案規範
資料物件 DO 規範
規範說明：
DO 專案名的命名規則：{產品線英文名全稱}.{子系統英文名全稱 + 應用名}.Entity，如上圖的 Trip.Seller.Entity；
如果涉及到多個資料庫訪問的，那麼需要按資料庫名稱（以 DB 為結尾）創建資料夾分開，如上圖的 TripOrderDB 資料夾；
表名 +Entity 結尾，如上圖的 OrderEntity.cs；
DO 是資料表物件，供單表 CURD 操作。對於多表查詢請求物件和返回物件，可定義新物件或使用現有物件（DTO/BO）來完成。
業務物件 BO 規範
BO 實體類名以 Model 為結尾：
資料傳輸物件 DTO 規範
規範說明：
DTO 專案名的命名規則：{產品線英文名全稱}.{子系統英文名全稱 + 應用名}.DTO，如上圖的 Trip.Order.DTO。
請求參數 DTO 實體類、回應 DTO 實體類存放規範以及其命名規則：
請求參數 DTO 實體類放在 Request 資料夾下，且命名規則為：以 Request 結尾，如上圖的 SearchOrderRequest.cs。
回應 DTO 實體類放在 Response 資料夾下，且命名規則為：以 Response 結尾，如上圖的 SearchOrderResponse.cs。
如果請求參數 DTO 實體類或回應 DTO 實體類的屬性中有物件或枚舉，那麼這些物件所屬的類、枚舉放在 DTO 專案的 Common 資料夾下。
如果請求參數 DTO 實體類、回應 DTO 實體類有基類要繼承，那麼建議為基類取名為 RequestBase.cs、ResponseBase.cs。且這些基類直接放在 DTO 項目的 Common 資料夾下。
視圖物件 VO 規範
規範說明：
VO 專案名的命名規則：{產品線英文名全稱}.{子系統英文名全稱 + 應用名}.ViewModel，如上圖的 Trip.Seller.ViewModel。
各 VO 實體類，我們用 Controller 名作為資料夾名進行分開，如上圖的 Order 資料夾。
VO 實體類名的命名建議：
請求參數 VO 實體類以 Input/Form/Query 結尾，如上圖的 SearchOrderInput.cs。
回應 VO 實體類以 Output/List/Result 結尾，如上圖的 SearchOrderOutput.cs。
資料庫連接配置規範
規範說明：
資料庫連接的配置必須讀寫分離。
資料庫連接字串建議加密處理。
資料庫連接配置名的命名規則：{以 DB 為結尾的資料庫名稱}_ 讀寫類型，如：TripOrderDB_SELECT、TripOrderDB_INSERT。
設定檔方面的規範
規範說明：
所有設定檔（除 Web.config 檔外）都必須放到 Config 資料夾下。
所有設定檔（除 Web.config 檔外）按不同環境區分開，具體命名規則是：{功能模組英文名}.{環境英文簡稱名}.config，其中本地環境的英文簡稱名是 Dev，測試環境的英文簡稱名是 Test，正式環境的英文簡稱名是 Prod，如上圖的 AppSetting.Dev.config。
保持 Web.config 設定檔的乾淨，只留環境設置節點。
靜態資源檔方面的規範
規範說明：
公共的靜態資源檔（css、js、image 等）放在另外的靜態網站中，統一由前端進行開發和維護。一般，css 檔放在 css 資料夾下，js 文件放在 js 資料夾下，image 圖片檔放在 img 資料夾下。
與某項業務有關的 js 檔可以放到各自業務專案的表現層 PresentationLayer 下，以方便開發人員調試，js 檔可放在專案的 js 資料夾下。
靜態資源檔必須使用版本號管理，以防更新後由於用戶端流覽器緩存而導致網站使用的依然是舊版本的靜態資源檔：
寫在最後
問題回答
問：服務的調用代碼應該放到哪一層呢？
A 表現層、B 業務邏輯層 、C 資料層、D 公共層。
答：我們的規範是統一放到資料資源訪問層即 C。上層提供服務，下層調用服務，中間處理業務邏輯。
問：如何組織好 VO(View Object 視圖物件)、BO(Business Object 業務物件)、DO(Data Object 資料物件)、DTO(Data Transfer Object 資料傳輸物件) 呢？
答：通常有兩種做法，限定訪問範圍和不限定訪問範圍，可根據需要選擇或折中。我們使用後者，將 EntityLayer 作為通用物件放到左側，具體可參考實體層規約：“DO 是資料表物件，不是資料訪問層物件，不是只能給資料訪問層使用；DTO 是網路傳輸物件，不是表現層物件，不是只能給表現層使用；BO 是記憶體計算邏輯物件，不是業務邏輯層物件，不是只能給業務邏輯層使用 。如果僅限定在本層訪問，則導致單個應用內大量沒有價值的物件轉換。以使用者為中心來設計實體類，可以減少無價值重複物件和無用轉換。”
問：應用分層範例代碼在編寫時需要注意些什麼？
答：應用分層範例代碼要想寫好，非常不容易，需要注意三點：
應用分層範例的主要價值是明確層的職責和交互，每個層要幹什麼，哪些要幹，哪些不要幹，以及層與層之間交互；
減少通用幫助類的編寫，如果每一個應用中都有這些類，這在架構層面上是有問題。在我們幾百個線上應用中，也是如此：沒有分頁説明類、資料庫説明類、緩存幫助類、MQ 説明類，沒有日誌説明類，沒有 AOP 幫助類。業務應用的重點是為業務服務，每一個應用都是特別的，大都需要定制，極少有通用的代碼，如果有，那應該是框架或元件；
少即可多。應用的場景特別多，參考人員多，時間長，所以只能做大家都認同的規範、正確的事情，要減少有爭議的代碼範例，否則一個錯誤將會放大百倍，一個爭議的規範將會很落地。
Demo 下載
https://github.com/das2017/LayerDemo
大新聞，倒計時 2 天！
作者介紹張輝清，10 多年的 IT 老兵，曾攜程架構師、古大集團首席架構師、中青易遊 CTO，主導過兩家公司的技術架構升級改造工作。現關注是架構與工程效率，技術與業務的匹配與融合，技術價值與創新。
今日薦文點擊下方圖片即可閱讀
為什麼 Python 發展得如此之快？