編輯導(dǎo)語：上篇文章中作者詳細介紹了《什么是中臺》，2016年阿里提出的“大中臺小前臺”戰(zhàn)略后，很多企業(yè)開始想搭建中臺；本文作者詳細介紹了中臺的定義及在“中臺”建設(shè)方面的經(jīng)驗和方案，我們一起來看一下。

《中臺詳解系列》共分上下兩篇，本文為下篇，總計約12000字，因為文中涉及知識體系較為廣泛，建議預(yù)留30-50分鐘進行閱讀。

目前市場僅對“中臺”和“平臺”間的繼承和發(fā)展關(guān)系有一定共識，“中臺”的定義及建設(shè)規(guī)范尚未有明確定論。

本系列文章旨在基于“以終為始”的思維模式，及“軟件對現(xiàn)實世界建?！钡幕A(chǔ)條件，梳理傳統(tǒng)軟件“平臺”所面臨的問題；并以此為起點，結(jié)合經(jīng)濟學(xué)中專業(yè)化分工協(xié)作理論，為“中臺”進行職能定義，再通過“中臺”的職能定義給出“中臺”建設(shè)的建議方案。

阿里云在提出“中臺”戰(zhàn)略后，僅在一定程度上給出了“數(shù)據(jù)中臺”的建設(shè)規(guī)范，同時市面上關(guān)于“中臺”的介紹性文章也都避而不談“中臺”的落地方案，想是仍未統(tǒng)一。

本文中，我將主要介紹基于我個人對于“中臺”的定義及在“中臺”建設(shè)方面的經(jīng)驗，總結(jié)得出的“中臺”總體建設(shè)建議方案；不過因為篇幅原因可能不會過于細致，也不會探討“業(yè)務(wù)中臺”、“數(shù)據(jù)中臺”、“技術(shù)中臺”在細節(jié)上的差別。

相關(guān)內(nèi)容主要包括以下幾個章節(jié)：

• 如何劃分“中臺”
• “中臺”領(lǐng)域內(nèi)建模要點
• “中臺”數(shù)據(jù)治理方案
• “中臺”模塊間建設(shè)順序
• “中臺”對外服務(wù)要點
• “中臺”迭代要點
• “中臺”對組織架構(gòu)及其協(xié)作關(guān)系的影響

一、如何劃分“中臺”

要做“中臺”，首先自然就是得梳理清楚可以有哪些“中臺”。

1. 原理說明

我對于“中臺”的劃分方法是基于“以終為始”的原則及我個人對“中臺”的定義總結(jié)的，其細則如下：

“中臺”需要通過專業(yè)化分工來解決“軟件平臺間職能邊界劃分問題”，專業(yè)化分工的本質(zhì)是一種分類規(guī)則，要想分類我們就先得梳理自己有哪些業(yè)務(wù)功能以及要做哪些業(yè)務(wù)功能。

所有的軟件及其背后的理論、原理、概念、技術(shù)都是為了解決業(yè)務(wù)問題而產(chǎn)生的，所以在梳理“自己有哪些業(yè)務(wù)功能以及要做哪些業(yè)務(wù)功能”之前，需要先梳理清楚業(yè)務(wù)目標，這可以幫助我們評估業(yè)務(wù)功能梳理及其他工作的合理性。

“軟件平臺”的專業(yè)化職能分工所需采用的“能力專業(yè)化”的原則，有著“多同一不”的特點（上篇文章有說明），所以建議提煉業(yè)務(wù)功能中的實體作為后續(xù)業(yè)務(wù)功能“分類”的“錨點”；將業(yè)務(wù)功能轉(zhuǎn)化為類圖等直觀可視的靜態(tài)模型，可以有效降低思維難度。

“中臺”的構(gòu)建需要在企業(yè)層面拉通。

2. 方法選擇：領(lǐng)域驅(qū)動設(shè)計

因為“中臺”背負著解決“軟件平臺間職能邊界劃分問題”的使命，從這個角度出發(fā)，我認為最適合應(yīng)用于“中臺”職能邊界梳理的方法是“領(lǐng)域驅(qū)動設(shè)計”；因為從“領(lǐng)域”這倆字就可以看出來，“領(lǐng)域驅(qū)動設(shè)計”是為定義職能邊界而生的。

不過目前“領(lǐng)域驅(qū)動設(shè)計”的落地實施方案是由技術(shù)人員總結(jié)的，主要應(yīng)用于某個既定領(lǐng)域內(nèi)的建模，如果我們直接用來進行“中臺”的“專業(yè)化分工”和“數(shù)據(jù)唯一性建?！笨赡懿惶?。

所以針對“中臺”的目標特征，我這里借助“領(lǐng)域驅(qū)動設(shè)計”思想，魔改了一套經(jīng)驗證可行的方案，大家可以簡單了解一下。（由于“領(lǐng)域驅(qū)動設(shè)計”是基于面向?qū)ο笏枷胙苌鰜淼囊环N建模方法，如果對于面向?qū)ο蟛惶煜?，可能不太看得懂，所以如果實在看不懂建議先跳過本段。）

3. 人員分工：產(chǎn)品經(jīng)理主導(dǎo)

基于前文的分析，“平臺”間的職能邊界劃分需要遵循專業(yè)化分工原則，所以建議增設(shè)“業(yè)務(wù)架構(gòu)師”崗主導(dǎo)相關(guān)工作；除技術(shù)“中臺”外，包括“業(yè)務(wù)中臺”、“數(shù)據(jù)中臺”的職能邊界劃分工作均由產(chǎn)品經(jīng)理擔(dān)任“業(yè)務(wù)架構(gòu)師”。

4. 操作方案

在用本方案進行“中臺”劃分時，我們大致需要經(jīng)過兩個階段，共計8個步驟：

第一階段：

第1-3步為第一個階段，是由“領(lǐng)域驅(qū)動設(shè)計”原落地方案中的“事件風(fēng)暴”環(huán)節(jié)演變而來；分別為“企業(yè)全量業(yè)務(wù)目標分解”、“企業(yè)全量業(yè)務(wù)功能風(fēng)暴”和“企業(yè)全量業(yè)務(wù)功能拓展”。

