建設(shè)中臺(tái)最直接的目的一般是為了幫助企業(yè)快速且低成本的創(chuàng)新，這就要求了中臺(tái)必須降低使用方的學(xué)習(xí)成本，能把各個(gè)業(yè)務(wù)進(jìn)行集中管理以及需要有較低的學(xué)習(xí)門檻，簡單來講就是：可視化、配置化、低代碼。中臺(tái)產(chǎn)品設(shè)計(jì)如何實(shí)現(xiàn)可視、可配、可復(fù)用？本文作者從常見的中臺(tái)架構(gòu)出發(fā)，對(duì)這個(gè)問題展開了詳細(xì)解析，與大家分享。

中臺(tái)在這兩年是一個(gè)非?；鸬母拍?，其出現(xiàn)的目的只有一個(gè)：幫助企業(yè)快速且低成本的進(jìn)行創(chuàng)新。

二十年前，中國的互聯(lián)網(wǎng)剛剛起步，在線交易一片荒蕪，商品信息極難通過在線進(jìn)行展示，更別論在線交易；十年前，中國互聯(lián)網(wǎng)蓬勃發(fā)展，以阿里、京東為代表的企業(yè)實(shí)現(xiàn)了在線交易基礎(chǔ)設(shè)施的搭建，大部分的消費(fèi)則能夠在網(wǎng)上查找商品并進(jìn)行交易；

而如今，互聯(lián)網(wǎng)日益向著成為水電煤的趨勢(shì)發(fā)展，各種模式、形態(tài)的電商不斷涌現(xiàn)，昨天剛出現(xiàn)蘑菇街、小紅書，今天就有有贊、拼多多；昨天剛大力吹捧微博、公眾號(hào)的自媒體營銷，今天又有小程序的出現(xiàn)。

在這個(gè)極其不確定的時(shí)代里，任何一家企業(yè)都害怕錯(cuò)失機(jī)會(huì)，不斷出現(xiàn)的新鮮事物，讓企業(yè)創(chuàng)新的成本越來越高，如何能夠通過盡量少的成本，而不失嘗試新鮮事物的機(jī)會(huì)，成為企業(yè)經(jīng)營中遇到的難題之一。

一、常見的中臺(tái)架構(gòu)

在聊中臺(tái)的時(shí)候，我們一定需要聊一聊軟件架構(gòu)，軟件架構(gòu)是系統(tǒng)發(fā)展到一定的復(fù)雜程度后的必然產(chǎn)物，當(dāng)系統(tǒng)足夠復(fù)雜以后我們需要大規(guī)模的協(xié)作才能完成開發(fā)，必然要求我們對(duì)整個(gè)系統(tǒng)進(jìn)行橫向和縱向的切分，再按切分后的系統(tǒng)進(jìn)行團(tuán)隊(duì)劃分。

在切分系統(tǒng)時(shí)我們需要從垂直的角度考慮，例如：頁面、應(yīng)用、領(lǐng)域和基礎(chǔ)設(shè)置；也需要從橫向角度考慮，例如：店鋪、商品、訂單、支付等。對(duì)系統(tǒng)進(jìn)行切分后我們需要定義切分后的模塊之間的通信、同步等機(jī)制。

而且分系統(tǒng)最終的目的是能夠以更小粒度調(diào)配人力、物力、財(cái)力去完成系統(tǒng)的開發(fā)工作，而更小粒度的團(tuán)隊(duì)也更加便于管理，有效的降低企業(yè)成本。狹義的中臺(tái)也是一種軟件架構(gòu)（如圖），面向消費(fèi)者的是各種端中的應(yīng)用，通過統(tǒng)一的API網(wǎng)關(guān)能夠使用中臺(tái)各個(gè)業(yè)務(wù)中心的業(yè)務(wù)能力，而各個(gè)中心之間也能通過統(tǒng)一的協(xié)議進(jìn)行調(diào)用。

