在我看來，Java專案分層簡直就是必須的，就算是一個人獨立發開的專案，也應該進行程式碼分層；我現在負責的專案，並沒有參考什麼程式碼分層規範，因為專案的框架都是我一個人搭建的，我也是憑著經驗做的設計，有些地方還摻雜了一些個人的喜好。

我們專案被分成幾個包，但是並不是微服務那種程度，因為公司的一些基礎還不是非常的完善，比如容器、容器管理工具、持續整合，雖然已經起步，但是並沒有成熟到讓生產環境使用的程度，畢竟是金融行業，求穩大於創新。

我們專案現在是按照功能模組分的包，比如介面服務、定時服務、前端頁面、監控等等；

前端頁面是純前端（我不太確定這樣形容是否明確），頁面所需的資料都是透過呼叫介面獲得，本身不和資料庫發生互動；

其餘工程都可以獨立部署，關聯功能，都是透過MQ進行解耦。

單個工程中，分層設計都一樣，也和主流的程式碼分層差不多（我們的專案絕大部分功能都是介面，少量的頁面功能，也被分到單獨的包中了）：

DAO層：Data Access Object，資料訪問物件，我們用的是MyBatis，在方法的註解中寫SQL語句；

Service層：業務邏輯層，這裡可能呼叫其他的Service或DAO；我看有些系統Service層會分成兩部分，一部分是功能比較單一的業務邏輯，另外一部分是組合的業務邏輯；個人認為這樣有些繁瑣；

Controller層：請求處理層，包括入參回參的型別轉換、入參驗證等功能在這裡完成；

Model層：資料的實體物件，和資料庫列名保持一致；類名也都是以Model為結尾命名；

Domain層：我們把入參和回參單獨做了一層，沒有和Model層混在一起；就算一個介面要查詢一個單表，查詢結果也要把Model轉成Domain；我們在Domain這一層做了很多欄位的標準化，保持見名知意；Domain層中的內容確定好了之後，屬性名稱不會改變，但是Model層中的內容允許修改。

剩下的就是Util、Contants、Config等等。

分包和分層，看起來讓程式碼結構變得更加的複雜，這種結構的複雜，實際上卻可以降低系統的複雜度：

單一職責：每一層的程式碼，只負責一類的職責，職責邊界變得非常的清晰；

高內聚、低耦合、易維護：業務邏輯被放到了一起，修改的時候不僅快，而且不會有遺漏；如果業務邏輯分散在多個程式碼層，那麼修改的時候，需要修改多處的程式碼，這樣難免會有疏漏；上層程式碼依賴下層程式碼，條理清晰，不會有迴圈依賴；

複用性高：某項功能被抽象出來，可以複用給多個業務流程。

如果專案本身具有明顯的“克隆”性質，比如，為crm 系統做個升級、為資訊系統新增gis 功能，等等。這樣的工作，或許有機會考慮一下“怎麼設計分層”。真正有挑戰性的軟體開發專案，系統的分層規劃，可能是經歷了數個早期版本之後的事情。

軟體產品、軟體開發工作，與其他工作的最大不同，是可以分層實施。然而，分層的重要意義，是為了便於工程參與者之間的交流。OSI 的7層結構，雖然在教材中很流行，但卻是“失敗”的設計。

一套頭頭是道的設計方案，說明專案開發工作僅僅是“體力活兒”了。