目標：梳理清楚“中臺”所需支持的業(yè)務(wù)功能邊界。

輸出物：企業(yè)全量業(yè)務(wù)功能藍圖（ER圖或類圖）。

具體流程：

第一步：企業(yè)全量業(yè)務(wù)目標分解。

1）在進行業(yè)務(wù)目標分解時需要優(yōu)先關(guān)心其在商業(yè)上的橫向拓展。

以下為我個人總結(jié)的幾個拓展點：

• 上下游業(yè)務(wù)拓展：比如犀牛制造和菜鳥物流之于淘寶 。
• 資源變現(xiàn)：比如滴滴搞外賣 。
• 數(shù)據(jù)變現(xiàn)：比如抖音、微信的用戶標簽等 。
• 流量變現(xiàn)：比如抖音、微信的引流服務(wù)等 。

2）具體到某個業(yè)務(wù)線、或體系下，業(yè)務(wù)功能都是通過解決一個一個小問題再最終解決小問題背后的大問題的，所以這里業(yè)務(wù)目標最好是采用金字塔模型來進行梳理。

以營銷體系為例：

• 營銷的最終目標是“賣更多的東西”，其子目標可以分為“讓更多人買東西”、“讓人買更多東西”；
• “讓更多人買東西”的子目標可以繼續(xù)分為“拉新”、“給用戶洗腦”、“推薦合適的商品”；“讓人買更多東西”的子目標可以繼續(xù)分為“給用戶洗腦”、“推薦合適的商品”；
• “給用戶洗腦”的子目標又可以繼續(xù)分為“提升品牌好感度”、“提升產(chǎn)品認知度”、“提升購物積極性”等……

雖然我們在“中臺”設(shè)計過程中，業(yè)務(wù)目標劃分的越細越好，不過業(yè)務(wù)子目標的分解也不是無限制的，最終狀態(tài)的子目標會有著鮮明的場景化特征，大致可以用以下模型表示。

比如：連鎖零售商總部營銷部門在“女性用戶”“非首次”情況下通過“ APP”購買“任意”商品時向其發(fā)放“肯德基10代金券”，以提高用戶通過APP下單的積極性 。

第二步：企業(yè)全量業(yè)務(wù)功能風(fēng)暴。

即對照“業(yè)務(wù)目標金字塔模型”對已有業(yè)務(wù)功能進行梳理，輸出已有全量業(yè)務(wù)功能版圖。

要求精確到實體，在操作本環(huán)節(jié)時，以下幾點需要注意：

前文說明“數(shù)據(jù)孤島”問題時提到過關(guān)系數(shù)據(jù)的重要性，所以在進行已有全量業(yè)務(wù)功能版圖梳理時，關(guān)系型實體或字段務(wù)必要梳理清楚，不能遺漏，比如訂單觸發(fā)積分發(fā)放的記錄等。

一般來說因為缺乏專業(yè)化職能分工設(shè)計，業(yè)務(wù)系統(tǒng)中會出現(xiàn)大量以下類型的臨時方案：

• 人機交互型臨時方案：比如業(yè)務(wù)場景沒有定義好，在使用某服務(wù)時由人工錄入服務(wù)的使用場景 。
• 在代碼中埋數(shù)據(jù)的臨時方案：比如某店鋪的銀行卡信息直接寫死。
• 在進行業(yè)務(wù)功能風(fēng)暴時，此類臨時方案一定要還原成通用方案。

業(yè)務(wù)功能版圖示例，圖片來自網(wǎng)絡(luò)

第三步：企業(yè)全量業(yè)務(wù)功能拓展。

即對照“業(yè)務(wù)目標金字塔模型”，基于第二步中輸出的已有全量業(yè)務(wù)功能版圖，梳理未來還可能會有哪些業(yè)務(wù)功能；因為“中臺”在應(yīng)用時處于底層，會被很多上層業(yè)務(wù)系統(tǒng)集成，如果“中臺”沒有做好前瞻性設(shè)計，后續(xù)迭代風(fēng)險會比較大。

以下為我個人總結(jié)的幾種拓展點：

業(yè)務(wù)功能細化拓展：在數(shù)據(jù)層面表現(xiàn)為字段取值范圍的增加，比如客戶類型的枚舉值從“個人客戶”增加到“個人客戶、機構(gòu)客戶”，即表示目標客戶從個人客戶拓展到了機構(gòu)客戶。

另外拋開約束性校驗和界面交互，所以軟件的底層功能有且僅有對某實體某字段的增刪改查，即每個實體天然有“字段數(shù)量*增刪改查”個功能。

業(yè)務(wù)功能閉環(huán)性拓展：這一項主要是基于面向?qū)ο笾械慕M合思想進行的拓展，即解決某一問題時可能需要多個功能組合完成，我們據(jù)此判斷缺失了哪個功能；比如要達成用戶激勵，光有積分發(fā)放是不行的，還得需要積分消費功能。

業(yè)務(wù)功能依賴/約束性拓展：在數(shù)據(jù)層面表現(xiàn)為實體字段的增刪改查需要從外部數(shù)據(jù)源取數(shù)或?qū)ν獠繑?shù)據(jù)源進行校驗；比如物流單中商品信息就需要從商品模塊獲取，用戶下單時需要對商品庫存數(shù)量進行校驗 。

業(yè)務(wù)功能支撐性拓展：即為了讓業(yè)務(wù)更好的開展而進行的業(yè)務(wù)功能拓展；比如為了提高打開某文章的概率，我們會開發(fā)閱讀指定文章送積分的功能。

業(yè)務(wù)功能縱向拓展：在數(shù)據(jù)層面表現(xiàn)為對實體及其屬性、方法、實體間關(guān)系進行定義；比如設(shè)置積分的面值，進行用戶操作權(quán)限授權(quán)等。

業(yè)務(wù)功能解耦分化型拓展：在數(shù)據(jù)層面表現(xiàn)為實體的拆分；比如有些車企自建的整車商城，包含汽車交易及汽車物權(quán)管理兩條業(yè)務(wù)線，為了保障業(yè)務(wù)靈活度，最好就是將整車交易單拆分為商品交易單和物權(quán)轉(zhuǎn)讓單。

