關注我，緊跟本系列專欄文章，咱們下篇再續！
作者簡介：魔都技術專家兼架構，多家大廠後端一線研發經驗，各大技術社區頭部專家博主，編程嚴選網創始人。具有豐富的引領團隊經驗，深厚業務架構和解決方案的積累。負責：
- 中央/分銷預訂系統性能優化
- 活動&優惠券等營銷中臺建設
- 交易平臺及數據中臺等架構和開發設計
目前主攻降低軟件複雜性設計、構建高可用系統方向。
參考：
1 前言
受限於對業務掌握度及對應數據特性的瞭解，大數據平臺更傾向海量的同構或異構數據採集，清洗，加工，存儲。而提供的數據服務更多是對採集到數據進行彙總及分析。
供應鏈域數據中臺專注供應鏈域業務數據，優勢是具備熟練掌握相關業務的產品和開發，更瞭解業務和數據特性：
- 爲產品線提供準確及時的數據服務
- 也爲數分提供完善的數據脈絡，幫助其更好對這些數據深層挖掘分析，再次提升數據價值
系統設計上也將考慮系統能做到能進能退：
- 進則作爲獨立數據域的數據中臺產品，逐漸完善自身特性
- 退則作爲一個數據域模塊快速融入公司大數據中臺
2 理論篇
有了存在意義和價值空間，接下來考慮如何構建。採用DDD構建數據中臺的各類模型。結合當下情況分析，自頂向下的策略更適合。首先目標建立供應鏈域數據中臺，頂層領域已限定供應鏈。其次該策略不受限於當前系統，適合用 DDD 領域逐級分解的建模方法。
2.1 領域模型界定
現階段業務需求是給相關業務系統提供準確及時的供應鏈域數據服務，同時也是數據中臺核心服務，所以作爲主體的數據服務是毫無爭議的核心域。
數據中臺第二個重要功能是提供元數據字典服務，即提供有關聯關係的元數據的脈絡服務。
其展示該域下各數據實體的關聯關係及鏈路節點出處，以及相關數據服務詳情介紹等，可稱之爲數據治理，作用上區分可將數據治理歸爲通用域。數據治理和數據服務的共同基石則是數據，這裏指出的就是數據中臺另一個功能同時也是本質功能，打通數據孤島對數據的採集加工和存儲，這些就組成另外一個子域，歸爲支撐域。
數據中臺域模型圖：
系統架構設計模、領域模型界定完畢後，下面就是以領域模型爲指導進行系統架構模型的設計。系統架構模型設計依然用 DDD。
搭建有自身特色的數據中臺，決定我們沒有可參考案例，爲防過度設計，提前設定一個設計方針，即系統架構須是一個演進式，經得起破壞和重構，才能滿足低成本，快建設，快試錯。大而全系統架構設計雖也是我們嚮往，但現狀不許。
2.2 數據中臺系統設計模型
① 接口層
數據中臺對外服務的統一入口：
- 對接各種類型的訪問請求，如restful 接口，api接口，RPC框架服務接口等
- 提供服務適配，對各種類型接口提供請求參數和返回結果集的適配相關的服務
② 應用層
實現服務組合和編排，以快速滿足業務需求。不可否認用戶需求一直在變化。能做的就是如何快速響應這些變化，服務組合和重新編排，提升服務可重用性，降低重複功能的開發成本，提升開發效率，爲業務的快速試錯提供了很好支撐。
③ 領域層
該層實現核心業務邏輯，同時聚集了領域模型的聚合、聚合根、實體、值對象、領域服務和事件等領域對象，以及它們組合所形成的業務能力。通俗易懂的，是實現了業務處理邏輯的服務原子化，按業務邏輯將服務細分，細分後的原子服務將脫離具體的業務模式，爲應用層的服務組合和編排提供“原材料”。
④ 基礎層
貫穿所有層，爲各層提供基礎資源服務。包含MySQL，PG，ES，HBase和Redis等數據存儲和緩存服務。
還有一部分重要組成就是公共服務，好產品離不開監控運維和相關日誌服務，這些是保障系統健康的重要措施。
3 實踐篇
3.1 供應鏈域數據中臺系統架構設計
數據中臺系統架構設計模型：
- 數據治理將供應鏈全鏈路涉及到或者相關的所有子域的數據進行目錄化管理
- 數據服務則基於所有子域數據提供標準或者定製化的服務
- 數據存儲則主要依賴大數據平臺和搜索，是基於數據中臺的數據的量級和服務的便利性以及可用性考慮
- 數據採集基本是 kafka 和 數據同步組件，基於數據的吞吐量和可靠性考慮
3.2 系統實現模型設計
數據中臺數據流轉模型（數據中臺服務保障方案）：
如圖所示，按既定接口層/應用層/領域層/基礎層設計，逐層封裝，各層相互協作，對業務系統提供靈活的數據服務，很好地實現了各層分工，便於快速響應業務需求。
考慮到數據中臺主要爲業務系統提供數據服務，爲保障數據服務的可靠性和及時性，還得兼顧系統性能和穩定，對數據服務做了冗餘和歸檔服務。冗餘的服務同時具備降級職責，提升服務 SAL 指標。
4 總結
基於 DDD 領域建模的供應鏈域數據中臺設計基本完畢，緊接着就是後續流暢的開發工作。覆盤過程，雖不甚完美，“先開槍後瞄準”至少在探索數據中臺領域邁出第一步，那麼成功就不會太遠。
本文由博客一文多發平臺 OpenWrite 發佈！