你們一般都是怎么設計代碼分層的？

我現在負責的項目，并沒有遵守什么外部嚴格的代碼分層規范，因為項目的架子都是我一個人搭建的，所以很多地方都是以個人的經驗做的設計，甚至有些地方摻雜了一些個人的喜好。下面我大概介紹一下，有不贊同的地方，可以留言討論。

分包

在說單個項目的代碼分層之前，先說一下代碼的分包。

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

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

分層

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

Model層：就是普通的Jave Bean，數據的實體對象，和數據庫列名保持一致；

DAO層：Data Access Object，數據訪問對象，我們用的是MyBatis，在方法的注解中寫SQL語句；

Service層：業務邏輯層，這里可能調用其他的Service或DAO；

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

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

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

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

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

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

我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。