經(jīng)過上面一番猛如虎的操作后，正常來說我們應(yīng)該可以得到一張比較全面的業(yè)務(wù)功能藍圖（ER圖或類圖），接下來我們將進入第二個階段，開始“中臺”的劃分工作。

第二階段：

第4-8步為第二個階段，是基于“領(lǐng)域驅(qū)動設(shè)計”原落地方案中的“聚合”概念拓展而來。分別為“關(guān)鍵屬性定義”、“實體抽象合并”、“可復(fù)用業(yè)務(wù)定義”、“中臺邊界劃分”和“中臺邊界修正”。

目標：進行“中臺”的專業(yè)化職能模塊劃分，并調(diào)優(yōu)。

輸出物：“中臺”產(chǎn)品架構(gòu)圖。

具體流程：

第四步：關(guān)鍵屬性定義。

每個業(yè)務(wù)都有很多附加功能，這使得這些業(yè)務(wù)對應(yīng)的實體會有很多屬性，但實際上每個實體都僅有少量的幾個關(guān)鍵屬性定義了“它是它”。

實體的屬性過多會對實體間的關(guān)系整理形成干擾，所以我們需要找出每個實體的關(guān)鍵屬性。

關(guān)于什么是核心屬性，我這里舉幾個例子：

• 商品的核心屬性：價格，關(guān)聯(lián)物品或產(chǎn)品編碼 。
• 權(quán)益的核心屬性：標的物、抵扣規(guī)則及面值 。
• 訂單的核心屬性：買賣雙方、交易額、交易商品、成交數(shù)量、成交單價 。

第五步：實體抽象合并。

按照“多同一不”（上篇文章有說明）原則，我們需要根據(jù)某一個“模型、方法”是否服務(wù)于不同的“對象”來進行專業(yè)化分工；所以需要把相關(guān)實體進行抽象合并，保障各類實體的唯一性；因為我們在第四步“關(guān)鍵屬性定義”中找到了各實體的關(guān)鍵屬性，這一步就相對容易。

這個環(huán)節(jié)有一點需要注意：因為缺乏規(guī)范，可能明明相同的實體，但關(guān)鍵屬性的命名卻完全不一樣，這可能導(dǎo)致將其分成了兩個實體，所以在對實體關(guān)鍵屬性定義時需要多檢查幾遍。

第六步：可復(fù)用業(yè)務(wù)定義。

接下來，我們需要基于“多同一不”（上篇文章有說明）的原則找到那些服務(wù)不同對象的“模型、方法”，這是專業(yè)化分工的基礎(chǔ)。

這里還是舉個例子，比如“權(quán)益發(fā)放”即為服務(wù)不同對象的“模型、方法”。

“權(quán)益發(fā)放”作為服務(wù)不同對象的“模型、方法”在業(yè)務(wù)上表現(xiàn)為：權(quán)益發(fā)放可以應(yīng)用于包括用戶注冊、用戶簽到、用戶下單等多個業(yè)務(wù)，所以即為服務(wù)不同對象的“模型、方法”。

“權(quán)益發(fā)放”作為服務(wù)不同對象的“模型、方法”在數(shù)據(jù)上表現(xiàn)為：

情況1：實體：用戶注冊記錄（如果有的話）、用戶簽到記錄（如果有的話）、用戶訂單（如果有的話）都冗余了權(quán)益發(fā)放數(shù)量信息 。

情況2：實體：用戶注冊記錄（如果有的話）、用戶簽到記錄（如果有的話）、用戶訂單（如果有的話）都冗余了權(quán)益發(fā)放規(guī)則信息，而權(quán)益發(fā)放規(guī)則冗余了積分發(fā)放數(shù)量信息 。

第七步：“中臺”邊界劃分。

接下來，我們就可以正式進行“中臺”邊界的劃分了。

首先，我們需要將第六步“核心業(yè)務(wù)定義”環(huán)節(jié)找到的服務(wù)不同對象的“模型、方法”，與其服務(wù)對象分開；比如權(quán)益發(fā)放因為可以同時服務(wù)用戶注冊、用戶簽到、用戶下單等，所以其需要與后三者分開。

然后我們在通過實體關(guān)鍵屬性所表現(xiàn)出關(guān)聯(lián)關(guān)系進行組合，比如：

• 物流單的核心屬性：物品、數(shù)量、取貨地址、收貨地址 。
• 訂單的核心屬性：買賣雙方、交易額及交易商品 。
• 權(quán)益賬戶：所屬用戶、所屬權(quán)益、權(quán)益余額 。
• 權(quán)益發(fā)放流水：流水類型（發(fā)放）、支出權(quán)益賬戶、收入權(quán)益賬戶、所屬權(quán)益、流轉(zhuǎn)權(quán)益數(shù)量 。

我們可以看出，物流單和訂單基于核心屬性是沒有直接聯(lián)系的，所以我們不會輕易將它們放到一個“中臺”業(yè)務(wù)域中；而積分賬戶和積分發(fā)放流水基于核心屬性是有直接聯(lián)系的，所以我們會將他們放到一個“中臺”業(yè)務(wù)域中。

需要注意的是，因為“中臺”強調(diào)專業(yè)化職能分工，就像企業(yè)員工在實施某項目時，協(xié)作的各工種之間有很多銜接環(huán)節(jié)一樣，在實際開展業(yè)務(wù)過程中，“中臺”功能間也需要很多銜接性功能才能夠真正支持業(yè)務(wù)。

一般來說，為了避免影響業(yè)務(wù)職能的完整性，不建議將這些銜接性功能強行劃分到某個“中臺”業(yè)務(wù)域中；實在不行，建議單獨抽象一個“業(yè)務(wù)流程編排/管理中臺”來統(tǒng)一行使功能銜接的職能。

第八步：“中臺”邊界修正。

第一，我們不排除有“基于關(guān)鍵屬性是沒有直接聯(lián)系的兩個實體”需要劃分到同一個“中臺”業(yè)務(wù)域中的可能，比如，有企業(yè)因為商品和訂單在業(yè)務(wù)上緊密的關(guān)系而將兩者劃歸為交易中臺；

