前言

從強(qiáng)調(diào)內(nèi)外隔離的六邊形架構(gòu)，逐漸發(fā)展衍生出的層層遞進(jìn)、注重領(lǐng)域模型的洋蔥架構(gòu)，再到和DDD完美契合的整潔架構(gòu)。架構(gòu)風(fēng)格的不斷演進(jìn)，其實(shí)就是為了適應(yīng)軟件需求越來(lái)越復(fù)雜的特點(diǎn)。

可以看到，越現(xiàn)代的架構(gòu)風(fēng)格越傾向于清晰的職責(zé)定位，且讓領(lǐng)域模型成為架構(gòu)的核心。

基于這些架構(gòu)風(fēng)格，在軟件架構(gòu)設(shè)計(jì)過(guò)程中又有非常多的架構(gòu)分層模型。

傳統(tǒng)三層架構(gòu)

傳統(tǒng)服務(wù)通常使用三層架構(gòu)：

?門(mén)面層：作為服務(wù)暴露的入口，處理所有的外部請(qǐng)求。部分情況下，門(mén)面層甚至不需要單獨(dú)定義對(duì)象而是直接使用服務(wù)層的實(shí)體定義。

?服務(wù)層：作為核心業(yè)務(wù)層，包含所有業(yè)務(wù)邏輯。并對(duì)基礎(chǔ)層能力進(jìn)行簡(jiǎn)單組合提供一定的能力復(fù)用。通常服務(wù)層會(huì)進(jìn)行實(shí)體定義來(lái)防止下層對(duì)象體直接暴露給外部服務(wù)，導(dǎo)致底層任何變化都有可能直接傳遞到外部，非常不穩(wěn)定。

?基礎(chǔ)層：用來(lái)存放dao和外部rpc服務(wù)的封裝，二者可以拆分為不同的module，也可合二為一，以不同package進(jìn)行隔離。

三層架構(gòu)特點(diǎn)就是簡(jiǎn)單，適用于一些無(wú)復(fù)雜業(yè)務(wù)場(chǎng)景的小型應(yīng)用，或者“數(shù)據(jù)不可變”作為基礎(chǔ)原則的DOP（面向數(shù)據(jù)編程）服務(wù)。

但是當(dāng)業(yè)務(wù)場(chǎng)景稍微復(fù)雜一些、調(diào)用層級(jí)較多時(shí)，可復(fù)用性、可維護(hù)性就都非常差了，很多代碼都耦合在一起，牽一發(fā)動(dòng)全身。

??

?

DDD架構(gòu)

DDD架構(gòu)可以看做是整潔架構(gòu)的一種實(shí)現(xiàn)，分層職責(zé)如下：

?適配層：用來(lái)做外部不同端請(qǐng)求的適配器，隔離不同端的協(xié)議差異，包裝不同端不同樣式的響應(yīng)體。

?應(yīng)用層：用例、任務(wù)入口、消息隊(duì)列監(jiān)聽(tīng)均在這一層，可以理解為業(yè)務(wù)流程的入口，通過(guò)聚合根的構(gòu)造執(zhí)行相應(yīng)的命令操作。

?領(lǐng)域服務(wù)層：包含核心的領(lǐng)域服務(wù)定義，并定義了gateway來(lái)做一層依賴(lài)倒置，使基礎(chǔ)設(shè)施層僅做實(shí)現(xiàn)。

?基礎(chǔ)設(shè)施層包含一切基礎(chǔ)能力：數(shù)據(jù)庫(kù)、ES、遠(yuǎn)程調(diào)用封裝等等。

??

優(yōu)點(diǎn)

?核心穩(wěn)定：領(lǐng)域模型在依賴(lài)鏈上是頂層角色，不依賴(lài)任何其他模塊，所以極其穩(wěn)定。其他任何業(yè)務(wù)域、存儲(chǔ)、邊緣能力的變化都不會(huì)對(duì)領(lǐng)域模型造成影響。

?敏捷：適合不同團(tuán)隊(duì)一起開(kāi)發(fā)和維護(hù)而不會(huì)產(chǎn)生沖突。

?可拆分：當(dāng)有屆上下文隨著演進(jìn)逐漸膨脹時(shí)，很容易拆分成微服務(wù)。

?可擴(kuò)展：添加新的功能非常簡(jiǎn)單，從而使得開(kāi)發(fā)人員能夠更快的部署和調(diào)整。

?可演進(jìn)：良好的可測(cè)試性帶來(lái)非常低的重構(gòu)成本，不會(huì)隨著不斷迭代導(dǎo)致項(xiàng)目成為難以修改的“大泥球”。

如此多的優(yōu)點(diǎn)自然帶來(lái)明確的缺點(diǎn)

