關於架構設計的易變性，應該如何理解呢？

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

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

• 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 不應該相互呼叫

三、總結

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

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

系統中的功能是整合的結果，而不是實現的結果。