[[427981]]

本文轉(zhuǎn)載自微信公眾號(hào)「架構(gòu)精進(jìn)之路」，作者架構(gòu)精進(jìn)之路。轉(zhuǎn)載本文請(qǐng)聯(lián)系架構(gòu)精進(jìn)之路公眾號(hào)。

hello，大家好，我是張張，「架構(gòu)精進(jìn)之路」公號(hào)作者。

一、架構(gòu)設(shè)計(jì)分層

通常情況下，我們的架構(gòu)設(shè)計(jì)圖大概率會(huì)如下圖這個(gè)樣子了，首先聲明一點(diǎn)，這其實(shí)并沒有什么不妥的，這也是很典型的分層設(shè)計(jì)啦~

關(guān)于各個(gè)分層的具體描述，就簡(jiǎn)單的來(lái)聊聊吧。

• Client層

這個(gè)比較簡(jiǎn)單，就不多說(shuō)了。

• Business Logic

業(yè)務(wù)邏輯這層分成 Manager 和 Engine 層，Manager 負(fù)責(zé)管理流程類的易變性，Engine 負(fù)責(zé)某個(gè)活動(dòng)節(jié)點(diǎn)本身的易變性。

什么是流程易變性呢?簡(jiǎn)單理解，就是工作流嘛。

下面的兩個(gè)流程是完全相同的，只是在第二步使用的活動(dòng)不一樣，如果 B 和 D 干的是同一件事情，那么 B 和 D 應(yīng)該被封裝進(jìn)同一個(gè) Engine 中。

當(dāng)然，如果 B 和 D 功能不一樣，那這兩個(gè)流程就不一樣了，另論。

• Resource Access

這一層是資源訪問層，負(fù)責(zé)一些存儲(chǔ)資源的封裝，也就是說(shuō)公司內(nèi)的基礎(chǔ)設(shè)施要變化的時(shí)候，不應(yīng)該影響到上層的業(yè)務(wù)，這種在 DDD 社區(qū)也有 Repo Pattern 之類的，比較好理解。

• Utilities

那些紫色的組件，一般是一些大家公用的非功能性 SDK，也比較好理解。

架構(gòu)圖里的模塊大多是服務(wù)：

這樣的分層每一次都是在解決 Who、What、How、Where 這四個(gè)問題：

從上往下，易變性是逐漸降低的，這個(gè)我們可以理解，公司里最常修改的都是上面的一些業(yè)務(wù)邏輯，底層的基礎(chǔ)設(shè)施幾年變一次就不錯(cuò)了。

自上而下的重用性是逐漸增加的，Manager 經(jīng)常做變更、重構(gòu)、完全重寫，都是挺正常的。

二、架構(gòu)組合設(shè)計(jì)方案

• 開放架構(gòu)

任何組件都可以調(diào)用任何其它組件，而不必考慮組件所在的層。可以向上向下調(diào)用。

開發(fā)架構(gòu)有很大的靈活性，不過顯然會(huì)導(dǎo)致層與層之間互相耦合，層內(nèi)的橫向調(diào)用也會(huì)導(dǎo)致層內(nèi)的相互耦合，這樣的項(xiàng)目是沒法維護(hù)的。

作者認(rèn)為產(chǎn)生橫向調(diào)用是因?yàn)榧軜?gòu)按照功能分解的惡果之一。

• 封閉架構(gòu)

封閉架構(gòu)禁止層內(nèi)的橫向調(diào)用，并且禁止下層調(diào)用上層系統(tǒng)。

這樣才能發(fā)揮分層的優(yōu)勢(shì)，將層與層之間解耦。

封閉架構(gòu)只允許一層的組件調(diào)用相鄰較低層中的組件，下層的組件封裝更下層的邏輯。

半封閉半開放架構(gòu)

基礎(chǔ)設(shè)施的關(guān)鍵部分，有時(shí)互相調(diào)用是難以避免的。因?yàn)榛A(chǔ)設(shè)施要考慮性能問題，必須要進(jìn)行最大優(yōu)化，而有時(shí)向下轉(zhuǎn)換會(huì)導(dǎo)致性能問題。

但大多系統(tǒng)不需要半開半閉，只要封閉就可以了。

放寬一點(diǎn)封閉架構(gòu)的規(guī)則

因?yàn)榉忾]架構(gòu)的要求太苛刻，實(shí)際開發(fā)中確實(shí)會(huì)遇到問題，在下面這些情況下也可以酌情放寬：

調(diào)用 utilities

按業(yè)務(wù)邏輯訪問資源訪問，即 manager 層直接調(diào)用 resource access 層

manager 組件調(diào)用不太相鄰的引擎

manager 組件到其它 manager 組件通過 MQ 來(lái)通信，這種情況 manager 組件不需要知道其它組件，只要發(fā) message 就可以了

• 設(shè)計(jì)禁忌

下面這些行為都是不能允許的：

Client 不應(yīng)該在一個(gè)用例中調(diào)用多個(gè) Manager，不應(yīng)該直接調(diào)用 Engine

Engine 不應(yīng)該發(fā)布消息，不應(yīng)該訂閱消息隊(duì)列

Engine 與 Manager 不應(yīng)該相互調(diào)用

三、總結(jié)

關(guān)于可組合架構(gòu)與架構(gòu)驗(yàn)證，一定不要根據(jù)需求設(shè)計(jì)，而是要根據(jù)易變性來(lái)設(shè)計(jì)。

設(shè)計(jì)系統(tǒng)時(shí)，要從需求列表中找到核心需求，在設(shè)計(jì)完成之后，先用核心用例進(jìn)行架構(gòu)驗(yàn)證。在增加新的需求時(shí)，應(yīng)該不太需要變更架構(gòu)，這才說(shuō)明這套架構(gòu)設(shè)計(jì)對(duì)了。 

系統(tǒng)中的功能是集成的結(jié)果，而不是實(shí)現(xiàn)的結(jié)果。