第二，也不排除有“基于關(guān)鍵屬性是有直接聯(lián)系的兩個實體”需要劃分到不同“中臺”業(yè)務(wù)域中的可能。比如，很多軟件供應(yīng)商會因為部署需要，把權(quán)益中心在拆分為會員卡中心、積分中心、卡券中心等；

第三，會有一些業(yè)務(wù)特征不明顯的功能是跨領(lǐng)域的，這種功能實際上可以抽象提取出來作為一個獨立的“中臺”板塊，比如基于用戶行為發(fā)卡券、積分、短信的功能可抽象為事件營銷中臺。

所以在“中臺”邊界劃分完成后，我們還需根據(jù)實際情況進行微調(diào)。

經(jīng)過驗證，只要按照以上步驟執(zhí)行，就可以梳理出相對理想的“中臺”結(jié)構(gòu)。不過“中臺”劃分原則的細節(jié)還有很多可聊，這些內(nèi)容我后面也都會單獨寫專題文章介紹。這里就不贅述了。

二、“中臺”領(lǐng)域內(nèi)建模要點

鑒于“中臺”背負著解決“軟件平臺的職能邊界問題”的使命，其領(lǐng)域內(nèi)建模即包括業(yè)務(wù)建模和技術(shù)建模兩個方面：

1. 業(yè)務(wù)建模

這一塊的工作可以進一步細分為“功能拓展”和“業(yè)務(wù)字段定義”兩塊工作，同樣建議由產(chǎn)品經(jīng)理作為“業(yè)務(wù)架構(gòu)師”承擔(dān)。

1）功能拓展

主體步驟跟“中臺劃分原則”中“第一步”階段的差不多，主要還是基于業(yè)務(wù)目標和“領(lǐng)域驅(qū)動設(shè)計”思想對已有實體和功能進行各種形式的拓展，這里也就不重復(fù)說明了。

僅強調(diào)以下要點：

在“中臺”的業(yè)務(wù)建模過程中，如果發(fā)現(xiàn)某個“中臺”業(yè)務(wù)域?qū)δ承┩獠繑?shù)據(jù)有依賴，而相關(guān)數(shù)據(jù)源還沒有構(gòu)建完成；這時萬萬不可私自在當(dāng)前“中臺”業(yè)務(wù)域中定義相關(guān)數(shù)據(jù)，這會嚴重破壞業(yè)務(wù)完整性，所謂“中臺”的職能邊界劃分就無從談起了（此種情況的解決方案在下文“3.3.中臺數(shù)據(jù)治理”章節(jié)會給出）。

2）業(yè)務(wù)字段定義

由于“中臺”還承擔(dān)著解決“數(shù)據(jù)孤島”的使命，所以在進行“中臺”的業(yè)務(wù)建模時需要進行實體業(yè)務(wù)字段的定義。

這一部分我們重點聊一下：

除了核心屬性字段外，我們需要基于以下要點進行字段冗余：基于實體間的依賴關(guān)系進行字段冗余，比如“卡券僅可用于指定商品功能”，就要求“卡券”實體冗余可用“商品ID”字段 。

“中臺”是底層應(yīng)用，不會直接對用戶提供服務(wù)，都是上層業(yè)務(wù)系統(tǒng)按照一定邏輯順序調(diào)用“中臺”的接口來實現(xiàn)業(yè)務(wù)串聯(lián)的；而上層業(yè)務(wù)系統(tǒng)在調(diào)用中臺服務(wù)時是基于明確的業(yè)務(wù)場景的，為了滿足后續(xù)數(shù)據(jù)分析、生產(chǎn)問題定位等目標，上層業(yè)務(wù)系統(tǒng)調(diào)用“中臺”服務(wù)時需要入?yún)⑾嚓P(guān)服務(wù)調(diào)用的具體應(yīng)用場景，而“中臺”建模時也需要考慮相關(guān)數(shù)據(jù)的存儲。

比如某APP后臺調(diào)用積分中心、卡券中心進行積分或卡券的發(fā)放時都需要入?yún)⑶繧D、業(yè)務(wù)終端ID、操作人ID、業(yè)務(wù)ID（如訂單這一業(yè)務(wù)的ID）、業(yè)務(wù)流水號（如具體某一筆訂單的ID）、后臺發(fā)放還是用戶行為觸發(fā)等，后續(xù)就可以用這些信息進行營銷成本分析了。

為了便于拓展，實體業(yè)務(wù)字段的定義盡可能做到全解耦，即字段名稱不要有任何定語；字段耦合的重災(zāi)區(qū)是各種“類型”，比如“流水類型”，有很多人會設(shè)計為“系統(tǒng)發(fā)放”、“人工發(fā)放”、“系統(tǒng)核銷”、“人工核銷”，就建議拆分成“流水類型”和“操作方式”兩個字段。

因為業(yè)務(wù)字段直接決定了“中臺”間的專業(yè)化職能分工關(guān)系，所以定義字段時，還要定義字段數(shù)據(jù)來源及枚舉 。

3）特別提醒

上篇文章在介紹“數(shù)據(jù)孤島”問題時提到過關(guān)系數(shù)據(jù)的重要性，所以在進行“中臺”“領(lǐng)域內(nèi)”的業(yè)務(wù)建模時，需要基于全量業(yè)務(wù)功能藍圖，充分考慮到關(guān)系型實體或字段的定義需求。

2. 技術(shù)建模

“領(lǐng)域驅(qū)動設(shè)計”有很明確的技術(shù)建模落地方案，在此我僅強調(diào)一下充血模型在“中臺”技術(shù)建模過程中的重要性，它可以有效保障系統(tǒng)的可拓展性。

舉個例子：

支付清結(jié)算業(yè)務(wù)中涉及多方分賬，多方分賬包括“指令分賬”和“自動分賬”兩種情況。

如果我們將“支付”、“分賬”分別作為一個事務(wù)進行封裝，等我們需要修改“指令分賬”功能時整個流程就阻塞了。

如果我們將“支付——指令分賬”、“支付——自動分賬”分別作為一個事務(wù)進行封裝，等我們需要修改“指令分賬”功能時“支付——自動分賬”這條流程將不會收到影響。