這樣一種架構(gòu)是與我們現(xiàn)在大部分的互聯(lián)網(wǎng)企業(yè)的組織架構(gòu)相匹配的，離消費(fèi)者或者客戶最近的是各個(gè)事業(yè)部，也就是軟件架構(gòu)中的應(yīng)用層；而中臺(tái)的各個(gè)業(yè)務(wù)中心就像技術(shù)部門、財(cái)務(wù)部門、市場公關(guān)等部門，能夠?yàn)榍芭_(tái)的應(yīng)用提供支撐。而我們把業(yè)務(wù)中心拆散后也更利于我們進(jìn)行微服務(wù)化，其直接的好處就是硬件資源變得可以按需投入了。

至此，我們簡單的對(duì)中臺(tái)的理念以及一些好處進(jìn)行了說明，那真實(shí)的中臺(tái)就是像我們上圖這種架構(gòu)嘛？答案是：不是。

二、如何解決快速和低成本的創(chuàng)新

首先我們回顧下推行建設(shè)中臺(tái)最直接的目的是：幫助企業(yè)快速且低成本的創(chuàng)新。如上的架構(gòu)我們對(duì)企業(yè)的系統(tǒng)進(jìn)行分層，并對(duì)中臺(tái)進(jìn)行領(lǐng)域的劃分，看上去似乎是能夠讓上層的應(yīng)用直接通過API網(wǎng)關(guān)調(diào)用中臺(tái)的能力進(jìn)行快速的應(yīng)用開發(fā)。

但我們忽略了一個(gè)重要的問題：系統(tǒng)開發(fā)不只是API調(diào)用，他是包括從產(chǎn)品規(guī)劃、開發(fā)測(cè)試、部署上線以及業(yè)務(wù)運(yùn)營等一系列的活動(dòng)。如果中臺(tái)只是能提供API是無法為應(yīng)用提供便利，即使有一些便利也會(huì)應(yīng)用接入中臺(tái)的復(fù)雜性而抵消這種便利。那復(fù)雜在哪里呢？

首先要能實(shí)施中臺(tái)我們一定會(huì)使用微服務(wù)，而要實(shí)現(xiàn)微服務(wù)我們必須要制定一系列的標(biāo)準(zhǔn)進(jìn)行微服務(wù)的劃分，也要把業(yè)務(wù)進(jìn)行更高層次的抽象，為何要進(jìn)行抽象呢？

例如：以前我們是單體應(yīng)用，我的交易流程只有一種就是現(xiàn)款后貨，但是由于我們是中臺(tái)我們面對(duì)大量的應(yīng)用每一個(gè)應(yīng)用雖然只有一種業(yè)務(wù)流程，但對(duì)我們來說可能就是很多種，如此我們需要對(duì)所有的業(yè)務(wù)進(jìn)行拆解，相同部分進(jìn)行合并，而不同的部分者需要獨(dú)立出來，同時(shí)在這些業(yè)務(wù)邏輯之上能夠提供統(tǒng)一流程編排服務(wù)。

而在這樣做了之后，對(duì)中臺(tái)每一個(gè)業(yè)務(wù)中心來說都有巨量的API可供使用，而如何能夠進(jìn)行使用只能通過API文檔或者是中臺(tái)開發(fā)直接的講解，而這種學(xué)習(xí)域熟悉的成本完全會(huì)抵消API復(fù)用的便利性。同時(shí)由于要中臺(tái)化，我們制定的諸多標(biāo)準(zhǔn)也會(huì)使得應(yīng)用處處受制，原本可以按照自己喜歡的方式進(jìn)行開發(fā)，而如今需要按照他人的標(biāo)準(zhǔn)執(zhí)行。

那到底應(yīng)該如何通過中臺(tái)進(jìn)行快速且低成本的創(chuàng)新呢？答案是：可視化、配置化、低代碼。

