目前公司系統多個應用分層結構各不相同，給運維和將來的開發帶來了巨大的成本，分層架構看似很簡單，但保證整個研發中心都使用統一的分層架構就不容易了。css
那麼如何保證整個研發中心都使用統一的分層架構，以達到提升編寫代碼效率、保證工程統一性的目的？html
這裏給出我的的規劃設計，但願對你有所啓發。前端
1.分層目標
- 簡單易用：少便是多，哪怕應屆生進來也能很快上手
- 結構統一：不論是新系統仍是舊系統結構的是同樣的。
- 提升效率：提升開發和運維效率，減小維護和學習成本
2.分層架構介紹
先簡單介紹當前兩種比較流行的分層架構體系：領域分層架構和傳統三層架構git
2.1領域分層架構
領域架構：包括倉儲層、領域層、應用服務層、表現層和基礎公共層，以下圖所示：數據庫
2.2傳統三層架構
另外一種是相對傳統地分爲三層：包括數據層、業務邏輯層和表現層，以下圖所示：編程
2.3兩者區別？
在早期作三層架構的時候，大都以表來驅動，在作領域架構的時候，大都以業務邏輯來驅動，二者的區別確實比較明顯，但到了如今，若是都以業務邏輯爲中心，那麼二者並無本質區別。json
攜程公司採用了第二種分層法，他們但願把分層作得極簡，也就是說，哪怕剛畢業進入公司的員工，在分層時基本上也不會亂。後端
相對於第一種分層法，第二種分層法簡單得多。每個應用的代碼量都不該該很大，一旦工程變得過大，就會把它適當拆分，而不是所有放在一單體應用裏。瀏覽器
總之，分層越簡單，整個軟件結構就越清晰，代碼就越容易統一。緩存
把工程作得極簡，纔有利於複製，有利於業務的快速構建，有利於規模化，使系統穩定可靠。
3.統一分層規範
以上兩種邏輯分層如何作選型？咱們要回到分層的目的上來評估，咱們的目標是簡單、統1、高效。因此傳統的三層架構很好的知足了咱們的需求。而領域驅動開發，對DDD有必定的學習成本，同時對舊系統的歷史包袱，好比數據庫，咱們沒法作到面向領域編程，咱們更多的要面向數據庫編程。因此，當前敏捷框架比較適合想從老系統遷移的，可是有數據庫歷史包袱的團隊。
3.1減小私人定製:
減小私人通用幫助類CommonLayer的編寫，若是每個應用中有大量相同的幫助類，則在架構層面上是有問題的。線上應用越多，則代碼重複越多。好比，每一個應用都有分頁幫助類、數據庫幫助類、緩存幫助類、MQ幫助類、日誌幫助類、AOP幫助類等。
每個應用都是特別的，都須要私人定製極少有通用的代碼，若是有，那麼應該由框架或組件專門解決。這裏框架統一放在Com.Util裏。
3.2內聚大於解耦:
內聚是指部門內有共同的目標，而後你們緊密合做。解耦是指部門間各自職責明確，而後減小沒必要要的鏈接。一個應用如同一個部門，應該有一個共同的目標和職責，而後你們緊密合做。
換句話說，應用內部應減小沒必要要的契約接口，減小沒必要要的依賴注入實現，減小沒必要要且代價過大的解耦。一切以簡單實用爲主，應用的價值輸出爲導向。
總之，不管採起何種分層架構，分層架構最核心的一點就是要保證各層之間職責足夠清晰，邊界足夠明顯，讓人看到架構圖後就能看懂整個架構。
4.分層規範實踐
4.0命名規範遵循：
4.1表現層規範
（1）項目命名規則：
- 若是是API服務，則命名規則爲：{公司}.{業務名}.API
好比：Com.Channel.API
- 若是是MVC站點，則命名規則爲：{公司}.{業務名}.MVCSite
好比：Com.Channel.MVCSite
4.2邏輯層規範
（1）項目命名規則：{公司}.{業務名}.Business
好比：Com.Channel.Business
（2）類名以Logic結尾
4.3數據層規範
（1）項目命名規則：{公司}.{業務名}.{數據庫}DB
好比：Com.Channel.MSSQLDB
（2）約定在應用中使用SQL語句，不使用存儲過程。舊的存儲過程能夠繼續使用和修改。
（3）使用數據庫的最新特性進行分頁
4.4實體層規範
（1）項目命名規則：{公司}.{業務名}.DTO
好比：Com.Channel.DTO
（2）請求參數DTO實體類放在Request文件夾下,且命名規則爲以Request結尾，以下圖的 SearchColorRequest.cs
（3）響應DTO實體類放在Response文件夾下，且命名規則爲以Response結尾，以下圖的 SearchColorResponse.cs
（4）若是請求或響應的DTO實體類的屬性中有對象或枚舉，那麼這些對象所屬的類、枚舉放在DTO項目的Common文件夾下。
（5）若是請求或響應的DTO實體類有基類要繼承，那麼約定爲基類取名爲RequestBase.cs、 ResponseBase.cs，且這些基類直接放在DTO項目的Common文件夾下。
（1）項目命名規則：{公司}.{業務名}.ViewModel
好比：Com.Channel.ViewModel
（2）VO實體類約定用Controller做爲文件夾名稱
（3）VO實體類名的命名約定:
- 請求VO以Input/Form/Query結尾,以下圖的Colorlnput.cs
- 響應VO以Output/List/Result結尾,以下圖的ColorOutput.cs
4.5公共層規範
（1）項目命名規則：{公司}.{業務名}.Util
好比：Com.Channel.Util
4.6測試層規範
（1）項目命名規則：{公司}.{業務名}.UnitTest
好比：Com.Channel.UnitTest
（2）單元測試類格式約定
（3）測試方法命名約定
測試方法名分紅三段：主題+指望結果+參數
4.6參數校驗層規範
咱們知道參數校驗對整個系統的安全性和性能來講是很重要的一個環節。
- 那麼咱們的參數校驗應該怎麼作才能讓本身滿意呢？
- 也就是說怎樣才能讓處處都存在的參數校驗變得優雅呢？
由於參數校驗屬於非業務性代碼，因此個人想法是使用AOP把他切割出來，不能讓校驗代碼和業務邏輯耦合，並且散落在各處，爲此我把校驗類獨立出來，以下圖所示：
在Controller層的作法也很簡單，就是綁定一下便可，以下圖所示：
5.其餘規範
5.1DB配置規範
（1）配置文件分開發環境和生產環境
（2）數據庫鏈接的配置讀寫分離，連接字符串加密處理
（3）數據庫鏈接配置名的命名規則:{業務}_DB_CONN_讀寫類型(如上圖所示)
5.2配置文件規範
（1）統一使用json文件的配置方式
（2）json文件的讀取
- 映射對象
- 統一走AppSetting封裝類，經過冒號（：）進行讀取
- 數據庫作讀寫分離
5.3靜態資源文件規範
（1）公共的靜態資源文件(CSS、JS、Image等)放在另外的靜態站點中，統一由前端進行開發和維護。通常CSS文件放在css文件夾下，JS文件放在js文件夾下， Image圖片文件放在img文件夾下，以下圖的左半部分所示。（截圖說明，以下圖所示：）
（2）靜態資源文件必須使用版本號管理，以避免更新後因爲客戶端瀏覽器緩存而致使站點使用的依然是舊版本的靜態資源文件:
<script src="~/js/order.js?v=(Appsetting.StaticFileVersion"></script>
（3）採用先後端徹底分離的方式，讓Java或NET開發資源撤出表現層，以專一於業務邏輯需求的迭代。
源碼下載：
下載
本篇博客通過很多天熬夜，反覆刪減代碼，一步步搭建完成後整理的我的心得，分享給你們~~~，
- 所需的源代碼，上傳在個人騰訊工蜂Git中，打賞博主一杯咖啡錢，而後私密博主~
- 若是您不想付出，那麼請您加入Q羣(996767213)，並上傳您的資源，好比電子書或者其餘資料，對羣友有幫助的便可。
下載須要簡單註冊工蜂，並把工蜂的用戶名給我(以下圖所示)
運行
您下載後，所要作的工做就是運行，而後就看到Swagger了(以下圖所示)
框架後續
該框架所有利用本身業餘時間進行設計和優化，後續會陸續推出其餘的系列：
版本系列
- 單體敏捷框架
- AF3(Agile Framework3)，基於三層邏輯概念劃分；
- AFD(Agile Framework DDD)，基於DDD驅動設計原理劃分；
- 微服務敏捷框架
- AMFS(Agile Microservice Framework Single Repository)，基於單體代碼倉庫劃分；
- AMFM(Agile Microservice Framework Muti-Repository)，基於代碼多倉庫劃分；
