作者：CodeSheep
鏈接：https://www.jianshu.com/p/fd99bebeadea
來源：簡書
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。
這篇文章寫的很好，可以爲以後項目設計目錄結構時做參考，故轉載過來，方便查找。
我爲什麼要寫這篇
近來，和不少初學Spring或Spring Boot的小夥伴私信交流了關於項目目錄結構劃分和代碼分層的問題。
很多小夥伴表示網上下載下來的開源項目看不懂，項目結構和代碼分層看得很蒙，不知道應該以一個什麼樣的思路去學習和吸收別人的項目。
好，今天熬夜肝了這篇文章，和大家一起來交流探討一下，不足之處也請小夥伴們批評指正。
先看看阿里是怎麼約定的
我印象中，以前在看《阿里巴巴Java開發手冊》時，好像有關於工程結構和應用分層相關的內容，於是我回翻了一下，果然有：
它這裏面講的內容大概就是：關於一個正常的企業項目裏一種通用的項目結構和代碼層級劃分的指導意見。
按這本書上說的，一般分爲如下幾層：
- 開放接口層
- 終端顯示層
- Web 層
- Service 層
- Manager 層
- DAO 層
- 外部接口或第三方平臺
由於書中的篇幅關係，它這地方講得比較籠統了，估計初學者看了還是會懵，所以接下來結合實際項目代碼結構，來嘮一嘮具體的項目結構和代碼分層。
通常的項目結構
首先說在前面的是：這東西並沒有一套通用的標準，不同公司或者團隊的使用習慣和規範也不盡相同。
我們就以當下非常火熱的Spring Boot典型項目結構爲例，創建出來的項目應該總體分爲三大層：
項目根目錄/src/main/java：放置項目Java源代碼項目根目錄/src/main/resources：放置項目靜態資源和配置文件項目根目錄/src/test/java：放置項目測試用例代碼
而位於/src/main/java目錄下的Java源代碼的組織結構大家比較關心，這地方也只能給出一個通常典型的結構，畢竟不同項目和團隊實踐不一樣，稍許有區別，但整體安排應該差不多。而且如果是多模塊的項目的話，下面的結構應該只對應其中一個模塊，其他模塊的代碼組織也大致差不多。
各個目錄詳細介紹：
|_annotation：放置項目自定義註解
|_aspect：放置切面代碼
|_config：放置配置類
|_constant：放置常量、枚舉等定義
|__consist：存放常量定義
|__enums：存放枚舉定義
|_controller：放置控制器代碼
|_filter：放置一些過濾、攔截相關的代碼
|_mapper：放置數據訪問層代碼接口
|_model：放置數據模型代碼
|__entity：放置數據庫實體對象定義
|__dto：存放數據傳輸對象定義
|__vo：存放顯示層對象定義
|_service：放置具體的業務邏輯代碼（接口和實現分離）
|__intf：存放業務邏輯接口定義
|__impl：存放業務邏輯實際實現
|_utils：放置工具類和輔助代碼
然後接下來/src/main/resources目錄，裏面主要存放靜態配置文件和頁面靜態資源等東西：
|_mapper：存放mybatis的XML映射文件（如果是mybatis項目）
|_static：存放網頁靜態資源，比如下面的js/css/img
|__js：
|__css：
|__img：
|__font：
|__等等
|_template：存放網頁模板，比如thymeleaf/freemarker模板等
|__header
|__sidebar
|__bottom
|__XXX.html等等
|_application.yml 基本配置文件
|_application-dev.yml 開發環境配置文件
|_application-test.yml 測試環境配置文件
|_application-prod.yml 生產環境配置文件
當然，這地方估計有一個很多人都會糾結的關於DTO/VO/DO等數據模型定義的區分。
這在《阿里巴巴Java開發手冊》中倒是做了一個所謂的嚴格區分，那本書上是這樣去定義的：
DO（Data Object）：與數據庫表結構一一對應，通過DAO層向上傳輸數據源對象。DTO（Data Transfer Object）：數據傳輸對象，Service或Manager向外傳輸的對象。BO（Business Object）：業務對象。由Service層輸出的封裝業務邏輯的對象。AO（Application Object）：應用對象。在Web層與Service層之間抽象的複用對象模型，極爲貼近展示層，複用度不高。VO（View Object）：顯示層對象，通常是Web向模板渲染引擎層傳輸的對象。Query：數據查詢對象，各層接收上層的查詢請求。注意超過2個參數的查詢封裝，禁止使用Map類來傳輸。
老實講，看到這麼多對象的定義，我也是很蒙的。實際項目開發時，我覺得沒有必要刻意照搬去定義這麼多層對象，這樣後續做對象轉換工作都能煩skr人。
出於簡單起見，我個人覺得，只要保證業務邏輯層Service和數據庫DAO層的操作對象嚴格劃分出來，確保互相不滲透，不混用，問題應該就不大。
比如在我上面舉例的這個項目的代碼結構中，Service層處理的對象都定義在了dto包裏，而DAO層處理的對象都放在了entity包裏了。
項目結構劃分總結
如果從一個用戶訪問一個網站的情況來看，對應着上面的項目代碼結構來分析，可以貫穿整個代碼分層：
對應代碼目錄的流轉邏輯就是：
我想，應該看得比較清楚了吧。
所以，以後每當我們拿到一個新的項目到手時，只要按照這個思路去看別人項目的代碼，應該基本都是能理得順的。
一些注意事項
1、Contorller層參數傳遞建議不要使用HashMap，建議使用數據模型定義
2、Controller層裏可以做參數校驗、異常拋出等操作，但建議不要放太多業務邏輯，業務邏輯儘量放到Service層代碼中去做
3、Service層做實際業務邏輯，可以按照功能模塊做好定義和區分，相互可以調用
4、功能模塊Service之間引用時，建議不要滲透到DAO層（或者mapper層），基於Service層進行調用和複用比較合理
5、業務邏輯層Service和數據庫DAO層的操作對象不要混用。Controller層的數據對象不要直接滲透到DAO層（或者mapper層）；同理數據表實體對象Entity也不要直接傳到Controller層進行輸出或展示。