中臺(tái)的復(fù)用性相信大家一定是能夠感受到的，但由于其復(fù)用性所帶來的復(fù)雜確實(shí)我們?nèi)鄙偎伎嫉?。可視化能夠有效的降低使用方的學(xué)習(xí)成本，讓其能夠直觀的感受中臺(tái)的業(yè)務(wù)能力；配置化能夠把各個(gè)業(yè)務(wù)使用的能力集中起來管理，讓最熟悉業(yè)務(wù)的人員直接控制應(yīng)用中的業(yè)務(wù)邏輯，能夠把標(biāo)準(zhǔn)更好的執(zhí)行下去；而低代碼則是降低了開發(fā)人員學(xué)習(xí)中臺(tái)復(fù)雜技術(shù)框架的門檻，讓其能夠忽略底層的技術(shù)實(shí)現(xiàn)，只關(guān)心業(yè)務(wù)邏輯部分。

三、為了實(shí)現(xiàn)可視化、配置化、低代碼我們需要做些什么？

中臺(tái)最顯現(xiàn)的優(yōu)勢(shì)就是復(fù)用，復(fù)用是快速和低成本創(chuàng)新的基礎(chǔ)，那電商中臺(tái)為什么能夠復(fù)用呢？首先我們可以對(duì)電商業(yè)務(wù)進(jìn)行拆解。如圖：

在所有的電商中其核心的基礎(chǔ)流程都是：開店-發(fā)布商品-下單-支付-履約/售后-結(jié)算，在商品部分會(huì)和庫存有直接關(guān)聯(lián)，簡單點(diǎn)的直接使用虛擬庫存，復(fù)雜的庫存系統(tǒng)則會(huì)包含出入庫管理、庫存管理、配補(bǔ)管理、盤點(diǎn)等相關(guān)功能，而我們主要還是基于虛擬庫存進(jìn)行設(shè)計(jì)。

而能夠?qū)A(chǔ)流程產(chǎn)生影響的主要有以下這幾個(gè)方面的因素：業(yè)務(wù)模式、營銷方式和商品類型。具體每一種因素可能對(duì)交易流程的影響可見上圖。

在應(yīng)用的分層架構(gòu)中，我們可以從用戶能夠接觸的層次往系統(tǒng)抽象層次依次分為：頁面、功能、能力、數(shù)據(jù)模型或者是界面接口、應(yīng)用、領(lǐng)域、基礎(chǔ)設(shè)施。

而在業(yè)務(wù)架構(gòu)下我們電商業(yè)務(wù)又是怎樣的，我們分別看下BBC、B2C商城是怎樣的，如圖：

我們可以看到在不同的業(yè)務(wù)模式下，其實(shí)我們有大量的業(yè)務(wù)模塊是可以在頁面、功能、能力、數(shù)據(jù)模型這四個(gè)維度中的某幾個(gè)進(jìn)行共用的，那我們是否可以可以做一個(gè)這樣的設(shè)想：是否能夠把每一個(gè)應(yīng)用中的頁面、功能、能力和數(shù)據(jù)模型都打散 分別沉淀到對(duì)應(yīng)的頁面、功能、能力、數(shù)據(jù)模型的公用庫中，這樣以后每層次來一個(gè)新的業(yè)務(wù)只要通過從共用庫中選擇自己所需要的頁面、功能、能力、數(shù)據(jù)模型就可以搭建匹配自己業(yè)務(wù)邏輯的應(yīng)用。

通過以上的推演，我們可以看到在頁面、功能、能力、數(shù)據(jù)模型這些維度上進(jìn)行復(fù)用是符合邏輯的。我們知道中臺(tái)不只是能為應(yīng)用提供接口，而應(yīng)該是能夠提供全套復(fù)用資源的，包括頁面、功能、能力、和數(shù)據(jù)模型。而我們?cè)O(shè)計(jì)中臺(tái)的時(shí)候也需要設(shè)計(jì)相應(yīng)的管理和使用的工具，以達(dá)到可視化、配置化和低代碼的最終目的。

