業(yè)務中臺構(gòu)建-模塊識別
SOA團隊 2020-03-16
注：圖片來源于阿里云棲大會相關材料
在談業(yè)務中臺前，首先看下對于中臺原來我們一般說法是包括了業(yè)務中臺和數(shù)據(jù)中臺，而現(xiàn)在另外一種說法是包括了業(yè)務中臺，數(shù)據(jù)中臺，技術中臺和AI中臺。而實際上對于技術中臺不建議劃分到中臺里面，可以劃分到底層的技術支撐平臺，屬于技術PaaS平臺的一部分。而對于AI中臺單獨劃分出來本身也沒有必要，AI中臺可以劃分到數(shù)據(jù)中臺的大范疇里面。
就拿企業(yè)來說，中臺的構(gòu)建包括了業(yè)務中臺和數(shù)據(jù)中臺，按道理應該是先考慮業(yè)務中臺如何構(gòu)建，再基于構(gòu)建好的業(yè)務中臺來構(gòu)建數(shù)據(jù)中臺。但是也有企業(yè)由于遺留系統(tǒng)很多，并沒有參考理想的方法去構(gòu)建完整的業(yè)務中臺，而是直接去構(gòu)建數(shù)據(jù)中臺。數(shù)據(jù)中臺按照全新的方法去構(gòu)建，替代傳統(tǒng)的ODS加數(shù)據(jù)倉庫的構(gòu)建方法。
對于數(shù)據(jù)中臺的構(gòu)建，下篇再展開分析，本篇還是重點談下業(yè)務中臺的構(gòu)建。
先看下傳統(tǒng)的業(yè)務系統(tǒng)規(guī)劃和構(gòu)建思路，我們講過更多的是業(yè)務和流程驅(qū)動型構(gòu)建模式。簡單來說就是，我們先分析清楚在業(yè)務上有哪些流程需要支撐，哪些業(yè)務需求需要支撐，然后基于流程逐層分解的方法來分析整個業(yè)務架構(gòu)，基于業(yè)務架構(gòu)再來分析數(shù)據(jù)架構(gòu)，最后結(jié)合業(yè)務+數(shù)據(jù)架構(gòu)來分析需要規(guī)劃建設哪些業(yè)務系統(tǒng)或子系統(tǒng)。最后才會去考慮數(shù)據(jù)如何落地到數(shù)據(jù)庫，應該有哪些數(shù)據(jù)對象和建立哪些數(shù)據(jù)庫表。
■ 以數(shù)據(jù)驅(qū)動先行的思路來考慮中臺模塊的識別
而對于業(yè)務中臺的構(gòu)建思路，這里給出一種新的構(gòu)建思路，即數(shù)據(jù)驅(qū)動型的構(gòu)建思路。對于切入還是可以從端到端流程切入，但是只需要初步分析頂層業(yè)務流程即可，不需要進行詳細的業(yè)務流程分析和分解，并規(guī)劃業(yè)務架構(gòu)。而是先進行數(shù)據(jù)架構(gòu)規(guī)劃和數(shù)據(jù)域劃分。
即流程并不需要分析的太細，就已經(jīng)能夠完全了解企業(yè)核心基礎主數(shù)據(jù)和核心共享數(shù)據(jù)。這個時候你已經(jīng)可以梳理出比較粗的數(shù)據(jù)架構(gòu)模型，找到核心的業(yè)務對象了（基礎主數(shù)據(jù)和核心共享數(shù)據(jù)）。
同時我們也初步定義了數(shù)據(jù)域和數(shù)據(jù)邊界。那么數(shù)據(jù)域和邊界的劃分是否合理？又得回到端到端流程分析，即還是需要根據(jù)端到端的業(yè)務流程來進一步試算和演練我們的數(shù)據(jù)域劃分是否合理，即在端到端流程協(xié)同的時候是否會出現(xiàn)底層數(shù)據(jù)域之間的頻繁交互和協(xié)同，如果存在多個數(shù)據(jù)對象間頻繁交互，那么這些數(shù)據(jù)對象往往不能進行拆分，否則就可以拆分。
同時我們看到以核心基礎數(shù)據(jù)和共享數(shù)據(jù)為主體進行數(shù)據(jù)分域，分域后形成的各個數(shù)據(jù)域之間滿足松耦合的要求，這些分離出來的數(shù)據(jù)域就是獨立的中臺各個業(yè)務能力提供中心。類似我們常說的訂單中心，合同中心，項目中心，產(chǎn)品中心，用戶中心，供應商中心，物料中心，客戶中心等。
在這個過程中你會發(fā)現(xiàn)供應商和物料之間的耦合性很強，那供應商+物料可以規(guī)劃在中臺的一個中心，一個微服微模塊里面來實現(xiàn)。類似框架協(xié)議和采購訂單，也需要放在一個中臺中心一個道理。
■ 以對外流程協(xié)同，對內(nèi)數(shù)據(jù)能力提供兩條線來考慮中臺模塊接口服務識別
如果中臺模塊已經(jīng)識別出來，接著就需要去思考每個中臺模塊究竟需要提供哪些接口服務能力。而這種接口服務的識別，我們考慮兩條線相互結(jié)合的方式進行。
1. 根據(jù)中臺模塊的核心數(shù)據(jù)對象來思考應該包括哪些數(shù)據(jù)接口服務能力
你可以理解為你先不用去思考需要支撐上層哪些業(yè)務功能和流程，就是將你已經(jīng)識別的基礎主數(shù)據(jù)對象和核心共享數(shù)據(jù)的CRUD能力暴露出現(xiàn)。但是這個暴露和簡單的暴露數(shù)據(jù)庫表有差異，這里暴露的應該是核心領域?qū)ο蠛蛿?shù)據(jù)對象，這個對象可能是底層多張數(shù)據(jù)庫表。即將底層數(shù)據(jù)庫表，以領域?qū)ο竽Ｐ途酆虾蟮乃悸穼PI接口暴露出去。同時我們還需要初步分析哪些能力是不需要對外開放的。比如一些數(shù)據(jù)對象只需要朝外暴露查詢能力接口即可，而有些業(yè)務對象則需要暴露CRUD的所有能力，這個也需要分析清楚。
2. 結(jié)合端到端交互流程
或者也可以是理解為通過前臺需要實現(xiàn)的業(yè)務場景和流程，來分析究竟中臺模塊需要提供哪些能力。要知道通過第一點往往并不能識別出來所有的中臺模塊應該提供的API接口服務，特別是一些涉及到業(yè)務規(guī)則和邏輯的接口服務能力，因此在這里還需要繼續(xù)識別還需要哪些接口服務，這些接口應該確保粗粒度和可重用。
簡單的如一個業(yè)務對象狀態(tài)變更的接口服務能力，在第一種方式下我們往往并不會單獨將其識別出來定義為一個獨立的API接口服務，但是基于業(yè)務場景分析后發(fā)現(xiàn)有這個需求，那么就需要單獨定義接口。
所有中臺的構(gòu)建目的都是為了更好的為前臺業(yè)務功能實現(xiàn)服務，因此結(jié)合前臺的業(yè)務場景和功能需求來進一步識別需要暴露的接口服務能力是必須的。即我們要意識到前臺的構(gòu)建更多的都是組裝中臺層各個微服務模塊暴露的API接口服務能力，而不是自己去實現(xiàn)這個能力，前臺可能有自己獨立的數(shù)據(jù)庫，但是這個數(shù)據(jù)庫本身也很輕，只會存儲一些臨時的或局部使用的數(shù)據(jù)信息。
遠行科技
遠行云商
