[[427981]]

本文轉載自微信公眾號「架構精進之路」，作者架構精進之路。轉載本文請聯系架構精進之路公眾號。

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

一、架構設計分層

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

關于各個分層的具體描述，就簡單的來聊聊吧。

• Client層

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

• Business Logic

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

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

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

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

• Resource Access

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

• Utilities

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

架構圖里的模塊大多是服務：

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

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

自上而下的重用性是逐漸增加的，Manager 經常做變更、重構、完全重寫，都是挺正常的。

二、架構組合設計方案

• 開放架構

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

開發架構有很大的靈活性，不過顯然會導致層與層之間互相耦合，層內的橫向調用也會導致層內的相互耦合，這樣的項目是沒法維護的。

作者認為產生橫向調用是因為架構按照功能分解的惡果之一。

• 封閉架構

封閉架構禁止層內的橫向調用，并且禁止下層調用上層系統。

這樣才能發揮分層的優勢，將層與層之間解耦。

封閉架構只允許一層的組件調用相鄰較低層中的組件，下層的組件封裝更下層的邏輯。

半封閉半開放架構

基礎設施的關鍵部分，有時互相調用是難以避免的。因為基礎設施要考慮性能問題，必須要進行最大優化，而有時向下轉換會導致性能問題。

但大多系統不需要半開半閉，只要封閉就可以了。

放寬一點封閉架構的規則

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

調用 utilities

按業務邏輯訪問資源訪問，即 manager 層直接調用 resource access 層

manager 組件調用不太相鄰的引擎

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

• 設計禁忌

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

Client 不應該在一個用例中調用多個 Manager，不應該直接調用 Engine

Engine 不應該發布消息，不應該訂閱消息隊列

Engine 與 Manager 不應該相互調用

三、總結

關于可組合架構與架構驗證，一定不要根據需求設計，而是要根據易變性來設計。

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

系統中的功能是集成的結果，而不是實現的結果。