四、真實(shí)的電商中臺(tái)架構(gòu)

在聊電商中臺(tái)架構(gòu)之前，還需要和大家說說系統(tǒng)的運(yùn)行域和管理域。

運(yùn)行域指的是人們?cè)谙到y(tǒng)上開展業(yè)務(wù)時(shí)系統(tǒng)運(yùn)行代碼的空間；管理域指的是系統(tǒng)管理員控制系統(tǒng)參數(shù)或?qū)崿F(xiàn)預(yù)留業(yè)務(wù)擴(kuò)展點(diǎn)的工具的代碼運(yùn)行的空間。運(yùn)行域是為了解決實(shí)際業(yè)務(wù)而存在的，而管理員則是為了對(duì)運(yùn)行域的業(yè)務(wù)流程、規(guī)則進(jìn)行動(dòng)態(tài)調(diào)整而存在的。

在上文所說的頁面、功能、能力、數(shù)據(jù)模型都是屬于運(yùn)行域的內(nèi)容，而由于這些內(nèi)容在隨著企業(yè)業(yè)務(wù)不斷的發(fā)展過程中會(huì)越來越豐富，所以我們需要提供一個(gè)工具來對(duì)這些內(nèi)容進(jìn)行管理，隨之管理域就出現(xiàn)了。如圖基于中臺(tái)的整體應(yīng)用架構(gòu)：

在管理域中有如下三個(gè)基礎(chǔ)功能模塊：元數(shù)據(jù)管理、能力管理、組件管理。

元數(shù)據(jù)管理主要完成對(duì)數(shù)據(jù)模型的管理，包括對(duì)內(nèi)置對(duì)象的數(shù)據(jù)結(jié)構(gòu)進(jìn)行擴(kuò)展、部分字段的定，也包括對(duì)應(yīng)用中的定制對(duì)象進(jìn)行定義、字段設(shè)置等功能，更多元數(shù)據(jù)相關(guān)的功能在此不做表述，在整個(gè)業(yè)務(wù)邏輯中元數(shù)只是作為配置參數(shù)存在，而更多元數(shù)據(jù)的能力并未涉及；

能力管理主要是對(duì)能力和功能的管理，主要包括兩部分，一、是對(duì)中臺(tái)預(yù)置的配置項(xiàng)進(jìn)行注冊(cè)和發(fā)現(xiàn)，二、中臺(tái)預(yù)留抽象類，可讓應(yīng)用自己進(jìn)行定制化開發(fā)，在通過機(jī)制進(jìn)行注冊(cè)和發(fā)現(xiàn)并提供給應(yīng)用使用。具體的實(shí)現(xiàn)機(jī)制可參考Java中的SPI機(jī)制，簡單來說步驟如下：

• 在代碼中使用統(tǒng)一注釋，通過掃描可以自動(dòng)把注釋部分的代碼上報(bào)到能力管理實(shí)現(xiàn)注冊(cè)；
• 在能力對(duì)應(yīng)的代碼進(jìn)行修改了之后，掃描機(jī)制也能在一定的時(shí)機(jī)進(jìn)行更新；
• 通過統(tǒng)一的編碼規(guī)范，對(duì)某些類預(yù)留抽象類，可暴露給應(yīng)用方自己進(jìn)行實(shí)現(xiàn)；
• 應(yīng)用方對(duì)抽象類進(jìn)行實(shí)現(xiàn)后，可通過掃描機(jī)制發(fā)現(xiàn)，并讓應(yīng)用進(jìn)行調(diào)用。

組件管理主要可以分為頁面組件和服務(wù)組件的管理，頁面組件在設(shè)計(jì)時(shí)需要區(qū)分面向用戶商城頁面組件管理和面向商家或運(yùn)營人員的管理后臺(tái)的頁面組件庫。前端的組件最終是以頁面編輯器的方式進(jìn)行實(shí)現(xiàn)，在此不做詳細(xì)表述，而管理后臺(tái)的頁面組件庫則需要與全局管理的中的資源、菜單、角色管理配合起來一起滿足業(yè)務(wù)的需求。