三、“中臺”數(shù)據(jù)治理方案

1. 數(shù)據(jù)依賴性治理

“中臺”的劃分遵循“多同一不”的原則，而各個“中臺”業(yè)務(wù)域中的實體本身也可能作為業(yè)務(wù)對象存在的，所以在“中臺”的業(yè)務(wù)建模過程中，可能出現(xiàn)某些“中臺”業(yè)務(wù)域之間有數(shù)據(jù)依賴關(guān)系的情況。

為了保障各個中臺業(yè)務(wù)域的獨立性，建議采用“主數(shù)據(jù)”管理平臺對中臺間的數(shù)據(jù)依賴關(guān)系進行解耦處理。

具體方案為：構(gòu)建主數(shù)據(jù)管理平臺，提供主數(shù)據(jù)寫入接口；梳理領(lǐng)域間的數(shù)據(jù)依賴關(guān)系，并在主數(shù)據(jù)管理平臺進行需要在多領(lǐng)域共享的數(shù)據(jù)實體定義 。

可通過“中臺”基礎(chǔ)信息維護的前端直接調(diào)用主數(shù)據(jù)寫入接口進行相關(guān)主數(shù)據(jù)的寫入，或通過主數(shù)據(jù)獨立寫入前端進行相關(guān)主數(shù)據(jù)的寫入 。

因為各有數(shù)據(jù)依賴需求的“中臺”業(yè)務(wù)域?qū)τ谥鲾?shù)據(jù)的數(shù)據(jù)依賴規(guī)則有所區(qū)別，所以在應(yīng)用時還需要根據(jù)實際數(shù)據(jù)依賴情況進行數(shù)據(jù)依賴需求注冊，從原始主數(shù)據(jù)中圈選依賴的數(shù)據(jù)；比如在主數(shù)據(jù)中“活動”和“商品”是兩個實體，卡券的可用對象需要包含“活動”和“商品”，就可以通過這種方式把“活動”和“活動”打包應(yīng)用。

此處是采用面向?qū)ο蟊硎緲I(yè)務(wù)結(jié)構(gòu)，不代表技術(shù)方案

這樣做有兩點好處：

• 在進行“中臺”研發(fā)時各個模塊之間不需要點對點進行對接聯(lián)調(diào)，都只需要對接主數(shù)據(jù)，大大降低研發(fā)難度 。
• 因為有主數(shù)據(jù)的存在，即便被依賴的數(shù)據(jù)源暫未構(gòu)建完成，我們也可以通過數(shù)據(jù)庫預(yù)設(shè)、導(dǎo)入等方式維護相關(guān)主數(shù)據(jù) 。

2. 數(shù)據(jù)唯一性治理

我們在進行了“中臺”專業(yè)化職能分工后，相似業(yè)務(wù)的相似數(shù)據(jù)在職能上的唯一性已經(jīng)有所保障；但因為“中臺”的本質(zhì)是模塊組件，模塊組件多數(shù)情況下是必須與其他模塊組件進行業(yè)務(wù)化串聯(lián)，甚至還要進行增量的個性化定制包裝，才能夠真正解決業(yè)務(wù)問題。

這時可能出現(xiàn)“中臺”業(yè)務(wù)域間、“中臺”和定制內(nèi)容間對于不同業(yè)務(wù)的數(shù)據(jù)字段命名一樣的情況，這雖然不會影響數(shù)據(jù)分析，但容易誤導(dǎo)研發(fā)，造成事故；所以建議采用“元數(shù)據(jù)”管理來規(guī)避這種風(fēng)險。

具體方案為：

• 構(gòu)建“元數(shù)據(jù)”管理平臺模塊，提供“元數(shù)據(jù)”查詢接口及監(jiān)察插件 。
• 各“中臺”業(yè)務(wù)域及對接“中臺”服務(wù)的業(yè)務(wù)系統(tǒng)在進行模型構(gòu)建時，可以根據(jù)業(yè)務(wù)依賴關(guān)系查詢元數(shù)據(jù)，并選擇綁定。
• 如果需要新增“元數(shù)據(jù)”則元數(shù)據(jù)管理平臺會通過插件進行“元數(shù)據(jù)”唯一性校驗；校驗不通過則預(yù)警，校驗通過且正式使用相關(guān)“元數(shù)據(jù)”后，元數(shù)據(jù)管理平臺即自動進行相關(guān)“元數(shù)據(jù)”的注冊。

此處是采用面向?qū)ο蟊硎緲I(yè)務(wù)結(jié)構(gòu)，不代表技術(shù)方案

3. 數(shù)據(jù)一致性治理

由于種種原因，某“中臺”業(yè)務(wù)可能會依賴甚至冗余外源數(shù)據(jù)，如果外源數(shù)據(jù)發(fā)生變動，就會出現(xiàn)雙方數(shù)據(jù)不一致的情況；比如為了檢索更方便可能會在“積分中心”——“積分流水”中冗余用戶手機號信息，但用戶手機號是支持換綁的。

對于此類情況我們一般有4種處理方案：

• 僅冗余主鍵字段：比如積分賬戶中僅冗余用戶ID，前端展示時使用主鍵屬性前往數(shù)據(jù)源進行指定字段查詢；檢索時則使用指定字段前往數(shù)據(jù)源查詢主鍵屬性，再用主鍵屬性去查詢當(dāng)前模塊數(shù)據(jù)。因為主鍵字段不會改變，所以自然就不會出現(xiàn)上述問題。
• 冗余數(shù)據(jù)不做增量修改：比如積分發(fā)放流水冗余了用戶手機號，我們可以理解積分發(fā)放流水為積分發(fā)放那一刻的憑證，后續(xù)就算用戶手機號變了，而積分發(fā)放那一刻的手機號是沒變的。
• 冗余數(shù)據(jù)在數(shù)據(jù)源變動后實時同步，這個難度比較大。
• 冗余數(shù)據(jù)在數(shù)據(jù)源變動后采用定時任務(wù)同步。

另外，為了便于后續(xù)進行數(shù)據(jù)核對，還建議所有的數(shù)據(jù)維護所有數(shù)據(jù)的修改記錄及歷史版本。

