一、為什么要用域來設計很多人做防偽溯源系統(tǒng)第一反應是建幾張表、寫幾個接口。結果做著做著賦碼、驗真、追溯、營銷全攪在一起一個需求改動要改 10 個地方。這就是典型的大泥球架構。我們的解法是領域驅(qū)動設計DDD把系統(tǒng)按業(yè)務域拆成 6 個獨立模塊。每個域有自己的數(shù)據(jù)庫、自己的服務、自己的團隊通過事件總線解耦。二、6 大域定義與職責1. 賦碼域Code Domain職責碼生成、碼池管理、產(chǎn)線賦碼客戶端。核心實體CodeBatch碼段、Code單碼、CodePool碼池。特點寫多、對一致性要求極高不能重復。2. 驗真域Verify Domain職責掃碼驗真、狀態(tài)查詢、異常封禁。核心實體VerifyResult、VerifyLog。特點讀多、峰值極高大促、對延遲敏感。3. 追溯域Trace Domain職責履歷構建、鏈路查詢、批次檢索。核心實體TraceEvent追溯事件、TraceChain鏈。特點檢索多、數(shù)據(jù)量大、讀多寫多。4. 風控域Risk Domain職責批量偽造識別、地理圍欄、竄貨評分。核心實體RiskRule、RiskScore、Blacklist。特點計算密集、實時性要求高。5. 分析域Analytics Domain職責掃碼行為畫像、復購預測、BI 看板。核心實體UserPortrait、Metric、Dashboard。特點離線批處理為主、容忍延遲。6. 會員域Member Domain職責留資、積分、企微 SCRM、券營銷。核心實體Member、Point、Coupon。特點和營銷強綁定、寫多。三、域間關系事件總線解耦關鍵設計所有跨域數(shù)據(jù)流通過 Kafka 事件總線傳遞不互相直接 RPC 調(diào)用。賦碼域 ──CodeAssigned──? [Kafka] ──? 追溯域 / 驗真域 / 分析域 驗真域 ──CodeVerified──? [Kafka] ──? 風控域 / 分析域 / 會員域 風控域 ──RiskAlert────? [Kafka] ──? 會員域 / 告警好處賦碼產(chǎn)生事件驗真/追溯/分析各自消費互不影響新增一個營銷域只需訂閱現(xiàn)有事件不改任何老代碼某個域宕機其他域照常運行最終一致。四、統(tǒng)一商品 ID 設計所有域打通的命脈是統(tǒng)一商品 ID 體系。我們設計了 4 級層級含義粒度誰用SPU產(chǎn)品級如茅臺 53°500ml品牌/BISKU規(guī)格級同款不同年份電商/庫存BATCH批次級同原料同產(chǎn)線質(zhì)檢/召回CODE單件碼每瓶唯一賦碼/驗真/追溯所有域的數(shù)據(jù)庫都以 CODE 為最細粒度主鍵向上聚合到 SPU 查詢。這樣消費者掃一瓶碼能追溯到它屬于哪個 SPU、哪一批倉儲掃一箱碼能拆出 N 個瓶碼產(chǎn)線賦一個碼自動歸屬到批次和 SKU。五、部署與擴容策略每個域獨立部署、獨立擴容驗真域大促前獨立加節(jié)點 Redis 副本讀多賦碼域按產(chǎn)線水平擴展寫多追溯域只讀副本分流查詢分析域彈性/定時跑批大促時可臨時縮容。六、MVP 建議與避坑別一上來就搞 6 個域。我們的節(jié)奏MVP第 1 月賦碼 驗真 追溯 3 域跑通閉環(huán)第 2 月加風控域防竄貨第 3 月加分析域BI第 4 月加會員域私域。避坑域間不要共享數(shù)據(jù)庫共享數(shù)據(jù)庫 偽微服務最終還是會耦合。數(shù)據(jù)通過事件傳遞接受最終一致。