其核心業(yè)務(wù)邏輯在于：所有系統(tǒng)中的頁面、菜單、頁簽、按鈕以及其它頁面元素都可以由統(tǒng)一的提供方提供，放到公共庫中，消費(fèi)方只需要按照標(biāo)準(zhǔn)進(jìn)行調(diào)用即可，如此能夠?qū)崿F(xiàn)最大限度的資源復(fù)用。統(tǒng)一UI資源的管理還有一個(gè)巨大的好處，能夠保證數(shù)據(jù)模型的穩(wěn)定性，不至于由于頁面的交互或視覺而造成對(duì)數(shù)據(jù)模型的沖擊，

功能服務(wù)組件則是把業(yè)務(wù)和平臺(tái)分離的關(guān)鍵，大量具有業(yè)務(wù)特性的聚合服務(wù)從核心業(yè)務(wù)邏輯中抽離，形成一個(gè)一個(gè)的服務(wù)組件，以插件的方式裝配到主干業(yè)務(wù)流程中，由于使用統(tǒng)一的標(biāo)準(zhǔn)進(jìn)行開發(fā)，在業(yè)務(wù)組件中預(yù)設(shè)大量的配置項(xiàng)，通過自動(dòng)注冊(cè)和發(fā)現(xiàn)機(jī)制實(shí)現(xiàn)配置項(xiàng)自動(dòng)化上報(bào)，而組件一被生產(chǎn)方生產(chǎn)出來后就會(huì)進(jìn)入統(tǒng)一的服務(wù)組件庫中，能夠被任一業(yè)務(wù)方進(jìn)行調(diào)用。

通過以上三個(gè)能力，能夠?qū)崿F(xiàn)對(duì)數(shù)據(jù)模型、能力、功能以及頁面的統(tǒng)一管理的需求，只是對(duì)這些內(nèi)容的管理還是不夠的，我們還不能實(shí)現(xiàn)最終目的，在能夠?qū)ζ溥M(jìn)行管理之后，我們需要能夠按業(yè)務(wù)需求把這些內(nèi)容組裝起來，以滿足業(yè)務(wù)的實(shí)際需求，且是通過配置化、低代碼的方式。

所有的業(yè)務(wù)系統(tǒng)按我們第二部分的內(nèi)容介紹都可以分為頁面、功能、能力、數(shù)據(jù)模型四個(gè)部分，電商系統(tǒng)普遍都是由前端商城+管理后臺(tái)組成。而在電商中整體的業(yè)務(wù)流程：開店-發(fā)布商品-下單-支付-履約/售后-結(jié)算，造成業(yè)務(wù)不同的因素主要是：行業(yè)（不同的類目）、賣家、和商品（不同的類型、模式）。

為了解決不同業(yè)務(wù)動(dòng)態(tài)化配置的問題 我們需要引入業(yè)務(wù)身份這一概念，業(yè)務(wù)身份主要是把前后臺(tái)的應(yīng)用放在同一個(gè)空間下進(jìn)行管理，我們?cè)诠芾碛蚩稍跇I(yè)務(wù)身份下進(jìn)行業(yè)務(wù)邏輯的配置，這些配置可以讓系統(tǒng)中包含的各個(gè)應(yīng)用在運(yùn)行域時(shí)能夠識(shí)別所需要使用的頁面、功能、能力和數(shù)據(jù)模型。

業(yè)務(wù)身份是一個(gè)標(biāo)識(shí)，能夠在虛擬空間中劃分一個(gè)獨(dú)立的系統(tǒng)運(yùn)行空間，在這個(gè)空間內(nèi)業(yè)務(wù)可以按設(shè)置好的配置在系統(tǒng)中完成，在這個(gè)空間中可以有多個(gè)應(yīng)用，空間中應(yīng)用所對(duì)應(yīng)的頁面（也即資源）、功能、能力和數(shù)據(jù)模型都會(huì)被業(yè)務(wù)身份進(jìn)行標(biāo)識(shí)。業(yè)務(wù)空間的示意圖如下：

