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

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

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

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

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

controller

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

biz-service-api

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

facade

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

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

biz-service-impl

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

core-service-api

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

core-domain

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

infrastructure

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

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

原文鏈接：https://mp.weixin.qq.com/s/-Ae2GnPwWFnpKFtQTKOCKA