商品中臺“反向賦能”架構實踐
引言
在系統演進的道路上，“另起爐灶”往往是應對歷史債務最快的“解藥”，但也可能埋下“新債”的種子。
我們的智慧門店業務以餐飲起家，構建了一套餐飲商品系統。當開拓零售業務時，為規避餐飲系統的歷史債務重、耦合度高的問題，我們選擇“另起爐灶”，構建了一套全新的“商品 2.0”系統。雖然解決了燃眉之急，卻帶來了新的挑戰：同時維護兩套獨立的商品系統，導致研發與維護成本急劇攀升。
例如，同一個“商家自定義單位”功能，我們不得不在兩個系統中重復開發，這顯然是難以接受。
我們意識到，真正的解決方案不是“商品 2.0”，而是必須將其升級為商品中臺，能支持超市、酒旅、教育等未來創新業務；還必須有能力“反向賦能”餐飲這個龐大的存量系統，逐步帶領我們走出“煙囪式”開發的困境。
架構的“道”與“術”
任何成功的架構轉型，都離不開頂層設計思想的指引。在構建商品中臺時，我們始終遵循著架構的“道”與“術”。
架構的“道”，是戰略層面的指導方針，它決定了我們“為什么這么做”。
- 業務驅動，而非技術驅動：架構的核心是為業務服務 。我們所有的設計決策，都源于對零售、餐飲等多業態商品管理本質的深刻理解與抽象 。
- 擁抱變化，可演化設計：我們深知業務是不斷變化的 。因此，架構必須具備彈性，能夠平滑地適應未來的不確定性，而非僵化地抵抗變化。
- 分而治之，隔離復雜度：面對日益復雜的系統，唯一的辦法就是“分治” 。將龐大的商品域，有序地拆解為獨立的、高內聚的業務單元，是控制 “熵增” 的關鍵手段。
架構的“術”，是戰術層面的具體實現，它回答了我們“如何去做”。
- 領域驅動設計（DDD）：這是我們最核心的武器。通過領域建模、限界上下文、領域事件，我們將業務的核心概念映射到系統架構之中 。
- 分層與模塊化：嚴格的垂直分層確保每一層職責單一 ，而橫向的業務單元化則保證了模塊的高內聚、低耦合，共同構成了清晰的系統邊界。
- 設計原則的堅守：SOLID、DRY、KISS等設計原則是我們編碼的“戒律”，是從理論認知到工程實踐的升華，幫助我們寫出更健壯、更易于維護的代碼。
中臺架構
基于這些思想，我們開始規劃商品中臺架構，其核心目標，是將過去各個業務域之間“網狀”的混亂依賴 ，重塑為以中臺為核心、由前臺應用靈活編排業務單元的有序結構。
1. 業務單元化
拆分是應對復雜系統的首選策略。我們首先對整個商品域進行解構，劃分出多個職責清晰的業務單元（Business Units），并按適用范圍將這些單元分為兩大類：通用單元和個性單元。
- 通用單元：這些是所有業務都必須依賴的核心能力，是中臺的基石。例如：主商品、商品類目、庫存、價格、標簽、媒體資源等。
- 個性單元：承載不同行業的差異化，例如：餐飲行業的 “口味做法”、“加料” ；零售行業的 “品牌”、“多包裝” 等
每個業務單元都是一個獨立的、可部署的服務，內部遵循 DDD 四層架構，擁有自己的領域模型、領域服務和倉儲服務。單元之間通過標準化的 RPC 接口和領域事件進行通信，實現了物理和邏輯上的雙重隔離。
2. 服務編排組裝
為了應對復雜多變的業務需求，我們對每個業務單元的內部結構進行了分層。任何一個業務領域（如商品、庫存）都包含 “穩定” 與 “易變” 兩個部分。基于此，我們將每個業務單元清晰地劃分為上下兩層結構：基礎服務層和業務場景層。
圖片
- 基礎服務層：負責提供穩定、原子化的核心能力。如圖所示，我們將商品、分類、庫存、單位、供應商等領域的核心操作，沉淀為一系列高內聚、低耦合的基礎服務。例如，主商品域提供 “創建”、“修改價格”、“上下架”等原子接口；庫存域提供 “預扣”、“直扣”、“查詢” 等接口。這些服務保持極高的簡潔性和可復用性，它們不耦合任何特定的上層業務，是整個商品中臺堅實、穩定的能力基座。
- 業務層：負責封裝靈活、易變、具有創新探索性的業務邏輯。它就像一個總指揮，根據具體的業務“劇本”，對底層基礎服務進行有序地“組裝”與“編排”，以滿足形態各異的業務玩法。這一層的服務特點是有狀態、有流程、懂業務。
圖片
無論是“商品導入”、“商品克隆” 還是“OCR創建商品”，它們作為不同的業務場景，最終都是通過調用和組合“基礎服務池”中的原子能力來完成的。
這樣，我們不需要從頭開發，而是可以像搭積木一樣，在業務場景層快速復用、編排已有的基礎服務，極大地提升了業務的響應速度。這種 “穩定基座 + 靈活編排”的模式，是我們實現商品中臺高擴展性與高效率的核心。
3. 多行業模板化設計
商品中臺面臨的另一個挑戰來自于業務的廣度：如何用一套統一的模型，支撐起零售、酒店、教育、旅行、攝影、油品等形態迥異的行業商品。如果為每個行業都定義一套獨立的商品模型，中臺將不復存在，我們會再次陷入“煙囪式”的開發困境。
我們采用 模板 + 屬性池 的設計，將所有行業可能用到的商品特征，如 “商品名稱”、“條碼”、“產地”等，全部沉淀到一個共享的“屬性池”中。每個屬性都包含了豐富的元數據，不僅定義了其業務含義，還封裝了前端渲染方式（component_config）和后端校驗規則（rules）。而“行業模板”則作為一個動態的“視圖”配置，通過圈選屬性池中的不同屬性，來精確定義該行業商品所需的數據結構和業務規則。
圖片
當商戶創建商品時，系統會根據其所選行業加載相應模板，并動態生成前端頁面。用戶提交數據后，后端服務會依據模板配置的規則進行泛化校驗，并對數據進行拆包，分為 “商品基礎信息” 和 “商品擴展信息” 兩部分。
- 商品基礎信息：包含所有行業通用、查詢頻率高的核心字段（如商品名稱、價格、單位等），被持久化到主商品表的物理字段中，以保證核心查詢性能。
- 商品擴展信息：包含行業特有的、動態變化的屬性，采用泛化存儲模式，以鍵值對（JSON）形式存入擴展字段中。
這種 核心模型 + 擴展模型 的設計，使得主數據表結構相對穩定。未來如果接入一個新的行業，只需在后臺配置一套新的模板，而無需大范圍的代碼改動以及數據表結構變更，使商品中臺具備較強的擴展性。
賦能餐飲業務
在商品中臺的架構逐步清晰并支撐起多行業業務后，我們開始“反向賦能”。利用中臺沉淀的能力，為債務沉重的餐飲商品系統高效地開發一些新功能，以滿足其不斷演進的業務需求。
1、商品單位：從重復建設到能力復用
單位，作為商品的重要屬性，是體現新舊架構差異的典型案例。在舊的系統中，單位是平臺級的標準化數據，通過一個全局的字典服務（DictService）管理，初期尚能滿足需求。但隨著業務不斷發展，商家提出想自己定義商品單位，并能自主管理，原來的架構不能滿足要求。
考慮到單位也是餐飲商品的重要屬性，我們沒有在舊的DictService上打補丁，而是遵循中臺化思想，設計成一個全新的、支持多行業的 “單位業務單元”。
圖片
新架構引入業務租戶，如圖所示，新的單位 RPC 服務在接口層設計了業務方code、所屬類型、所屬ID等參數。這意味著，無論是零售還是餐飲調用同一個 “創建單位” 接口，在服務內部會根據租戶標識，將數據進行邏輯隔離，確保不同業務方的自定義單位數據互不干擾，為能力的復用提供了安全邊界。
圖片
- 高比例復用：新的“商品單位” 架構具備商家自定義單位的全部核心能力。其 RPC 服務、領域服務、倉儲服務和數據存儲幾乎可以 80% 復用。
- 少量適配：我們僅需在 API 網關層和 RPC 服務的路由邏輯中，增加對“餐飲”業務租戶的識別和適配少量差異化場景，比如：刪除自定義單位時，需要校驗其在餐飲或零售商品庫是否存在引用，這是一個暫時的、可接受的耦合點。
這次架構升級的價值在后續業務迭代中也得到很好反饋，當產品同學提出 【餐飲商品要支持自定義單位】功能時，我們僅用 **不到一周 **的時間便高質量完成交付。
2、進銷存：從零到一的平臺化構建
與 “商品單位” 這類存量改造不同，“進銷存”是一個全新的業務域，更容易實踐中臺化的架構思想。項目啟動之初，我們的目標就不僅僅是滿足零售業務的需求，而是要構建一個能夠同時支撐零售、餐飲乃至未來更多業態的統一進銷存平臺。
為確保新業務的穩健落地，我們規劃了從零售到餐飲、從 APP 端到多端（PC、收銀機）四階段迭代路線，通過小步快跑，有序地擴展服務范圍。
圖片
在整體架構上，我們將采購入庫、退貨出庫、盤點、報損等業務，封裝成一個獨立的“進銷存業務單元”。其內部嚴格遵循前文所述的分層模型。將“創建采購單”、“確認盤點單”等沉淀為一系列穩定、原子化的基礎服務。上層的業務網關則面向不同前端（如收錢吧APP、PC端、收銀機），負責處理客戶端接入、協議轉換及服務編排。
考慮到零售和餐飲的商品服務、庫存服務仍是兩套獨立系統，引入“路由器，當需要商品信息時，統一發出請求，路由器根據租戶標識將請求轉發至對應的下游服務（零售商品服務或餐飲商品服務）。這個路由器扮演了防腐層的角色，使得進銷存單元本身保持對外部系統異構性的“無知”，極大地降低了系統間的耦合度。
圖片
3、庫存中心：務實的融合之道
歷史架構中，餐飲和零售的庫存管理是兩套完全獨立的物理系統，隨著“進銷存”項目在餐飲業務的落地，一個迫切的需求擺在面前，餐飲庫存需要支持精細化的流水追蹤。
此前，零售庫存系統已經沉淀了十幾種庫存流水類型（如：售賣、采購入庫、商品克隆等）。餐飲場景不僅可以復用其中大部分類型，還存在一些獨有場景（如：自動補足庫存）。如果沿用舊模式，為餐飲再開發一套獨立的庫存流水，容易形成新的技術孤島，且維護兩套高度相似的代碼成本也非常高。
圖片
從中臺復用的視角出發，最理想的方案是構建一個物理統一的庫存中心。然而，我們也面臨著一個巨大的挑戰：懸殊的數據體量與并發壓力。
- 餐飲業務：作為成熟業務，存量庫存數據非常高，每日新增流水在千萬級別，系統常年處于高并發狀態。
- 零售業務：作為新興業務，庫存和流水數據量相對小一個數量級，日均流水約百萬級別。
強行合并物理存儲，不僅數據遷移過程風險極高，而且在遷移窗口期內，要確保線上業務（如商品售賣、退貨、采購入庫等等）持續產生的動態數據變更最終一致，是一個巨大的挑戰，甚至可能需要“停機發布”，這對業務是不可接受的。
面對有限的研發資源和對線上穩定性的敬畏，我們權衡再三，決定采用一種更務實的** “邏輯統一，物理隔離” **的融合策略。
圖片
a）統一的領域服務：我們抽象出一套統一的庫存服務，向上游業務（收錢吧APP、收銀機等）提供標準化的 RPC 接口，如批量新增、庫存直扣、查詢流水等。無論調用方是餐飲還是零售，調用的都是同一套代碼邏輯。
b）倉儲層的路由分發：當請求到達倉儲服務時，通過上下文中的業務標識，將調用動態分發至對應的 餐飲 Mapper 或 零售 Mapper。
c）適配的物理存儲：沿用舊的物理數據庫，餐飲和零售的庫存、流水表依然保持獨立。Mapper層通過不同的SQL實現，巧妙地“消化”了底層表結構的差異。
畢竟，系統迭代大多發生在上層業務邏輯，而底層表結構變更相對低頻。這種統一策略，在不影響線上穩定性的前提下，實現約 80% 的代碼復用。以最低的成本和風險，解決了餐飲庫存流水的核心訴求，并為未來實現數據層面的徹底統一保留了平滑演進的可能。
五、結語
從各自為政的業務煙囪，到統一商品中臺的構建，再到反向賦能歷史系統。我們始終堅持以業務驅動和分而治之為為目標，并通過深度的模型抽象、業務單元化、服務分層等有效地隔離了系統的穩定內核與業務的敏捷變化。未來，商品中臺將繼續深化其能力，橫向支持更多元的行業，為智慧門店的業務創新提供源源不斷的動力。
關于作者
宋志朋，來自智慧經營開發部