而在端到業(yè)務(wù)應(yīng)用之間最為關(guān)鍵的就是如何進(jìn)行業(yè)務(wù)身份識(shí)別。業(yè)務(wù)身份不同的影響因素主要有：行業(yè)（不同的類目）、賣家、和商品（不同的類型、模式），我們?cè)谠O(shè)計(jì)業(yè)務(wù)身份時(shí)首先需要明確這個(gè)業(yè)務(wù)身份是在那個(gè)租戶下，其次需要把對(duì)應(yīng)的應(yīng)用關(guān)聯(lián)到業(yè)務(wù)空間，關(guān)聯(lián)的應(yīng)用決定了在該業(yè)務(wù)空間能夠設(shè)置的配置項(xiàng)的范圍，然后我們可以對(duì)我們這個(gè)業(yè)務(wù)空間進(jìn)行四個(gè)因素的選擇。

例如：行業(yè)為酒水、賣家為自營時(shí)我們加入購物車和立即下單時(shí)需要進(jìn)行認(rèn)證，且在商品類型為預(yù)售分階段時(shí)訂單需要走分階段訂單流程。在用戶操作頁面產(chǎn)生一個(gè)請(qǐng)求后，業(yè)務(wù)身份識(shí)別的過程如下圖：

業(yè)務(wù)身份的整體邏輯示例：在基礎(chǔ)的BBC電商系統(tǒng)中我們已經(jīng)實(shí)現(xiàn)了實(shí)物商品先款后貨的整體業(yè)務(wù)流程，但我們有些業(yè)務(wù)需要實(shí)現(xiàn)預(yù)售這種交易模式，此時(shí)我們能很好的運(yùn)用業(yè)務(wù)身份進(jìn)行業(yè)務(wù)邏輯的擴(kuò)展。我們需要對(duì)BBC商城中的發(fā)布商品（此處為設(shè)置營銷活動(dòng)）、下單、支付這三個(gè)環(huán)節(jié)進(jìn)行相關(guān)的業(yè)務(wù)配置：

1. 定義業(yè)務(wù)身份，當(dāng)“類目包涵茅臺(tái)”且“商家為直營”的業(yè)務(wù)身份為xxx.maotai.zhiying；
2. 把云商APP端關(guān)聯(lián)到該業(yè)務(wù)身份，把云商APP端對(duì)應(yīng)的發(fā)布商品應(yīng)用、下單應(yīng)用關(guān)聯(lián)到該業(yè)務(wù)身份下；
3. 我們需要在業(yè)務(wù)身份下進(jìn)行相關(guān)的配置設(shè)置，在營銷活動(dòng)的配置中開啟預(yù)售模式，在下單節(jié)點(diǎn)需要開啟訂單支持分階段交易，支付支持對(duì)一個(gè)訂單進(jìn)行多次支付；
4. 把相應(yīng)的配置配好之后，我們把配置以及配置對(duì)應(yīng)的功能組件進(jìn)行重新打包并發(fā)布上線；
5. 我們需要把預(yù)售對(duì)應(yīng)的菜單、頁面及按鈕等資源配置出來（在BOC中）
6. 在發(fā)布成功后，后臺(tái)管理（運(yùn)營及商家）能夠出現(xiàn)預(yù)售管理的菜單及相關(guān)的功能操作按鈕
7. 在發(fā)布商品時(shí)選擇的類目為茅臺(tái)且發(fā)布人對(duì)應(yīng)的商家為自營則能夠發(fā)貨預(yù)售活動(dòng)，
8. 在用戶對(duì)預(yù)售商品進(jìn)行下單時(shí)能夠根據(jù)類目與賣家的標(biāo)識(shí)進(jìn)行業(yè)務(wù)身份識(shí)別從而選擇對(duì)應(yīng)的業(yè)務(wù)空間中的交易流程。