?專(zhuān)業(yè)性要求較高：需要對(duì)業(yè)務(wù)、架構(gòu)原則理解深刻的人員進(jìn)行設(shè)計(jì)和維護(hù)，不恰當(dāng)?shù)念I(lǐng)域模型將使后續(xù)迭代極為痛苦。

?開(kāi)發(fā)成本高：復(fù)雜的架構(gòu)設(shè)計(jì)，更多的架構(gòu)分層，自然帶來(lái)代碼行數(shù)的指數(shù)級(jí)增長(zhǎng)。尤其是項(xiàng)目前期的開(kāi)發(fā)任務(wù)變得異常繁重。

?不再適合簡(jiǎn)單的業(yè)務(wù)場(chǎng)景：實(shí)現(xiàn)一個(gè)簡(jiǎn)單的CRUD顯得過(guò)于復(fù)雜。

?改變決策困難：嘗試使用整潔架構(gòu)需要和團(tuán)隊(duì)的管理層和其他成員達(dá)成一致，這往往需要非常強(qiáng)大的說(shuō)服力。如果在架構(gòu)演進(jìn)過(guò)程中想切換回其他架構(gòu)模式也十分困難，幾乎是整個(gè)項(xiàng)目級(jí)別的重構(gòu)工作。

簡(jiǎn)單的微服務(wù)分層架構(gòu)

基于六邊形架構(gòu)規(guī)范的接口適配原則和防腐理念，同時(shí)借鑒了CQRS模式的優(yōu)點(diǎn)，我們定義了一個(gè)簡(jiǎn)單的微服務(wù)分層架構(gòu)。

骨架Maven坐標(biāo)：

com.jdt.open
simple-microservices-layered-architecture-archetype
1.4.0

分層定義：

?門(mén)面層：作為程序的入口，通過(guò)包隔離來(lái)存放JSF服務(wù)、Rest服務(wù)、定時(shí)任務(wù)和MQ消費(fèi)，其中對(duì)外提供服務(wù)的接口定義存放在單獨(dú)的api包中。該層的請(qǐng)求定義命名以Request結(jié)尾，響應(yīng)體命名以Response結(jié)尾。

?領(lǐng)域服務(wù)層：每一個(gè)領(lǐng)域服務(wù)存放在單獨(dú)的module中，并通過(guò)單獨(dú)的api包對(duì)外暴露能力。該層的命令請(qǐng)求定義命名以Command結(jié)尾，查詢(xún)請(qǐng)求定義命名以Query結(jié)尾，響應(yīng)體命名以Dto結(jié)尾。

?基礎(chǔ)設(shè)施層：存放數(shù)據(jù)庫(kù)、ES、遠(yuǎn)程調(diào)用服務(wù)的封裝。該層的持久化數(shù)據(jù)定義命名以Po結(jié)尾。遠(yuǎn)程命令服務(wù)入?yún)⒚訰pcCommand結(jié)尾，遠(yuǎn)程查詢(xún)服務(wù)入?yún)⒚訰pcQuery結(jié)尾，響應(yīng)體命名以RpcDto結(jié)尾。

??

最佳實(shí)踐

1.命令服務(wù)必須訪問(wèn)領(lǐng)域服務(wù)層，允許簡(jiǎn)單查詢(xún)直接調(diào)用基礎(chǔ)設(shè)施層。

2.參數(shù)校驗(yàn)、請(qǐng)求出入?yún)⑷罩尽徲?jì)日志記錄、TraceID預(yù)埋、異常處理等非核心業(yè)務(wù)能力均由公共組件（參考： Open-Lab組件包 ）完成，減少項(xiàng)目?jī)?nèi)部的邊緣能力代碼。

3.由于在門(mén)面層進(jìn)行統(tǒng)一的異常處理，非必要時(shí)無(wú)需在項(xiàng)目中進(jìn)行大面積的try-catch，讓代碼更清爽。

4.實(shí)際開(kāi)發(fā)過(guò)程中，門(mén)面層、領(lǐng)域服務(wù)層和基礎(chǔ)設(shè)施層均有各自的實(shí)體定義，跨層調(diào)用的對(duì)象體轉(zhuǎn)換使用MapStruct組件來(lái)減少手寫(xiě)映射代碼的工作量。

5.數(shù)據(jù)層使用Fluent-Mybatis，最大好處是減少后期迭代中，數(shù)據(jù)對(duì)象增減字段時(shí)修改Mapper的成本。

優(yōu)點(diǎn)

1. 開(kāi)發(fā)效率

簡(jiǎn)單的業(yè)務(wù)開(kāi)發(fā)過(guò)程中，相比較書(shū)寫(xiě)核心業(yè)務(wù)邏輯，更多的工作量幾乎都是來(lái)自處理跨層調(diào)用時(shí)對(duì)象轉(zhuǎn)換和Mapper定義，通過(guò)MapStruct和Fluent-Mybatis等組件的使用（也許再加上GitHub Copilot

審核編輯 黃宇