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

ITPUB社群 發表於 2022-12-01

一、架構設計分層

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

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


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

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


三、總結

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

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

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

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70024420/viewspace-2926161/,如需轉載,請註明出處,否則將追究法律責任。