在實際操作中，我們需要對“中臺”業(yè)務(wù)域內(nèi)的業(yè)務(wù)細節(jié)進行全面排查，具體情況具體分析，分別選取上述不同的解決方案。

四、“中臺”模塊間的建設(shè)順序

“中臺”的建設(shè)是有順序的，這個順序主要基于依賴性原則，即被依賴的實體、功能先做；在“中臺”劃分時，我們幾乎不可能把所有具備依賴關(guān)系的實體、功能劃分到同一個“中臺”業(yè)務(wù)域中。

鑒于除了關(guān)系型實體有著明確的依賴對象外，依賴關(guān)系并沒有什么特別的規(guī)律，所以我建議是在進行“中臺”劃分時就需要把各“中臺”間的依賴關(guān)系理清楚。

以我目前的實踐經(jīng)驗來看，包含以下實體的“中臺”業(yè)務(wù)域需要優(yōu)先搭建：

• 業(yè)務(wù)基礎(chǔ)實體：組織機構(gòu)信息、客戶、賬戶、商品等；絕大部分企業(yè)的最核心業(yè)務(wù)都是交易，交易最核心依賴的就是這些數(shù)據(jù) 。
• 數(shù)據(jù)分析關(guān)鍵實體：業(yè)務(wù)場景、渠道、終端、頁面、點位等；業(yè)務(wù)分析最核心的就是找出最有效的上述信息。

五、“中臺”對外服務(wù)要點

1. 對外接口字段標準化

1）通用標準字段定義：

上文有提到，“中臺”是底層應(yīng)用，不會直接對用戶提供服務(wù)，“中臺”的對外服務(wù)需要記錄應(yīng)用場景信息。

這一情況在“中臺”各業(yè)務(wù)域中都是普遍存在的，所以所有“中臺”對外暴露的接口中都應(yīng)該冗余這些通用字段；當(dāng)然，我們也可以根據(jù)具體企業(yè)的業(yè)務(wù)需要定義其他通用字段。

2）業(yè)務(wù)標準字段定義：

這里的業(yè)務(wù)標準字段主要是根據(jù)“充血模型”的建模需求定義的，比如積分發(fā)放接口，基于貧血模型定義的接口可能如下：

• 通過積分發(fā)放賬戶關(guān)聯(lián)B端用戶ID來找到積分發(fā)放賬戶，再進行積分發(fā)放。
• 使用積分發(fā)放賬戶進行積分發(fā)放。

過多的校驗環(huán)節(jié)可能帶來較大的錯誤風(fēng)險，所以建議改成“積分賬戶查詢”及“積分發(fā)放”等兩個接口，示例如下：

2. 服務(wù)組合

前文提到“中臺”之間可能存在數(shù)據(jù)依賴，這使得很多時候上層業(yè)務(wù)系統(tǒng)在調(diào)用某“中臺”接口時，需要先去被依賴的數(shù)據(jù)源取數(shù)，再回過頭來調(diào)用原先的接口。

這種情況無疑會大大增加“中臺”服務(wù)的理解難度，以及上層業(yè)務(wù)系統(tǒng)對接“中臺”服務(wù)的聯(lián)調(diào)工作量與出錯概率；針對這種情況，建議是拓展一個“中臺”服務(wù)組合層，通過這個組合層進行各“中臺”相互依賴的接口間的組合。

這樣做的好處有以下幾點：

• 可以保障領(lǐng)域?qū)臃?wù)的獨立性，保障充血模型的有效性。
• “中臺”服務(wù)還可集成中臺應(yīng)用服務(wù)網(wǎng)關(guān)的職能。

3. 對外服務(wù)應(yīng)用架構(gòu)

前文有多次強調(diào)過，“中臺”的本質(zhì)是模塊組件，模塊組件多數(shù)情況下是必須與其他模塊組件進行業(yè)務(wù)化串聯(lián)，甚至還要進行增量的個性化定制包裝，才能夠真正解決業(yè)務(wù)問題。

這里的“業(yè)務(wù)化串聯(lián)”及“個性化定制包裝”工作就需要單獨拓展一個“業(yè)務(wù)應(yīng)用層”來完成。

注意這個“業(yè)務(wù)應(yīng)用層”與“第二點”中的“中臺服務(wù)組合層”并不是一回事，服務(wù)組合層主要是基于接口間的依賴關(guān)系構(gòu)建的，而“業(yè)務(wù)應(yīng)用層”中需要串聯(lián)的業(yè)務(wù)之間不只存在依賴關(guān)系；比如前文“3.1.如何劃分中臺”中提到的業(yè)務(wù)之間的“支撐關(guān)系”。

這里舉個例子：抽獎活動的創(chuàng)建和卡券的創(chuàng)建之間并不存在必然的依賴關(guān)系，而在實際操作過程中，我們常常會在活動創(chuàng)建的過程中創(chuàng)建新的卡券，這就需要研發(fā)人員在“業(yè)務(wù)應(yīng)用層”進行邏輯編碼。

這里有2點需要說明：

1）“業(yè)務(wù)應(yīng)用層”的設(shè)計建議采用前文提到的經(jīng)濟學(xué)原理——專業(yè)化分工原則中的“對象專業(yè)化”原則，這里就當(dāng)開了個新坑，以后再專門寫一篇相關(guān)的文章，在本文中就暫不細聊了。

• 對象專業(yè)化：按照業(yè)務(wù)對象來劃分生產(chǎn)單位的原則，即按不同的業(yè)務(wù)對象，建立不同的生產(chǎn)單位。
• 特點：“多不一同”。多不——不同模型 、不同方法、相同服務(wù)等；一同——相同的業(yè)務(wù)對象。

2）我們常說的B端或者運營后臺一般就對應(yīng)著這個業(yè)務(wù)應(yīng)用層。所以從這個角度上來說，“中臺”相對所有業(yè)務(wù)系統(tǒng)來說都是更底層的，不存在文章一開始所說的“業(yè)務(wù)支撐后臺”概念。

六、“中臺”迭代要點

1. 常規(guī)版本迭代

