Model層

該層在MVC模式中，主要負責與資料的直接對話。該層在Java Web專案中，通常會出於實際情況，又將其細分為了兩層：Service層，DAO（在Spring+Mybatis中，也可以說是Mapper）層。

Service層，主要用於編寫業務邏輯。通常它在一個Java Web專案中的程式碼量是最多的。

DAO層，主要用於與資料庫進行互動，根據業務操作相關資料。

該層在MVC模式中，主要負責控制業務邏輯，以及返回相關檢視。在Java Web的專案中，這層有時候會直接也DAO層對話，這是錯誤的，這完全不符合該層的設計理念。這層只能與Service層對話，控制業務方向，而不是獲取資料。

該層在MVC模式中，主要負責向客戶端呈現資料。在傳統的Java Web專案中，這一層，我們通常用jsp,template等這類模板引擎來處理。現在的話，由於前後端分離，所以這層基本上剝離出Java Web專案，而改為由前端處理這塊資料的呈現了，後端則更多的用於返回json。

分包

在說單個專案的程式碼分層之前，先說一下程式碼的分包。

我們公司現在面臨著比較尷尬的問題，一方面新的專案部再是隻有一個程式碼包，希望走微服務的方式，把一個專案拆成多個工程，分別迭代開發和部署；另一方面，很多基礎的基礎還不是很完善，比如容器、容器管理工具、持續整合，要麼是沒有，要麼是難以用在生產環境中。

所以我們專案只拆分出來五六個工程，包括定式服務、介面服務、前端頁面等；除了前端頁面這個工程要依賴介面服務之外，其餘幾個工程彼此可以單獨部署，很多功能是透過MQ解耦。

單個工程中，分包都是一樣的，也和主流的程式碼分層差不多：

Model層：就是普通的Jave Bean，資料的實體物件，和資料庫列名保持一致；

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

Service層：業務邏輯層，這裡可能呼叫其他的Service或DAO；

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

Domain層：我們把回參單獨做了一層，沒有和Model層混在一起；就算一個介面要查詢一個單表，查詢結果也要把Model轉成Domain；我們在Domain這一層做了很多欄位的標準化，保持見名知意；

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

做到現在的階段，也遇到了一些問題，也在想辦法解決：

一些可以通用的類，在幾個包中都存在，有的時候修改起來要修改好幾個工程，挺麻煩的，準備把這些通用的東西提出來放在單獨的一個工程中；

介面現在放在一個工程中，我認為是有些不合理的；介面應該可以分成原子服務和組合服務，這裡至少要分成兩層，原子服務穩定，改動的頻率很低；組合服務應該是快速迭代的，會根據需求不斷地修改和增加。但是苦於沒有很多基礎設施，純人工的話又很難支援。