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