通過前文“3.1.如何劃分中臺”，我們大致可以了解到“中臺”以下兩個特點：

• 前瞻性：這使得很多“中臺”功能可能暫時用不到；
• 規(guī)模大：這使得“中臺”很難一兩個版本直接搞定；

所以“中臺”的迭代是很正常。在“中臺”的常規(guī)版本迭代過程中，我們可以結(jié)合企業(yè)的業(yè)務(wù)發(fā)展路徑來進行各“中臺”業(yè)務(wù)域的PI計劃制定。

2. 重構(gòu)性迭代

雖然我們是基于專業(yè)化分工原則來劃分“中臺”職能，但以下兩點原因可能會造成中臺的重構(gòu)：

• “中臺”在進行職能劃分時需要使用“能力專業(yè)化”原則，其有“多同一不”的特點，而實際“多同”是可以有不知一種解讀的，比如原先我們將“權(quán)益賬戶”劃歸了“權(quán)益中心”，后續(xù)可能我們又會將其滑軌到“賬號賬戶中心”，其實這都有道理，關(guān)鍵是看與相關(guān)企業(yè)的業(yè)務(wù)匹配度。
• 因為一些特殊原因需要將中臺進行細化；比如我司會因為部署需要，把權(quán)益中心在拆分為會員卡中心、積分中心、卡券中心等。

理論上來說，以上兩種原因造成的“中臺”重構(gòu)都只是涉及到原有某一個或某幾個“中臺”，如果發(fā)現(xiàn)各“中臺”業(yè)務(wù)域都需要調(diào)整，那估計是一開始的“全量業(yè)務(wù)風(fēng)暴”和“全量業(yè)務(wù)拓展”沒做好，這就建議從頭再來一遍了。

七、“中臺”對企業(yè)組織架構(gòu)及其協(xié)作關(guān)系的影響

很多與“中臺”相關(guān)的文章和出版圖書中都提到了“中臺”對企業(yè)組織架構(gòu)的影響，其中不乏觀點認為“中臺”的本質(zhì)就是企業(yè)組織架構(gòu)的升級，這可以說是錯把結(jié)果當(dāng)原因了。

實際上“中臺”與企業(yè)組織架構(gòu)間的關(guān)系是這樣的：

就像“中臺”概念是用來協(xié)調(diào)“平臺”間職能分工、協(xié)作關(guān)系的一樣，組織機構(gòu)是用來協(xié)調(diào)“組織成員”間職能分工、協(xié)作關(guān)系的；而恰好“中臺”的應(yīng)用特性使得其需要專門的團隊維護，而新團隊的出現(xiàn)則帶來了新的“組織成員”間協(xié)作關(guān)系的構(gòu)建需求。

因為“中臺”繼承了“平臺”解決“重復(fù)造輪問題”，并拓展出了解決“數(shù)據(jù)孤島”問題的使命，所以中臺對于組織架構(gòu)的影響必然是企業(yè)級的。

不過一方面運營人員直接面對的是“業(yè)務(wù)應(yīng)用層”，另一方面各類數(shù)據(jù)也可以通過數(shù)據(jù)權(quán)限進行隔離，所以“中臺”的構(gòu)建不會對運營工作產(chǎn)生任何影響，這也很符合“中臺”的定義和使命；“中臺”的構(gòu)建主要影響的還是IT團隊。

1. 增設(shè)新的部門

“中臺”的構(gòu)建和運維工作有以下特點：

• 首先，“中臺”的研發(fā)工作將持續(xù)一個長周期，這期間工作密度較大；但如果一切正常，在這個階段后，相關(guān)研發(fā)工作就會急劇減少，除非需要進行某些“中臺”業(yè)務(wù)域的重構(gòu)；
• 其次，“中臺”構(gòu)建完成后，構(gòu)建各業(yè)務(wù)系統(tǒng)的IT團隊在對接“中臺”時，需要進行高強度的業(yè)務(wù)咨詢及技術(shù)咨詢；
• 最后，因為“中臺”雖然進行了“專業(yè)化分工”和“數(shù)據(jù)唯一性建?！?，所以在實際生產(chǎn)環(huán)境中，“中臺”承擔(dān)的并發(fā)量是各業(yè)務(wù)線相似業(yè)務(wù)的并發(fā)量之和，這使得“中臺”對于業(yè)務(wù)運維、應(yīng)用運維人員、技術(shù)運維及DBA的能力及響應(yīng)速度要求都高出一般的業(yè)務(wù)系統(tǒng)很多。

基于上述特點，我們建議需要圍繞“中臺”增設(shè)一個部門，這個部門及其人員配備應(yīng)具備以下特點：

• 為了保障中臺的獨立性，不會輕易被業(yè)務(wù)系統(tǒng)的需求所碾壓，該部門最好與業(yè)務(wù)系統(tǒng)的研發(fā)部門平行存在；
• 因為“中臺”構(gòu)建的工作量前重后輕，所以相關(guān)研發(fā)團隊建議是從原有業(yè)務(wù)系統(tǒng)研發(fā)部門抽調(diào)，待“中臺”研發(fā)工作取得階段性成果后，可以逐步釋放回原來的部門；這樣做的好處還有：因為相關(guān)研發(fā)團隊對原有業(yè)務(wù)系統(tǒng)比較熟悉，更能夠做好業(yè)務(wù)組合、關(guān)系實體構(gòu)建以及其他前瞻性設(shè)計；
• 因為“中臺”對于運維工作要求高，所以相關(guān)團隊建議單獨建立，可以招聘，可以抽調(diào)，但要穩(wěn)定；
• 相關(guān)業(yè)務(wù)架構(gòu)師、技術(shù)架構(gòu)師需要保持穩(wěn)定，以保持業(yè)務(wù)和技術(shù)理解的連續(xù)性。

構(gòu)建各業(yè)務(wù)系統(tǒng)的IT團隊在對接中臺時，在進行業(yè)務(wù)咨詢和技術(shù)咨詢時需要有專門的顧問解答，具體工作內(nèi)容在下方“研發(fā)及運維流程調(diào)整”章節(jié)有詳細描述。

2. 研發(fā)及運維流程調(diào)整

