[[410313]]

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

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

這種分解層次體現(xiàn)為：

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

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

映射體系如下圖所示：

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

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

• 中臺是企業(yè)數(shù)字化轉型的能力復用戰(zhàn)略規(guī)劃體系
• 中臺是演進式的能力復用戰(zhàn)略動態(tài)規(guī)劃過程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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