一、为什么要用域来设计很多人做防伪溯源系统第一反应是建几张表、写几个接口。结果做着做着赋码、验真、追溯、营销全搅在一起一个需求改动要改 10 个地方。这就是典型的大泥球架构。我们的解法是领域驱动设计DDD把系统按业务域拆成 6 个独立模块。每个域有自己的数据库、自己的服务、自己的团队通过事件总线解耦。二、6 大域定义与职责1. 赋码域Code Domain职责码生成、码池管理、产线赋码客户端。核心实体CodeBatch码段、Code单码、CodePool码池。特点写多、对一致性要求极高不能重复。2. 验真域Verify Domain职责扫码验真、状态查询、异常封禁。核心实体VerifyResult、VerifyLog。特点读多、峰值极高大促、对延迟敏感。3. 追溯域Trace Domain职责履历构建、链路查询、批次检索。核心实体TraceEvent追溯事件、TraceChain链。特点检索多、数据量大、读多写多。4. 风控域Risk Domain职责批量伪造识别、地理围栏、窜货评分。核心实体RiskRule、RiskScore、Blacklist。特点计算密集、实时性要求高。5. 分析域Analytics Domain职责扫码行为画像、复购预测、BI 看板。核心实体UserPortrait、Metric、Dashboard。特点离线批处理为主、容忍延迟。6. 会员域Member Domain职责留资、积分、企微 SCRM、券营销。核心实体Member、Point、Coupon。特点和营销强绑定、写多。三、域间关系事件总线解耦关键设计所有跨域数据流通过 Kafka 事件总线传递不互相直接 RPC 调用。赋码域 ──CodeAssigned──▶ [Kafka] ──▶ 追溯域 / 验真域 / 分析域 验真域 ──CodeVerified──▶ [Kafka] ──▶ 风控域 / 分析域 / 会员域 风控域 ──RiskAlert────▶ [Kafka] ──▶ 会员域 / 告警好处赋码产生事件验真/追溯/分析各自消费互不影响新增一个营销域只需订阅现有事件不改任何老代码某个域宕机其他域照常运行最终一致。四、统一商品 ID 设计所有域打通的命脉是统一商品 ID 体系。我们设计了 4 级层级含义粒度谁用SPU产品级如茅台 53°500ml品牌/BISKU规格级同款不同年份电商/库存BATCH批次级同原料同产线质检/召回CODE单件码每瓶唯一赋码/验真/追溯所有域的数据库都以 CODE 为最细粒度主键向上聚合到 SPU 查询。这样消费者扫一瓶码能追溯到它属于哪个 SPU、哪一批仓储扫一箱码能拆出 N 个瓶码产线赋一个码自动归属到批次和 SKU。五、部署与扩容策略每个域独立部署、独立扩容验真域大促前独立加节点 Redis 副本读多赋码域按产线水平扩展写多追溯域只读副本分流查询分析域弹性/定时跑批大促时可临时缩容。六、MVP 建议与避坑别一上来就搞 6 个域。我们的节奏MVP第 1 月赋码 验真 追溯 3 域跑通闭环第 2 月加风控域防窜货第 3 月加分析域BI第 4 月加会员域私域。避坑域间不要共享数据库共享数据库 伪微服务最终还是会耦合。数据通过事件传递接受最终一致。