[[410313]]

本文轉載自微信公眾號「逸言」，作者我是張逸。轉載本文請聯系逸言公眾號。

通過《多維度規劃業務架構》，我們獲得了由業務領域-業務組件-業務服務三個層次組成的業務架構。雖然是架構，但其本質仍然屬于問題空間，其目的在于真實地探索問題空間，了解我們要解決什么樣的問題。我們用到“分解”的方法，并非在解決問題，而是希望通過橫向分層與縱向切分讓問題空間變得更小，降低業務復雜度罷了。

這種分解層次體現為：

• 業務領域是對目標系統之系統范圍進行劃分，劃分依據為價值高低
• 業務組件是對業務領域的劃分，劃分依據在于業務相關性
• 業務服務是對業務組件的劃分，劃分依據在于領域模型的知識語境

領域驅動進行的業務分解，既是對問題空間的探索，又自然地暗合確定解決方案的思路。由于有清晰的邊界存在，這一做法并未混淆問題空間與解空間，卻天然地搭建了一種映射方法，使得我們能夠以較小成本將業務架構映射為IT架構中的應用架構。

映射體系如下圖所示：

在圖右側所示的應用架構中，我旗幟鮮明地標記了前臺、中臺與后臺，意味著我對應用架構的劃分遵循了中臺戰略規劃的思想。

我所理解的“中臺”，滿足以下定義：

• 中臺是企業數字化轉型的能力復用戰略規劃體系
• 中臺是演進式的能力復用戰略動態規劃過程

顯然，中臺不是產品，也不是平臺，而是一種規劃體系。在企業架構的應用架構中，中臺僅占據了中間代表了“能力服務層”的一部分，體現為由應用組件構成的能力中心。所謂的“能力復用戰略動態規劃過程”，就是在企業戰略愿景的指導下，以能力復用為最終目的：

• 對于產品服務層，通過識別變化頻率與復用粒度，逐步將前臺的產品特性沉淀為可復用的業務能力中心
• 對于基礎服務層，通過識別企業IT資產，逐步從后臺的工具與框架中提煉出可復用的業務能力中心

換言之，中臺不是獨立的，隨著時間的推移，應形成前臺、中臺和后臺(統稱為“三臺”)職責之間聯動;中臺也不是靜態不變的，同樣隨著時間的推移，三臺的邊界發生動態變化。

之所以要為應用架構建立中臺，是以復用為目的，提升研發的效率和質量。能力中心的構成，使得整個企業的系統架構可以打破煙囪系統天然構成的壁壘，也有利于它的快速演化，適應企業高速發展的業務需要。

中臺戰略體系保留了前臺，主要是為了適應創新型產品的演變。前臺的設計屬于產品思維的范疇，因為它牽涉到快速試錯的成本，沒有時間和成本考慮對復用能力的沉淀，然而，對于中臺已經具備的能力中心，不妨取“拿來主義”的態度，直接復用。如此既保證了快，又保證了穩。

在我認為的“三臺”中，后臺并非基礎設施，它同樣屬于業務范疇。從Pace-Layer Architecture的角度講，后臺提供的業務其區別主要在于它的變化頻率更低，甚至可能幾乎不變;從領域驅動設計的子領域角度講，后臺提供的業務更加通用，以至于考慮購買而非自己構建的方式實現。

如果后臺穩定地提供了業務支撐，其收益高于維護成本，則不必一定要將其提煉為能力中心，甚至于它就是一個或多個相對獨立而封閉的IT系統，對它的改造存在諸多阻力，改造成本極高，就得允許在企業IT系統生態中繼續存在這樣的遺留煙囪系統。

不管是前臺的產品，還是中臺的能力中心，抑或后臺的工具或框架，其解決方案皆由應用組件構成，它由業務組件映射而得。本質上，業務組件與應用組件都是限界上下文，但前者對應的限界上下文只考慮了業務邊界，后者對應的限界上下文在此基礎上繼續深化，分別考慮團隊角度的工作邊界和技術角度的應用邊界，進一步梳理限界上下文的邊界，使其與應用架構相匹配。為示區分，我將其命名為“應用組件”。

應用組件與限界上下文也有不同之處。在領域驅動設計中，限界上下文確定的是邏輯邊界，而在應用架構中，還需要確定它的物理邊界。物理邊界的確定是從質量屬性角度考慮的，例如對可擴展性、可伸縮性、低延遲、高并發的響應，技術棧的限制，資源獨立性的要求，可以確定該應用組件究竟應定義為服務(Service)，還是庫(library)。

通常，中臺能力中心的應用組件應考慮微服務化，后臺工具或框架則不然，大多數時候，定義為庫可能更合適。對于前臺，可以考慮一個產品對應一個微服務，也可以考慮一個產品的特性對應一個微服務。這取決于前臺產品的粒度。

業務架構中純粹表達業務的業務服務，在映射到應用架構時，被定義為應用組件需要公開在外的服務接口，我將其稱之為“服務契約”，目的是體現服務調用者與服務提供者之間的一種”契約“關系。

一個業務服務映射到解空間，會定義一個服務契約;反之，一個服務契約卻未必對應問題空間的業務服務——因為業務服務中的一個執行步驟也可能映射為一個服務契約。應用組件之間存在協作關系，根據業務服務的定義，如果一個業務服務的某個執行步驟由另外一個應用組件提供，就需要將其定義為另一個服務契約，但它并非業務服務。例如，“提交訂單”業務服務對應于訂單應用組件，需要對外公開”提交訂單“的服務契約;在執行提交訂單的流程時，需要驗證庫存，該功能由庫存應用組件承擔。由于訂單應用組件會調用它，因而需要對外公開”驗證庫存“的服務契約，但”驗證庫存“并非一個業務服務，如下圖所示：

業務服務屬于問題空間的范疇，服務契約屬于解空間的范疇，如此才是合理的。

服務契約對應于我提出的《菱形對稱架構》中的北向網關。若應用組件為服務，則對應遠程服務;為庫，則對應本地服務。它們都不屬于領域層的內容。業務服務的需求表現為業務服務規約，它的輸入成為領域分析建模的基礎;服務契約需要構成菱形對稱架構的角色構造型共同協作完成，利用服務驅動設計可以驅動出領域設計模型，進而對其進行建模實現。

從產品/能力中心/工具/框架到應用組件，再從應用組件到服務契約，都有領域驅動設計的對應模式或方法去實現，由此就能實現應用架構的真正落地。若按照中臺戰略思想規劃應用架構，意味著中臺的落地也有了可供參考的實現過程與方法。

當然，通常所謂的”中臺“，都會建立雙中臺，即業務中臺和數據中臺。這里參考了領域驅動設計的方法，針對的是業務中臺的落地，亦可以理解為是應用架構的微服務化。至于數據中臺，它關注的是全域數據的生命周期管理、數據資產的梳理與建設、全域數據分析與數據智能挖掘的數據服務，其著眼點顯然和業務中臺有著天壤之別，需要另外的設計方法與實現手段。