[[441809]]

上次關(guān)于如何編寫代碼的文章里面提到了應(yīng)用的模塊化和分層，這篇文章就來聊聊這個事情。

沒有頂層設(shè)計、模塊劃分的應(yīng)用就像一團打結(jié)的毛線，代碼分支可能會跳來跳來，沒有邊界。很難理清楚內(nèi)部的業(yè)務(wù)邏輯，更糟糕的是隨著需求的堆積，日積月累更難理清楚內(nèi)部的模塊劃分，所以從一開始就應(yīng)該定好系統(tǒng)的模塊，確定好邊界之后才知道每一部分往哪里放。

每次實現(xiàn)一個新需求內(nèi)心都有一個層次樹，大概會在哪個模塊加什么東西，傳統(tǒng)的MVC 模型在web 應(yīng)用流行了很久，也很容易理解，下面我基于之前實現(xiàn)的一個系統(tǒng)做了些修剪和設(shè)計，形成了一個比較通用的分層架構(gòu)。

如下圖：后面分別講解每一個模塊的職責(zé)。

應(yīng)用分層和模塊化

controller

控制器層大家應(yīng)該都不陌生，寫過web應(yīng)用的都知道，這個是http 請求的入口，controller 負責(zé)接受web請求HttpRequest, 返回HttpResponse。

biz-service-api

業(yè)務(wù)服務(wù)層的接口定義，一般簡單的應(yīng)用不需要區(qū)分 biz-service 和 core-service，但是如果業(yè)務(wù)復(fù)雜度比較高，最佳實踐是把service 拆二層，biz-service 負責(zé)業(yè)務(wù)邏輯，業(yè)務(wù)邏輯是繁雜多樣的，隨時會變，而那些具有通用性的基礎(chǔ)能力、有時候也叫平臺能力放到core-service 里面，比如很多業(yè)務(wù)都需要支付能力，支付的服務(wù)就可以作為平臺能力放在core-service 提供給biz-service使用。biz-service 使用core-service的能力，在阿里內(nèi)部系統(tǒng)，非常重視core-service，如果系統(tǒng)拆分成域來看，core-service 可以理解成中臺，biz-service 是前臺，大中臺小前臺戰(zhàn)略除了在組織結(jié)構(gòu)上，也可以在應(yīng)用內(nèi)體現(xiàn)，一般都是把中臺能力做強，前臺能力負責(zé)靈活、高效滿足業(yè)務(wù)需求。

facade

門面接口，和設(shè)計模式里面的門面有點像，facade 模塊只定義接口，具體實現(xiàn)放在biz-service-impl 模塊。facade 一般是提供給外部系統(tǒng)的，打成jar 包，人家依賴你，只需要知道接口定義的出入?yún)ⅲ唧w實現(xiàn)他不需要關(guān)心。你的facade 服務(wù)發(fā)布成rpc provider，為上游提供服務(wù)。

其實有很多系統(tǒng)會把facade 層放在core-service 層下面，因為認為facade 提供的服務(wù)都是rpc 服務(wù)，一般只在內(nèi)部發(fā)布，但是我覺得放在和controller 一層邏輯比較順，也比較清晰，當(dāng)然也是因為調(diào)用我controller 的也是內(nèi)部系統(tǒng)，所以我一視同仁。

biz-service-impl

業(yè)務(wù)邏輯實現(xiàn)，實現(xiàn)facade 接口和 biz-service-api。

core-service-api

核心能力服務(wù)api定義。核心原子能力的定義，比如支付能力、模型運行能力、通用對象定位能力、安全。

core-domain

這里承載核心領(lǐng)域，最重要的模型都放在這個模塊，有的架構(gòu)設(shè)計這里除了模型，還會防m(xù)odel-service，但是我還是覺得模型更多是數(shù)據(jù)的概念，模型的操作應(yīng)該是自包含的，也就是模型的操作只依賴自己的數(shù)據(jù)，可以直接在模型內(nèi)部完成，如果需要多個模型參與的操作都應(yīng)該交給core-service 來完成。算是DDD 領(lǐng)域驅(qū)動設(shè)計的折中，可理解性比規(guī)范有時候更重要，這方面的例子還很多，比如大型互聯(lián)網(wǎng)公司的表設(shè)計就沒有遵循數(shù)據(jù)庫規(guī)范的范式，表join 都很少，單表冗余情況很多。

infrastructure

基礎(chǔ)的比如數(shù)據(jù)庫、緩存、消息隊列、流程引擎、審批流、定時任務(wù)這種系統(tǒng)基礎(chǔ)設(shè)施，還有第三方外部系統(tǒng)依賴都放在這一層。一般我的建議是每引入一個第三方服務(wù)或者組件，都定義service-api 和 serviceImpl，api做出通用性的，不依賴具體第三方的存在，這樣比如接入了A 公司提供的流程引擎，發(fā)現(xiàn)不合適，不好用的時候api 這一層不用動，也不會影響到上層應(yīng)用的服務(wù)，而且還可以非常好的支持SPI機制，方便切流到新服務(wù)提供者上去。

上面有的是按照層的概念說的，有的是按照模塊來說的。這篇文章我自己覺得挺有價值的，工程上的一些最佳實踐，希望對大家在做應(yīng)用架構(gòu)設(shè)計的時候有幫助。