以上就是業(yè)務(wù)身份在整體的業(yè)務(wù)流程中如何使用的邏輯，業(yè)務(wù)身份其實(shí)是我們自己定義的一個(gè)分隔業(yè)務(wù)的標(biāo)準(zhǔn)協(xié)議，在不同的企業(yè)可以選取不同過的業(yè)務(wù)維度決定業(yè)務(wù)身份，但主要從商品、類目、賣家這幾個(gè)業(yè)務(wù)維度，再加上端、應(yīng)用、租戶這幾個(gè)基礎(chǔ)維度即能準(zhǔn)確定位到具體的業(yè)務(wù)空間。

在不同的業(yè)務(wù)空間中配置有可能會(huì)出現(xiàn)沖突，此時(shí)需要對(duì)沖突進(jìn)行處理，才能真正把配置發(fā)布成功，配置沖突的場景如下：商品ID包涵0947（促銷活動(dòng)那個(gè)）時(shí)需要校驗(yàn)活動(dòng)庫存；商家為自營時(shí)需要校驗(yàn)邏輯庫存，此時(shí)由于配置都是對(duì)庫存校驗(yàn)進(jìn)行作用，需要確定配置是互斥還是疊加起作用，若是互斥，優(yōu)先使用哪一個(gè)？而如果是在業(yè)務(wù)空間的父子業(yè)務(wù)空間中的配置則取子業(yè)務(wù)空間中的配置項(xiàng)值。

通過以上的功能，我們能夠做到在復(fù)雜業(yè)務(wù)體系中對(duì)能力、功能、頁面/資源的可視、可配，而通過建設(shè)能力共享中心、業(yè)務(wù)組件庫、服務(wù)組件庫我們能夠沉淀大量的數(shù)字資產(chǎn)，實(shí)現(xiàn)業(yè)務(wù)的復(fù)用，從而降低重復(fù)開發(fā)的工作。

在以上的所有業(yè)務(wù)邏輯中，還需要強(qiáng)調(diào)以下幾點(diǎn)：

1. 由于所有的實(shí)體模型均在中臺(tái)進(jìn)定義，所以能夠有統(tǒng)一的實(shí)體編號(hào)生成機(jī)制，而這個(gè)統(tǒng)一的機(jī)制是能夠與業(yè)務(wù)身份所需要的信息進(jìn)行關(guān)聯(lián)，例如：需要在商品ID中預(yù)留6位，表示特定含義，而這種含義是需要被各個(gè)應(yīng)用進(jìn)行識(shí)別的；
2. 組件都是由生產(chǎn)方生產(chǎn)，可以被任一消費(fèi)方進(jìn)行調(diào)用，而不需要進(jìn)行代碼上的重復(fù)開發(fā)；
3. 業(yè)務(wù)中臺(tái)的能力都是通過接口提供給上方的功能或者頁面進(jìn)行調(diào)研，所以所有應(yīng)用對(duì)應(yīng)的底層業(yè)務(wù)邏輯代碼都是使用業(yè)務(wù)中臺(tái)的代碼；

以上就是我對(duì)整個(gè)電商業(yè)務(wù)中臺(tái)如何實(shí)現(xiàn)可視、可配、可復(fù)用的整體思考，而這只是一個(gè)真正中臺(tái)的業(yè)務(wù)及產(chǎn)品的部分，中臺(tái)是一個(gè)涵蓋組織、工程、業(yè)務(wù)產(chǎn)品、技術(shù)、運(yùn)營等方方面面的系統(tǒng)工程，而這種多維度的復(fù)合系統(tǒng)其復(fù)雜度與以往的后臺(tái)系統(tǒng)相比是指數(shù)級(jí)增長，而這種復(fù)雜性也是中臺(tái)戰(zhàn)略落地中的最大障礙。

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

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