[[427981]]

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

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

一、架構(gòu)設計分層

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

關(guān)于各個分層的具體描述，就簡單的來聊聊吧。

• Client層

這個比較簡單，就不多說了。

• Business Logic

業(yè)務邏輯這層分成 Manager 和 Engine 層，Manager 負責管理流程類的易變性，Engine 負責某個活動節(jié)點本身的易變性。

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

下面的兩個流程是完全相同的，只是在第二步使用的活動不一樣，如果 B 和 D 干的是同一件事情，那么 B 和 D 應該被封裝進同一個 Engine 中。

當然，如果 B 和 D 功能不一樣，那這兩個流程就不一樣了，另論。

• Resource Access

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

• Utilities

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

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

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

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

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

二、架構(gòu)組合設計方案

• 開放架構(gòu)

任何組件都可以調(diào)用任何其它組件，而不必考慮組件所在的層?？梢韵蛏舷蛳抡{(diào)用。

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

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

• 封閉架構(gòu)

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

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

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

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

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

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

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

因為封閉架構(gòu)的要求太苛刻，實際開發(fā)中確實會遇到問題，在下面這些情況下也可以酌情放寬：

調(diào)用 utilities

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

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

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

• 設計禁忌

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

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

Engine 不應該發(fā)布消息，不應該訂閱消息隊列

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

三、總結(jié)

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

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

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