最近跟一個師兄吃飯，聊到他在微軟的工作，感嘆超過1萬人維護了30年的office軟件，不得不說，一個軟件，能夠在如此多平臺，如此多歷史版本中還能不斷地迭代，還能把兼容性做得如此之好真是不容易。聊到一些中美程序員的差異，中國的互聯網公司大多追求短平快，大部分地程序員并非軟件工程專業出生，軟件工程在大學也是一門比較無足輕重地必修課。但在國外，很多公司會給你充足的時間，讓你慢慢把軟件做好，做好的最重要一點，便是可維護。無論你的設計有多么巧妙，算法有多么高深，這些都不是好代碼的標準，好的代碼是可以給一個團隊不停地維護，迭代中，不輕易出現混亂與差錯。

編程這個行業在我國盛行，也不到20年的歷史，真正流行并快速發展的，也只有最近十年。以往在大多數公司里面，開發的規范比較少，大家各成一派，有著自己的風格，不過這幾年，國內的一些開發規范慢慢盛行起來。今天我們來簡單聊一聊阿里巴巴推出的JAVA開發規范中的服務分層。

業務分層在我們的開發中非常的常見，好處也是非常多，首先是業務分層讓分工更加明確，邏輯更加清晰，更好地進行維護。其次業務分層可以讓代碼更加容易復用，舉個簡單例子，我們通常會把跟數據庫交互的代碼收攏到一個DAO層，如果你不這么做，會有什么問題呢？假如某一天我們對表結構進行表更，新增或者替換了字段，我們可能要修改非常多處的代碼，令人頭疼。最后是讓業務更加容易擴展，那一層有性能問題，我們可以針對那一層該加機器就加機器，該優化就進行優化。

在業務邏輯層，會處理通用的業務，例如電商系統中的交易成單接口，會調用商品，優惠，會員等多個子系統，完成成單服務。在業務邏輯層中，一些通用的業務會被抽象出來，放到Manage層，我們還是舉電商交易成單的例子，我們有一個訂單查詢接口，但是這個查詢接口不太想去理解太多業務邏輯，例如交易的類型，業務方，訂單的狀態等等，可以由Service層去理解這些邏輯，然后調用Manage層對應的查詢接口。Service層接口與Manage層都可以訪問后方的DAO層，DAO層主要負責與數據庫交互，不理解業務邏輯。

所以，我們在開發項目的過程中，雖然不用完全按照這個規范，但也至少也把項目分成若干個層次，這樣，才能讓代碼更容易閱讀與維護。