目前公司系統多個應用分層結構各不相同，給運維和未來的開發帶來了巨大的成本，分層架構看似很簡單，但保證整個研發中心都使用統一的分層架構就不容易了，
那么如何保證整個研發中心都使用統一的分層架構，以達到提高撰寫代碼效率、保證工程統一性的目的？
這里給出個人的規劃設計，希望對你有所啟發，
1.分層目標
- 簡單易用：少即是多，哪怕應屆生進來也能很快上手
- 結構統一：不管是新系統還是舊系統結構的是一樣的，
- 提高效率：提高開發和運維效率，減少維護和學習成本
2.分層架構介紹
先簡單介紹當前兩種比較流行的分層架構體系：領域分層架構和傳統三層架構
2.1領域分層架構
領域架構：包括倉儲層、領域層、應用服務層、表現層和基礎公共層，如下圖所示：
2.2傳統三層架構
另一種是相對傳統地分為三層：包括資料層、業務邏輯層和表現層，如下圖所示：
2.3二者區別？
在早期做三層架構的時候，大都以表來驅動，在做領域架構的時候，大都以業務邏輯來驅動，兩者的區別確實比較明顯，但到了現在，如果都以業務邏輯為中心，那么兩者并沒有本質區別，
攜程公司采用了第二種分層法，他們希望把分層做得極簡，也就是說，哪怕剛畢業進入公司的員工，在分層時基本上也不會亂，
相對于第一種分層法，第二種分層法簡單得多，每一個應用的代碼量都不應該很大，一旦工程變得過大，就會把它適當拆分，而不是全部放在一單體應用里，
總之，分層越簡單，整個軟體結構就越清晰，代碼就越容易統一，
把工程做得極簡，才有利于復制，有利于業務的快速構建，有利于規模化，使系統穩定可靠，
3.統一分層規范
以上兩種邏輯分層如何做選型？我們要回到分層的目的上來評估，我們的目標是簡單、統一、高效，所以傳統的三層架構很好的滿足了我們的需求，而領域驅動開發，對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物體層規范
- DTO規范
（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檔案夾下，
- VO規范
（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）單元測驗類格式約定
- 1.一個測驗方法只測驗一個問題
- 2.使用Moq框架4.11.0
- 3.使用FluentAPI https://fluentassertions.com/
- 最后修改人：張飛洪
- 最后修改時間：2019-6-20
（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="https://www.cnblogs.com/IT-Evan/p/~/js/order.js?v=(Appsetting.StaticFileVersion"></script>
（3）采用前后端完全分離的方式，讓Java或NET開發資源撤出表現層，以專注于業務邏輯需求的迭代，
原始碼下載：
下載
本篇博客經過數日熬夜，反復刪減代碼，一步步搭建完成后整理的個人心得，分享給大家~~~，
- 所需的源代碼，上傳在我的騰訊工蜂Git中，在下面打賞博主一杯咖啡錢，然后私密博主~
下載需要簡單注冊工蜂，并把工蜂的用戶名給我(如下圖所示)
運行
您下載后，所要做的作業就是運行，然后就看到Swagger了(如下圖所示)
框架后續
該框架全部利用自己業余時間進行設計和優化，后續會陸續推出其他的系列：
版本系列
- 單體敏捷框架
- AF3(Agile Framework3)，基于三層邏輯概念劃分；
- AFD(Agile Framework DDD)，基于DDD驅動設計原理劃分；
- 微服務敏捷框架
- AMFS(Agile Microservice Framework Single Repository)，基于單體代碼倉庫劃分；
- AMFM(Agile Microservice Framework Muti-Repository)，基于代碼多倉庫劃分；
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/88188.html
標籤：其他
上一篇：Github無法訪問的解決辦法
下一篇：查看包名和Activity