09 | 中臺：數字轉型後到底應該共享什麼？
課程鏈接：https://time.geekbang.org/column/article/159580
中臺是數字化轉型的一個熱門話題。繼阿里提出中臺概念後，很多人又提出了各種各樣的中臺。今天主要討論業務中臺和數據中臺。作爲企業數字化中臺轉型的整體，我也會順帶聊一聊前臺和後臺的一些設計思路。
中臺源於平臺，但它的戰略高度要比平臺高很多。
平臺到底是不是中臺？
平臺只是將部分通用的公共能力獨立爲共享平臺。雖然可以通過 API 或者數據對外提供公共共享服務，解決系統重複建設的問題，但這類平臺並沒有和企業內的其它平臺或應用，實現頁面、業務流程和數據從前端到後端的全面融合，並且沒有將核心業務服務鏈路作爲一個整體方案考慮，各平臺仍然是分離且獨立的。平臺解決了公共能力複用的問題，但離中臺的目標顯然還有一段差距！
中臺到底是什麼？
“一千個讀者就有一千個哈姆雷特”。
阿里自己人對中臺的定義：“中臺是一個基礎的理念和架構，我們要把所有的基礎服務用中臺的思路建設，進行聯通，共同支持上端的業務。業務中臺更多的是支持在線業務，數據中臺提供了基礎數據處理能力和很多的數據產品給所有業務方去用。業務中臺、數據中臺、算法中臺等等一起提供對上層業務的支撐。”
思特沃克對中臺的定義：“中臺是企業級能力複用平臺。”
可以提煉出幾個關於中臺的關鍵詞：共享、聯通、融合和創新。聯通是前臺以及中臺之間的聯通，融合是前臺流程和數據的融合，並以共享的方式支持前端一線業務的發展和創新。
中臺首先體現的是一種企業級的能力，它提供的是一套企業級的整體解決方案，解決小到企業、集團，大到生態圈的能力共享、聯通和融合問題，支持業務和商業模式創新。通過平臺聯通和數據融合爲用戶提供一致的體驗，更敏捷地支撐前臺一線業務。中臺來源於平臺，但中臺和平臺相比，它更多體現的是一種理念的轉變，它主要體現在這三個關鍵能力上：對前臺業務的快速響應能力；企業級複用能力；從前臺、中臺到後臺的設計、研發、頁面操作、流程服務和數據的無縫聯通、融合能力。其中最關鍵的是快速響應能力和企業級的無縫聯通和融合能力，尤其是對於跨業經營的超大型企業來說至關重要。
數字化轉型中臺應該共享什麼？
相對互聯網企業而言，傳統企業的渠道應用更多樣化，有面向內部人員的門店類應用、面向外部用戶的互聯網電商以及移動 APP 類應用。這些應用面向的用戶和場景可能不同，但其功能類似，基本涵蓋了核心業務能力。此外，傳統企業也會將部分核心應用的頁面或 API 服務能力開放給生態圈第三方，相互借力發展。
爲了適應不同業務和渠道的發展，過去很多企業的做法是開發很多獨立的應用或 APP。但由於 IT 系統建設初期並沒有企業級的整體規劃，平臺之間融合不好，就導致了用戶體驗不好，最關鍵的是用戶並不想裝那麼多 APP。
爲了提升用戶體驗，實現統一運營，很多企業開始縮減 APP 的數量，開始通過一個 APP 集成企業內的所有能力，聯通前臺所有的核心業務鏈路。由於傳統企業的商業模式和 IT 系統建設發展的歷程與互聯網企業不是完全一樣的，因此傳統企業的中臺建設策略與阿里中臺戰略也應該有所差異，需要共享的內容也不一樣。
由於渠道多樣化，傳統企業不僅要將通用能力中臺化，以實現通用能力的沉澱、共享和複用，這裏的通用能力對應 DDD 的通用域或支撐域；傳統企業還需要將核心能力中臺化，以滿足不同渠道的核心業務能力共享和複用的需求，避免傳統核心和互聯網不同渠道應用出現“後端雙核心、前端兩張皮”的問題，這裏的核心能力對應 DDD 的核心域。
這就屬於業務中臺的範疇了，我們需要解決核心業務鏈路的聯通和不同渠道服務共享的問題。除此之外，我們還需要解決系統微服務拆分後的數據孤島、數據融合和業務創新等問題，這就屬於數據中臺的範疇了，尤其是當我們採用分佈式架構以後，我們就更應該關注微服務拆分後的數據融合和共享問題了。
綜上，在中臺設計和規劃時，我們需要整體考慮企業內前臺、中臺以及後臺應用的協同，實現不同渠道應用的前端頁面、流程和服務的共享，還有核心業務鏈路的聯通以及前臺流程和數據的融合、共享，支持業務和商業模式的創新。
如何實現前中後臺的協同？
企業級能力往往是前中後臺協同作戰能力的體現。如果把業務中臺比作陸軍、火箭軍和空軍等專業軍種的話，它主要發揮戰術專業能力。前臺就是作戰部隊，它需要根據前線的戰場需求，對業務中臺的能力進行調度，實現能力融合和效率最大化。而數據中臺就是信息情報中心和聯合作戰總指揮部，它能夠彙集各種數據、完成分析，制定戰略和戰術計劃。後臺就是後勤部隊，提供技術支持。
1.前臺：傳統企業的早期系統有不少是基於業務領域或組織架構來建設的，每個系統都有自己的前端，相互獨立，用戶操作是豎井式，需要登錄多個系統才能完成完整的業務流程。
中臺後的前臺建設要有一套綜合考慮業務邊界、流程和平臺的整體解決方案，以實現各不同中臺前端操作、流程和界面的聯通、融合。不管後端有多少箇中臺，前端用戶感受到的就是隻有一個前臺。
在前臺設計中我們可以借鑑微前端的設計思想，在企業內不僅實現前端解耦和複用，還可以根據核心鏈路和業務流程，通過對微前端頁面的動態組合和流程編排，實現前臺業務的融合。前端頁面可以很自然地融合到不同的終端和渠道應用核心業務鏈路中，實現前端頁面、流程和功能複用。
2.中臺：傳統企業的核心業務大多是基於集中式架構開發的，而單體系統存在擴展性和彈性伸縮能力差的問題，因此無法適應忽高忽低的互聯網業務場景。而數據類應用也多數通過 ETL 工具抽取數據實現數據建模、統計和報表分析功能，但由於數據時效和融合能力不夠，再加上傳統數據類應用本來就不是爲前端而生的，因此難以快速響應前端一線業務。業務中臺的建設可採用領域驅動設計方法，通過領域建模，將可複用的公共能力從各個單體剝離，沉澱並組合，採用微服務架構模式，建設成爲可共享的通用能力中臺。同樣的，我們可以將核心能力用微服務架構模式，建設成爲可面向不同渠道和場景的可複用的核心能力中臺。 業務中臺向前臺、第三方和其它中臺提供 API 服務，實現通用能力和核心能力的複用。
在將傳統集中式單體按業務職責和能力細分爲微服務，建設中臺的過程中，會產生越來越多的獨立部署的微服務。這樣做雖然提升了應用彈性和高可用能力，但由於微服務的物理隔離，原來一些系統內的調用會變成跨微服務調用，再加上前後端分離，微服務拆分會導致數據進一步分離，增加企業級應用集成的難度。如果沒有合適的設計和指導思想，處理不好前臺、中臺和後臺的關係，將會進一步加劇前臺流程和數據的孤島化、碎片化。
數據中臺的主要目標是打通數據孤島，實現業務融合和創新，包括三大主要職能：
- 一是完成企業全域數據的採集與存儲，實現各不同業務類別中臺數據的彙總和集中管理。
- 二是按照標準的數據規範或數據模型，將數據按照不同主題域或場景進行加工和處理，形成面向不同主題和場景的數據應用，比如客戶視圖、代理人視圖、渠道視圖、機構視圖等不同數據體系。
- 三是建立業務需求驅動的數據體系，基於各個維度的數據，深度萃取數據價值，支持業務和商業模式的創新。
相應的，數據中臺的建設就可分爲三步走：
- 第一步實現各中臺業務數據的彙集，解決數據孤島和初級數據共享問題。
- 第二步實現企業級實時或非實時全維度數據的深度融合、加工和共享。
- 第三步萃取數據價值，支持業務創新，加速從數據轉換爲業務價值的過程。
數據中臺不僅限於分析型場景，也適用於交易型場景。它可以建立在數據倉庫或數據平臺之上，將數據服務化之後提供給業務系統。基於數據庫日誌捕獲的技術，使數據的時效性大大提升，這樣就可以爲交易型場景提供很好的支撐。綜上，數據中臺主要完成數據的融合和加工，萃取數據業務價值，支持業務創新，對外提供數據共享服務。
3.後臺：阿里對前臺、中臺和後臺的定位：前臺主要面向客戶以及終端銷售者，實現營銷推廣以及交易轉化；中臺主要面向運營人員，完成運營支撐；後臺主要面向後臺管理人員，實現流程審覈、內部管理以及後勤支撐，比如採購、人力、財務和 OA 等系統。
那對於後臺，爲了實現內部的管理要求，很多人習慣性將這些管理要求嵌入到核心業務流程中。而一般來說這類內控管理需求對權限、管控規則和流程等要求都比較高，但是大部分管理人員只是參與了某個局部業務環節的審覈。這類複雜的管理需求，會憑空增加不同渠道應用前臺界面和核心流程的融合難度以及軟件開發的複雜度。
在設計流程審覈和管理類功能的時候，我們可以考慮按角色或崗位進行功能聚合，將複雜的管理需求從通用的核心業務鏈路中剝離，參考小程序的建設模式，通過特定程序入口嵌入前臺 APP 或應用中。
管理需求從前臺核心業務鏈路剝離後，前臺應用將具有更好的通用性，它可以更加容易地實現各渠道前臺界面和流程的融合。一個前臺應用或 APP 可以無差別地同時面向外部互聯網用戶和內部業務人員，從而促進傳統渠道與互聯網渠道應用前臺的融合。
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
10 | DDD、中臺和微服務：他們是如何協作的？
課程鏈接：https://time.geekbang.org/column/article/161004
DDD 和微服務來源於西方，而中臺誕生於中國的阿里巴巴。DDD已經出現了二十多年，中臺和微服務的理念近幾年纔出現，提出後就非常火爆。看似風馬牛不相及，實則緣分匪淺。中臺是抽象出來的業務模型，微服務是業務模型的系統實現，DDD 作爲方法論可以同時指導中臺業務建模和微服務建設。
DDD 有兩把利器，那就是它的戰略設計和戰術設計方法。
中臺更多偏向業務模型，形成過程是業務領域不斷細分的過程，過程中我們會將同類通用的業務能力進行聚合和業務重構，再根據限界上下文和業務內聚的原則建立領域模型。而 DDD 的戰略設計最擅長的就是領域建模。
在中臺完成領域建模後，就需要通過微服務來完成系統建設。此時，DDD 的戰術設計又恰好可以與微服務的設計完美結合。可以說，中臺和微服務正是 DDD 實戰的最佳場景。
DDD 的本質
在研究和解決業務問題時，DDD 會按照一定的規則將業務領域進行細分到一定的程度，然後將問題範圍限定在特定的邊界內，並在這個邊界內建立領域模型，進而用代碼實現該領域模型，解決相應的業務問題。領域可分解爲子域，子域可繼續分爲子子域，一直到你認爲適合建立領域模型爲止。子域還會根據自身重要性和功能屬性劃分爲三類子域，它們分別是核心域、支撐域和通用域。
上面這張圖，是保險的幾個重要領域，進行了高階的領域劃分。每個企業的領域定位和職責會有些不一樣，那在覈心域的劃分上肯定會有一定差異。因此，在做領域劃分的時候，請務必結合企業戰略，這恰恰也體現了 DDD 領域建模的重要性。通過領域劃分和進一步的子域劃分，就可以區分不同子域在企業內的功能屬性和重要性，進而採取不同的資源投入和建設策略，這在企業 IT 系統的建設過程中十分重要，並且這樣的劃分還可以幫助企業進行中臺設計。
中臺的本質
中臺來源於阿里的中臺戰略。作爲前臺的一線業務會更敏捷、更快速地適應瞬息萬變的市場，而中臺將集合整個集團的運營數據能力、產品技術能力，對各前臺業務形成強力支撐。
中臺的本質其實就是提煉各個業務板塊的共同需求，進行業務和系統抽象，形成通用的可複用的業務模型，打造成組件化產品，供前臺部門使用。前臺要做什麼業務，需要什麼資源，可以直接找中臺，不需要每次都去改動自己的底層。
DDD、中臺和微服務的協作模式
更多的企業還是會聚焦在傳統企業中臺建設的模式，也就是將通用能力與核心能力全部中臺化，以滿足不同渠道核心業務能力的複用。
可以將需要共享的公共能力進行領域建模，建設可共享的通用中臺。除此之外，還會將核心能力進行領域建模，建設面向不同渠道的可複用的核心中臺。而這裏的通用中臺和核心中臺都屬於業務中臺的範疇。
DDD 的子域分爲核心域、通用域和支撐域。劃分這幾個子域的主要目的是爲了確定戰略資源的投入，一般來說戰略投入的重點是核心域，因此後面我們就可以暫時不嚴格區分支撐域和通用域了。領域、中臺以及微服務雖然屬於不同層面的東西，但我們還是可以將他們分解對照，整理出來它們之間的關係。下面這張圖，從 DDD 領域建模和中臺建設這兩個不同的視角對同一個企業的業務架構進行分析。
如果將企業內整個業務域作爲一個問題域的話，企業內的所有業務就是一個領域。在進行領域細分時，從 DDD 視角來看，子域可分爲核心域、通用域和支撐域。從中臺建設的視角來看，業務域細分後的業務中臺，可分爲核心中臺和通用中臺。從領域功能屬性和重要性對照來看，通用中臺對應 DDD 的通用域和支撐域，核心中臺對應 DDD 的核心域。從領域的功能範圍來看，子域與中臺是一致的。領域模型所在的限界上下文對應微服務。建立了這個映射關係，我們就可以用 DDD 來進行中臺業務建模了。
這裏還是以保險領域爲例。保險域的業務中臺分爲兩類：第一類是提供保險核心業務能力的核心中臺（比如營銷、承保和理賠等業務）；第二類是支撐核心業務流程完成保險全流程的通用中臺（比如訂單、支付、客戶和用戶等）。根據 DDD 首先要建立通用語言的原則，在將 DDD 的方法引入中臺設計時，我們要先建立中臺和 DDD 的通用語言。這裏的子域與中臺是一致的，那我們就可以將子域統一爲中颱。
中臺通過事件風暴可以進一步細分，最終完成業務領域建模。中臺業務領域的功能不同，限界上下文的數量和大小就會不一樣，領域模型也會不一樣。
當完成業務建模後，就可以採用 DDD 戰術設計，設計出聚合、實體、領域事件、領域服務以及應用服務等領域對象，再利用分層架構模型完成微服務的設計。這就是 DDD、中臺和微服務在應用過程中的協作模式。
中臺如何建模？
中臺業務抽象的過程就是業務建模的過程，對應 DDD 的戰略設計。系統抽象的過程就是微服務的建設過程，中臺業務建模的過程：
第一步：按照業務流程（通常適用於核心域）或者功能屬性、集合（通常適用於通用域或支撐域），將業務域細分爲多箇中臺，再根據功能屬性或重要性歸類到核心中臺或通用中臺。核心中臺設計時要考慮核心競爭力，通用中臺要站在企業高度考慮共享和複用能力。
第二步：選取中臺，根據用例、業務場景或用戶旅程完成事件風暴，找出實體、聚合和限界上下文。依次進行領域分解，建立領域模型。由於不同中臺獨立建模，某些領域對象或功能可能會重複出現在其它領域模型中，也有可能本該是同一個聚合的領域對象或功能，卻分散在其它的中臺裏，這樣會導致領域模型不完整或者業務不內聚。這裏先不要着急，這一步我們只需要初步確定主領域模型就可以了，在第三步中我們還會提煉並重組這些領域對象。
第三步：以主領域模型爲基礎，掃描其它中臺領域模型，檢查並確定是否存在重複或者需要重組的領域對象、功能，提煉並重構主領域模型，完成最終的領域模型設計。
第四步：選擇其它主領域模型重複第三步，直到所有主領域模型完成比對和重構。
第五步：基於領域模型完成微服務設計，完成系統落地。
上面這張圖，DDD 戰略設計包括上述的第一步到第四步，主要爲：業務域分解爲中颱，對中臺歸類，完成領域建模，建立中臺業務模型。DDD 戰術設計是第五步，領域模型映射爲微服務，完成中臺建設。
如果還是以保險領域爲例的話，完成領域建模後，裏面的數據就可以填上了。以通用中臺的用戶、客戶和訂單三個中臺來做示例。客戶中臺提煉出了兩個領域模型：客戶信息和客戶視圖模型。用戶中臺提煉出了三個領域模型：用戶管理、登錄認證和權限模型。訂單中臺提煉出了訂單模型。
這就是中臺建模的全流程，當然看似簡單的背後，若是遇上覆雜的業務總會出現各種各樣的問題，不然應用起來也不會有那麼多的困難。
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
問題總結
課程鏈接：https://time.geekbang.org/column/article/161888
問題 1：有關於領域可以劃分爲核心域、通用域和支撐域，以及子域和限界上下文關係的話題，還有是否有邊界劃分的量化標準？
在領域不斷劃分的過程中，領域會被細分爲不同的子域，這個過程實際上是將問題範圍不斷縮小的過程。
“對於領域問題來說，可以理解爲，對一個問題不斷地劃分，直到劃分爲我們熟悉的、能夠快速處理的小問題。然後再對小問題的處理排列一個優先級。”
在領域細分到一定的範圍後，就可以對這個子域進行事件風暴，爲這個子域劃分限界上下文，建立領域模型，然後就可以基於領域模型進行微服務設計了。
雖然 DDD 沒有明確說明子域和限界上下文的關係。子域的劃分是一種比較粗的領域邊界的劃分，它不考慮子域內的領域對象、對象之間的關係和結構。子域的劃分往往按照業務階段或者功能模塊邊界進行粗分，其目的就是爲了能夠在一個相對較小的問題空間內，比較方便地用事件風暴來梳理業務場景。
而限界上下文本質上也是子域，限界上下文是在明確的子域內，用事件風暴劃分出來的。它體現的是一種詳細的設計過程。這個過程設計出了領域模型，明確了領域對象以及領域對象的依賴等關係，有了領域模型，就可以直接進行微服務設計了。
關於核心域、通用域和支撐域，劃分這三個不同類型子域的主要目的是爲了區分業務域的優先級，確定 IT 戰略投入。將重要的資源投入在覈心域上，確保好鋼用在刀刃上。每個企業由於商業模式或者戰略方向不一樣，核心域會有一些差異，不要用固定的眼光看待不同企業的核心域。
核心域、通用域和支撐域都是業務領域，只不過重要性和功能屬性不一樣。採用的 DDD 設計方法和過程，是沒有差異的。
從目前來看，還沒有可以量化的領域以及限界上下文的劃分標準。它主要依賴領域專家經驗，以及和項目團隊在事件風暴過程中不斷地權衡和分析。不要奢望一次迭代就能夠給複雜的業務，建立一個完美的領域模型。領域模型很多時候也需要多次迭代才能成型，它也需要不斷地演進。但如果是用 DDD 設計出來的領域模型的邊界和微服務內聚合的邊界非常清晰的話，這個演進過程相對來說會簡單很多，所需的時間成本也會很低。
問題 2：關於聚合設計的問題？領域層與基礎層爲什麼要依賴倒置（DIP）？
聚合主要實現核心業務邏輯，裏面有很多的領域對象，這些領域對象之間需要通過聚合根進行統一的管理，以確保數據的一致性。
在聚合設計時，我們會用到兩個重要的設計模式：工廠（Factory）模式和倉儲（Repository）模式。推薦閱讀《實現領域驅動設計》一書的第 11 章和第 12 章。
爲什麼要引入工廠模式呢？因爲有些聚合內可能含有非常多的實體和值對象，需要確保聚合根以及所有被依賴的對象實例同時被創建。如果都通過聚合根來構造，將會非常複雜。因此可以通過工廠模式來封裝複雜對象的創建過程，但並不是所有對象的構造都需要用到工廠，如果構造過程不復雜，只是單一對象的構造，用簡單的構造方法就足夠了。
又爲什麼要引入倉儲模式？解答這個問題的同時，也一起將依賴倒置的問題解答一下。在傳統的 DDD 四層架構中，所有層都是依賴基礎層的。這樣做有什麼不好的地方呢？如果應用邏輯對基礎層依賴太大的話，基礎層中與資源有關的代碼可能會滲透到應用邏輯中。而現在技術組件的更新頻率是很快的，一旦出現基礎組件的變更，且基礎組件的代碼被帶入到了應用邏輯中，這樣會對上層的應用邏輯產生致命的影響。
爲了解耦應用邏輯和基礎資源，在基礎層和上層應用邏輯之間會增加一層，這一層就是倉儲層。一個聚合對應一個倉儲，倉儲實現聚合內數據的持久化。聚合內的應用邏輯通過接口來訪問基礎資源，倉儲實現在基礎層實現。這樣應用邏輯和基礎資源的實現邏輯是分離的。如果變更基礎資源組件，只需要替換倉儲實現就可以了，不會對應用邏輯產生太大的影響，這樣就實現了應用邏輯與基礎資源的解耦，也就實現了依賴倒置。
關於聚合設計過程中的一些原則問題。大部分的業務場景都可以通過事件風暴，找到聚合根，建立聚合，劃分限界上下文，建立領域模型。但也有部分場景，比如數據計算、統計以及批處理業務場景，所有的實體都是獨立無關聯的，找不到聚合根，也無法建立領域模型。但是它們之間的業務關係是非常緊密的，在業務上是高內聚的。也可以將這類場景作爲一個聚合處理，除了不考慮聚合根的設計方法外，其它諸如 DDD 分層架構相關的設計方法都是可以採用的。
一些業務場景，如果複雜度並不高，而用 DDD 設計會帶來不必要的麻煩的話，比如增加複雜度，有些原則也是可以突破的，不要爲做 DDD 而做 DDD。即使採用傳統的方式也是沒有關係的，最終以解決實際問題爲最佳。但必須記住一點，如果採用傳統的設計方式，一定要保證領域模型的邊界以及微服務內聚合的邏輯邊界清晰，這樣的話，以後微服務的演進就不會太複雜。
問題 3：領域事件採用消息異步機制，發佈方和訂閱方數據如何保證一致性？微服務內聚合之間領域事件是否一定要用事件總線？
在領域事件設計中，爲了解耦微服務，微服務之間數據採用最終一致性原則。由於發佈方是在消息總線發佈消息以後，並不關心數據是否送達，或者送達後訂閱方是否正常處理，因此有些技術人會擔心發佈方和訂閱方數據一致性的問題。
在對數據一致性要求比較高的業務場景，是有相關的設計考慮的。也就是發送方和訂閱方的事件數據都必須落庫，發送方除了保存業務數據以外，在往消息中間件發佈消息之前，會先將要發佈的消息寫入本地庫。而接收方在處理消息之前，需要先將收到的消息寫入本地庫。然後可以採用定期對發佈方和訂閱方的事件數據對賬的操作，識別出不一致的數據。如果數據出現異常或不一致的情況，可以啓動定時程序再次發送，必要時可以轉人工操作處理。
關於事件總線的問題。由於微服務內的邏輯都在一個進程內，後端數據庫也是一個，微服務內的事務相比微服務之間會好控制一些。在處理微服務內的領域事件時，如果引入事件總線，會增加開發的複雜度，那是否引入事件總線，需要權衡。
如果你的場景中，不會出現導致聚合之間數據不一致的情況，就可以不使用事件總線。另外，通過應用服務也可以實現聚合之間的服務和數據協調。