鑒于“中臺”的企業(yè)級使命，所以在新的部門成立后，以下工作要點需要注意：

• 是否需要接入“中臺”服務(wù)，不能由業(yè)務(wù)系統(tǒng)研發(fā)團隊自己說了算，需要由業(yè)務(wù)系統(tǒng)研發(fā)團隊派出“產(chǎn)品經(jīng)理”、“技術(shù)經(jīng)理”與“中臺”團隊的“業(yè)務(wù)咨詢顧問”及“技術(shù)咨詢顧問”共同商討決定；
• 無論某個業(yè)務(wù)系統(tǒng)最終是否接入了“中臺”服務(wù)，其模型及元數(shù)據(jù)必須上報“中臺”-“元數(shù)據(jù)管理平臺”，也必須遵循企業(yè)層面元數(shù)據(jù)唯一性原則；
• 因為“中臺”與業(yè)務(wù)系統(tǒng)間是“1對多”的關(guān)系，正常情況下如果“中臺”出了問題所有業(yè)務(wù)系統(tǒng)都會受到影響，所以在某個業(yè)務(wù)系統(tǒng)與“中臺”的銜接環(huán)節(jié)出現(xiàn)了問題后，需要先由業(yè)務(wù)系統(tǒng)相關(guān)運維團隊進行問題定位。

基于上述要點，我們建議業(yè)務(wù)系統(tǒng)研發(fā)流程大致如下：

業(yè)務(wù)系統(tǒng)研發(fā)流程：

• 業(yè)務(wù)系統(tǒng)研發(fā)團隊“產(chǎn)品經(jīng)理”、“技術(shù)經(jīng)理”深度學(xué)習(xí)“中臺”服務(wù)；
• 業(yè)務(wù)系統(tǒng)研發(fā)團隊“產(chǎn)品經(jīng)理”、“技術(shù)經(jīng)理”對自身業(yè)務(wù)及模型進行梳理，初步確定與“中臺”間的交互關(guān)系；
• 業(yè)務(wù)系統(tǒng)研發(fā)團隊“產(chǎn)品經(jīng)理”、“技術(shù)經(jīng)理”提交工單申請“中臺”服務(wù)咨詢，并與“中臺”團隊的“業(yè)務(wù)咨詢顧問”及“技術(shù)咨詢顧問”交流確認業(yè)務(wù)系統(tǒng)與“中臺”間的交互關(guān)系；
• 業(yè)務(wù)系統(tǒng)研發(fā)團隊“產(chǎn)品經(jīng)理”、“技術(shù)經(jīng)理”在得到“中臺”團隊的“業(yè)務(wù)咨詢顧問”及“技術(shù)咨詢顧問”確認后，申請接入“中臺”服務(wù)，并在通過后獲得相關(guān)接口文檔及其他必要材料/工具/網(wǎng)關(guān)授權(quán)等；
• 業(yè)務(wù)系統(tǒng)研發(fā)團隊在系統(tǒng)構(gòu)建過程中全程受“中臺”元數(shù)據(jù)管理平臺及業(yè)務(wù)編排監(jiān)控插件的監(jiān)控，以免出現(xiàn)數(shù)據(jù)“張冠李戴”等錯誤；

業(yè)務(wù)系統(tǒng)研發(fā)流程異常處理：

• 業(yè)務(wù)系統(tǒng)如涉及到“中臺”還在研發(fā)中的需求，可以在經(jīng)過高層審批后，酌情讓業(yè)務(wù)系統(tǒng)自身定制，但相關(guān)問題需要由負責(zé)的“業(yè)務(wù)咨詢顧問”及“技術(shù)咨詢顧問”記錄，并在后續(xù)“中臺”相關(guān)服務(wù)上線后立即進行服務(wù)切換及數(shù)據(jù)遷移；
• 一旦發(fā)現(xiàn)“元數(shù)據(jù)重復(fù)定義”及其他明令禁止的，會影響“中臺”職能定義及“數(shù)據(jù)歸一”的問題，即使相關(guān)模塊已上線，也需要立刻進行修正。

運維流程大致如下：

“中臺”內(nèi)部運維流程：

• 由“中臺”測試團隊每日匯總內(nèi)部問題，并根據(jù)問題嚴重性進行排期，嚴重問題需要當(dāng)日解決；
• 各“中臺”業(yè)務(wù)域按照測試的排期計劃進行相關(guān)修復(fù)工作。

缺陷型業(yè)務(wù)應(yīng)用生產(chǎn)問題運維流程：

• 問題發(fā)生后由業(yè)務(wù)系統(tǒng)運維團隊優(yōu)先定位問題，在排除業(yè)務(wù)系統(tǒng)問題后，向“中臺”運維團隊業(yè)務(wù)運維崗提交工單；
• 由“中臺”運維團隊的業(yè)務(wù)運維崗每日匯總?cè)毕菪蜆I(yè)務(wù)應(yīng)用生產(chǎn)問題，所有問題必須當(dāng)日定位，當(dāng)日解決；

需求性業(yè)務(wù)應(yīng)用生產(chǎn)問題運維流程：

• 由業(yè)務(wù)系統(tǒng)運維團隊提交需求性業(yè)務(wù)應(yīng)用生產(chǎn)問題工單至“中臺”運維團隊的應(yīng)用運維崗；
• “中臺”運維團隊的應(yīng)用運維崗對業(yè)務(wù)需求進行核實和確認，制定服務(wù)器內(nèi)存擴容等解決方案，并提交相關(guān)主管審核；
• 相關(guān)主管審核通過后即可以啟用相關(guān)解決方案；

在實際操作中，細節(jié)可能要比上述描述更加復(fù)雜，因為篇幅有限，暫且略過了。

八、寫在最后

至此，《中臺詳解系列》文章完結(jié)了，文中所載均是我個人一些微薄、淺顯的見識，“中臺”作為軟件建設(shè)的一個里程碑式概念（至少基于個人對“中臺”的定義我是這么認為的）有著太多內(nèi)容可以探討。

所以如有不同觀點，歡迎聯(lián)系作者進行交流，彼此促進，共同成長。

本文由 @阿魏 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議