Arch Day 67
Arch Day 67: 商品中心设计
商品中心是电商/零售系统的数据基石，通过SPU(标准化产品单元)、SKU(库存量单位)、属性体系、类目体系和价格体系的组合设计，实现"一个商品从创建到展示到交易"全生命周期的结构化管理。
2026-06-05
第三阶段 - 零售域深度商品中心SPUSKU类目体系价格体系DDD
日期: 2026-06-05 (Day 67) 阶段: 第三阶段 - 零售域深度 标签: #商品中心 #SPU #SKU #类目体系 #价格体系 #DDD
核心概念
一句话定义
商品中心是电商/零售系统的数据基石，通过SPU(标准化产品单元)、SKU(库存量单位)、属性体系、类目体系和价格体系的组合设计，实现"一个商品从创建到展示到交易"全生命周期的结构化管理。
为什么关注
- 基石系统：所有零售业务(搜索/展示/下单/库存/物流)都依赖商品数据
- 设计复杂度高：全品类商品中心的属性/SKU管理是数据模型设计的经典挑战
- 面试高频：SPU/SKU关系、属性模板设计是系统设计面试的常见题目
- AI革新：AIGC正在重塑商品内容生产(描述/图片/视频自动生成)
- 规模挑战：头部电商平台管理数十亿SKU，性能和效率是核心
误区与反模式
| 误区 | 现实 |
|---|---|
| SPU就是商品 | SPU是标准化产品单元，一个SPU可以有多个SKU(不同颜色/尺码) |
| SKU越多越好 | SKU爆炸导致管理成本飙升，需要精细化管控 |
| 属性随便加 | 属性管理不当导致数据混乱(同义属性/格式不统一) |
| 一套类目打天下 | 前台类目(用户浏览)和后台类目(管理分类)必须分离 |
| 价格就一个字段 | 基础价/促销价/渠道价/会员价/区域价需要独立管理 |
知识点详解
1. SPU/SKU核心概念
核心概念关系：
类目(Category)
└── SPU(Standard Product Unit，标准化产品单元)
└── SKU(Stock Keeping Unit，库存量单位)
类比理解：
类目：手机
SPU：iPhone 16 Pro (一"款"产品)
SKU：iPhone 16 Pro 256GB 银色 (一"件"具体商品)
SPU描述的是"产品的共同特征"：
├── 品牌：Apple
├── 型号：iPhone 16 Pro
├── 处理器：A18 Pro
├── 屏幕：6.3英寸
└── 上市时间：2024年9月
SKU描述的是"可购买的最小单位"：
├── 颜色：银色/黑色/白色/沙漠色/自然色
├── 存储：128GB/256GB/512GB/1TB
├── 价格：不同SKU不同价格
└── 库存：每个SKU独立库存
SPU/SKU的关系
SPU和SKU的关系：
SPU: iPhone 16 Pro
│
├── SKU-001: 银色-128GB → ¥7999 → 库存50
├── SKU-002: 银色-256GB → ¥8999 → 库存30
├── SKU-003: 银色-512GB → ¥10999 → 库存20
├── SKU-004: 银色-1TB → ¥12999 → 库存10
├── SKU-005: 黑色-128GB → ¥7999 → 库存45
├── SKU-006: 黑色-256GB → ¥8999 → 库存35
├── ...
└── SKU-020: 自然色-1TB → ¥12999 → 库存5
SKU数量 = 颜色选项数 × 存储选项数
= 5 × 4 = 20个SKU
这就是"属性笛卡尔积"：
销售属性A的选项 × 销售属性B的选项 × ... = SKU总数
电商平台的商品层次
自营电商(京东自营)：
SPU → SKU (两层结构)
平台电商(淘宝/天猫)：
SPU → 商家商品(Merchant Product) → SKU (三层结构)
为什么需要三层？
├── 同一个SPU(iPhone 16 Pro)可能有多个商家售卖
├── 每个商家有自己的价格、库存、服务
├── 平台需要汇聚展示(比价、推荐)
└── CSPU(Child SPU)进一步管控商家发布质量
示例：
SPU: iPhone 16 Pro
├── 商家A(Apple官方旗舰店)
│ ├── SKU-A1: 银色-256GB → ¥8999
│ └── SKU-A2: 黑色-256GB → ¥8999
├── 商家B(京东自营)
│ ├── SKU-B1: 银色-256GB → ¥8899
│ └── SKU-B2: 黑色-256GB → ¥8899
└── 商家C(第三方卖家)
├── SKU-C1: 银色-256GB → ¥8799
└── SKU-C2: 黑色-256GB → ¥8799
2. 属性管理
属性分类
商品属性分类：
1. 关键属性(Key Attributes)
├── 用于唯一确定一个SPU
├── 品牌 + 型号 → 唯一SPU
└── 例：品牌=Apple, 型号=iPhone 16 Pro
2. 销售属性(Sale Attributes)
├── 用于生成SKU(笛卡尔积)
├── 影响价格和库存
└── 例：颜色、尺寸、存储容量
3. 非关键属性(Non-key Attributes)
├── 商品描述信息(不影响SKU)
├── 用于搜索过滤和详情展示
└── 例：处理器、屏幕尺寸、重量、产地
属性模板(Attribute Template)
属性模板设计：
每个类目定义一套属性模板
商品发布时按模板填写属性值
示例：手机类目属性模板
┌──────────────────────────────────────────────┐
│ 手机类目属性模板 │
├──────────────────────────────────────────────┤
│ 关键属性： │
│ ├── 品牌 (必填, 枚举: Apple/Samsung/...) │
│ └── 型号 (必填, 文本) │
│ │
│ 销售属性： │
│ ├── 颜色 (必填, 多选: 银/黑/白/...) │
│ └── 存储容量 (必填, 多选: 128GB/256GB/...) │
│ │
│ 非关键属性： │
│ ├── 处理器 (选填, 文本) │
│ ├── 屏幕尺寸 (选填, 数值+单位) │
│ ├── 摄像头 (选填, 文本) │
│ ├── 电池容量 (选填, 数值mAh) │
│ ├── 重量 (选填, 数值g) │
│ ├── 防水等级 (选填, 枚举: IP67/IP68) │
│ └── 5G支持 (选填, 是/否) │
└──────────────────────────────────────────────┘
属性值继承
属性值继承机制：
类目级默认值：
手机类目 → 5G支持=是 (类目默认)
SPU级属性值：
iPhone 16 Pro → 品牌=Apple, 处理器=A18 Pro
SKU级属性值(销售属性)：
SKU-001 → 颜色=银色, 存储=128GB
继承链：
类目默认 → SPU覆盖 → SKU覆盖
(低优先级) (高优先级)
查询时：
先查SKU属性 → 没有则查SPU → 没有则查类目默认
3. 类目体系设计
前台类目 vs 后台类目
后台类目(管理分类)：
├── 固定树形结构(3级)
├── 用于商品管理和属性模板关联
├── 一个商品只属于一个后台类目
└── 变更频率低(年度调整)
电子产品
├── 手机
│ ├── 智能手机
│ └── 功能手机
├── 平板电脑
└── 笔记本电脑
前台类目(浏览分类)：
├── 灵活多变(可重组)
├── 用于用户浏览和导航
├── 一个商品可属于多个前台类目
└── 变更频率高(运营调整)
热门推荐
├── 学生开学季 → 手机+平板+笔记本
├── 送礼精选 → 手机+手表+耳机
└── 5G新品 → 各品牌5G手机
为什么要分离？
后台类目：稳定、标准、一对一
前台类目：灵活、可运营、多对多
分离后运营可以自由调整前台导航，不影响后台管理
类目关联设计
类目关联模式：
模式一：树形结构(单继承)
后台类目通常使用
一个子类目只有一个父类目
简单清晰，但不灵活
Root
├── Level 1 (大类)
│ ├── Level 2 (中类)
│ │ ├── Level 3 (小类)
│ │ └── Level 3
│ └── Level 2
└── Level 1
模式二：DAG(有向无环图)
前台类目可以使用
一个类目可以属于多个父类目
灵活但复杂
"iPhone 16" 可以同时出现在：
├── 手机 > 苹果手机
├── 新品推荐
└── 5G精选
模式三：标签体系(Tag)
配合类目使用
自由标注，支持搜索和筛选
例：#5G #折叠屏 #旗舰 #学生推荐
4. 价格体系
价格体系层次：
┌──────────────────────────────────────────────┐
│ 价格体系 │
│ │
│ ┌──────────────────────────────────┐ │
│ │ 基础价(Base Price) │ │
│ │ = 商品的标准零售价 │ │
│ │ 通常由商品中心管理 │ │
│ └──────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────┐ │
│ │ 渠道价(Channel Price) │ │
│ │ ├── App价格 │ │
│ │ ├── 小程序价格 │ │
│ │ ├── 门店价格 │ │
│ │ └── 第三方平台价格 │ │
│ └──────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────┐ │
│ │ 会员价(Member Price) │ │
│ │ ├── 普通会员 95折 │ │
│ │ ├── 金卡会员 9折 │ │
│ │ └── 黑卡会员 85折 │ │
│ └──────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────┐ │
│ │ 促销价(Promotion Price) │ │
│ │ ├── 限时折扣 │ │
│ │ ├── 满减/满折 │ │
│ │ ├── 优惠券 │ │
│ │ └── 秒杀价 │ │
│ └──────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────┐ │
│ │ 区域价(Regional Price) │ │
│ │ ├── 一线城市价格 │ │
│ │ ├── 二三线城市价格 │ │
│ │ └── 海外价格 │ │
│ └──────────────────────────────────┘ │
│ │
│ 最终价格 = f(基础价, 渠道, 会员, 促销, 区域) │
│ 需要明确优先级和叠加规则！ │
└──────────────────────────────────────────────┘
价格计算规则
价格叠加/互斥规则(示例)：
规则1: 会员价和促销价取最低
会员价=¥899, 促销价=¥859 → 最终¥859
规则2: 优惠券可以叠加在促销价上
促销价=¥859, 优惠券-¥50 → 最终¥809
规则3: 有保底价(不能低于成本)
if 最终价格 < 成本价 × 保底系数:
最终价格 = 成本价 × 保底系数
规则4: 渠道价独立
App渠道有专属价格时，覆盖基础价
价格优先级：
秒杀价 > 促销价 > 会员价 > 渠道价 > 基础价
价格防护(防止资损)：
├── 改价审批(大幅降价需审核)
├── 保底价校验(不低于成本+X%)
├── 价格变更日志(审计)
└── 价格异常告警
5. 商品参数化(SKU笛卡尔积)
SKU生成过程(笛卡尔积)：
步骤1：选择销售属性
颜色：[银色, 黑色, 白色] → 3个选项
存储：[128GB, 256GB, 512GB] → 3个选项
步骤2：生成笛卡尔积
颜色 × 存储 = 3 × 3 = 9个SKU
SKU-1: 银色 + 128GB
SKU-2: 银色 + 256GB
SKU-3: 银色 + 512GB
SKU-4: 黑色 + 128GB
SKU-5: 黑色 + 256GB
SKU-6: 黑色 + 512GB
SKU-7: 白色 + 128GB
SKU-8: 白色 + 256GB
SKU-9: 白色 + 512GB
步骤3：为每个SKU设置价格和库存
SKU-1: ¥7999, 库存50
SKU-2: ¥8999, 库存30
...
注意SKU爆炸问题：
服装：颜色(10) × 尺码(8) = 80个SKU
鞋类：颜色(10) × 尺码(15) = 150个SKU
手机：颜色(5) × 存储(4) × 版本(2) = 40个SKU
当属性维度超过3-4个时，SKU数量指数增长
→ 需要SKU管理策略(不是所有组合都需要)
6. 商品DDD领域模型
/**
* 商品中心DDD领域模型
*
* 聚合根：SPU
* 实体：SKU, Attribute, PricePolicy
* 值对象：CategoryPath, AttributeValue
*/
// ===== 聚合根：SPU =====
@AggregateRoot
public class SPU {
private SPUId id; // SPU唯一标识
private String name; // 商品名称
private String subtitle; // 副标题
private BrandId brandId; // 品牌ID
private CategoryPath categoryPath; // 后台类目路径
// SPU级属性(非关键属性)
private Map<AttributeId, AttributeValue> attributes;
// SKU列表
private List<SKU> skus;
// 状态
private SPUStatus status; // DRAFT/REVIEW/ONLINE/OFFLINE
// 商品描述(富文本/AIGC)
private ProductDescription description;
// 媒体资源
private List<MediaResource> images;
private List<MediaResource> videos;
// 业务方法
public SKU addSKU(Map<SaleAttribute, String> saleAttrs,
Money price, int stock) {
// 校验销售属性组合不重复
validateUniqueSaleAttributes(saleAttrs);
SKU sku = new SKU(generateSKUId(), this.id, saleAttrs, price, stock);
this.skus.add(sku);
return sku;
}
public void online() {
// 上架校验
validateForOnline();
this.status = SPUStatus.ONLINE;
registerEvent(new SPUOnlinedEvent(this.id));
}
public void offline() {
this.status = SPUStatus.OFFLINE;
registerEvent(new SPUOfflinedEvent(this.id));
}
}
// ===== 实体：SKU =====
@Entity
public class SKU {
private SKUId id; // SKU唯一标识
private SPUId spuId; // 所属SPU
private String skuCode; // SKU编码(条码/货号)
// 销售属性组合(确定唯一SKU)
private Map<SaleAttribute, String> saleAttributes;
// 例: {颜色: "银色", 存储: "256GB"}
// 价格
private Money basePrice; // 基础价
private Money costPrice; // 成本价
// 状态
private SKUStatus status; // ACTIVE/INACTIVE
// 物流属性
private Weight weight; // 重量
private Dimension dimension; // 尺寸(长宽高)
}
// ===== 实体：类目 =====
@Entity
public class Category {
private CategoryId id;
private String name;
private CategoryId parentId; // 父类目
private int level; // 层级(1/2/3)
private CategoryType type; // BACKEND/FRONTEND
private boolean isLeaf; // 是否叶子节点
// 属性模板
private AttributeTemplate attributeTemplate;
// 前台类目关联的后台类目(多对多)
private List<CategoryId> linkedBackendCategories;
}
// ===== 值对象：属性模板 =====
@ValueObject
public class AttributeTemplate {
private CategoryId categoryId;
// 关键属性定义
private List<AttributeDefinition> keyAttributes;
// 销售属性定义
private List<AttributeDefinition> saleAttributes;
// 非关键属性定义
private List<AttributeDefinition> nonKeyAttributes;
}
// ===== 值对象：属性定义 =====
@ValueObject
public class AttributeDefinition {
private AttributeId id;
private String name; // 属性名
private AttributeType type; // TEXT/NUMBER/ENUM/MULTI_ENUM/BOOLEAN
private boolean required; // 是否必填
private List<String> enumValues; // 枚举值列表(如有)
private String unit; // 单位(如有)
private String defaultValue; // 默认值
private int sortOrder; // 排序
}
// ===== 实体：价格策略 =====
@Entity
public class PricePolicy {
private PricePolicyId id;
private SKUId skuId;
private PriceType type; // BASE/CHANNEL/MEMBER/PROMOTION/REGIONAL
private Money price;
private String channelCode; // 渠道(如适用)
private MemberLevel memberLevel; // 会员等级(如适用)
private String regionCode; // 区域(如适用)
private LocalDateTime startTime; // 生效时间
private LocalDateTime endTime; // 失效时间
private int priority; // 优先级
}
// ===== 值对象：类目路径 =====
@ValueObject
public class CategoryPath {
private CategoryId level1; // 一级类目
private CategoryId level2; // 二级类目
private CategoryId level3; // 三级类目
public String getFullPath() {
return level1 + "/" + level2 + "/" + level3;
}
}
7. 大量SKU管理策略
面对海量SKU(数十亿)的管理策略：
1. 存储分层
├── 热数据(活跃SKU)：Redis缓存
├── 温数据(近期SKU)：MySQL/TiDB
└── 冷数据(下架SKU)：归档存储(OSS/HBase)
2. 搜索优化
├── Elasticsearch索引商品+属性
├── 属性值标准化(防止"红色"和"Red"重复)
├── 分词优化(商品名+属性+品牌)
└── 向量搜索(语义相似商品)
3. 属性管理
├── 属性值字典(统一管理枚举值)
├── 属性继承(减少重复定义)
├── 属性校验(格式/范围/必填)
└── AI自动标注(图像识别→属性)
4. SKU精简
├── 低销SKU下架(长尾清理)
├── 重复SKU合并
├── 属性组合限制(不是所有组合都开放)
└── 按需生成SKU(而非预生成所有组合)
5. 性能优化
├── 商品详情页静态化(CDN)
├── 属性查询缓存(多级缓存)
├── 批量操作(批量改价/上下架)
└── 异步索引更新(MQ+ES)
对比分析
各平台商品模型对比
| 平台 | 商品层次 | SKU量级 | 属性管理 | 特色 |
|---|---|---|---|---|
| 淘宝/天猫 | SPU→商家商品→SKU | 百亿+ | 类目属性模板+商家自定义 | CSPU标准化管控 |
| 京东 | SPU→SKU | 数十亿 | 标准属性+自定义属性 | 自营严格品控 |
| 拼多多 | 商品→SKU | 数十亿 | 简化属性 | 低门槛快速发布 |
| Amazon | ASIN→Offer | 百亿+ | Product Type+Attributes | 全球统一编码 |
| Shopify | Product→Variant | 中小规模 | 最多3个Option+100 Variant | 简单灵活 |
商品数据结构方案对比
| 方案 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|
| 宽表(所有属性列) | 查询简单 | 属性变更要改表 | 属性固定的少品类 |
| EAV(属性值表) | 灵活扩展 | 查询复杂(多次JOIN) | 属性变化大的多品类 |
| JSON字段 | 灵活+查询尚可 | 索引支持有限 | 中等规模 |
| ES+MySQL | 灵活+高性能搜索 | 数据一致性维护 | 大规模电商(主流) |
架构设计实操
设计目标
设计一个"全品类商品DDD领域模型"，包含：
- SPU/SKU/Attribute/Category/Price五大实体
- 支持多品类属性模板
- 支持价格分层管理
- 支持前后台类目分离
(领域模型已在上方"知识点详解-6"中完整给出)
ADR: 商品属性存储方案
## ADR-067: 商品属性存储方案选型
### 状态: 已采纳
### 上下文
全品类商品中心，不同类目属性差异大(手机vs服装vs食品)，
需要灵活的属性存储方案。
### 可选方案
A. 宽表(每个类目一张表，列=属性)
B. EAV(Entity-Attribute-Value，三张表)
C. JSON字段(MySQL JSON / PostgreSQL JSONB)
D. ES索引 + MySQL基础信息
### 决策
采用方案D：MySQL存储基础信息(SPU/SKU/类目) +
ES存储全量属性(搜索/过滤) + Redis缓存热数据
### 理由
1. MySQL管理核心实体和关系(事务保证)
2. ES支持灵活的属性搜索和过滤(不需要ALTER TABLE)
3. Redis缓存商品详情(高并发读)
4. 属性变更通过MQ同步到ES(准实时)
5. 这是淘宝/京东等大厂的主流方案
### 后果
- 需要维护MySQL↔ES数据一致性
- ES集群运维成本
- 属性变更有秒级延迟(异步同步)
AI增强实践
AI在商品中心的革新应用
2025-2026年AI在商品中心的应用：
1. AI自动标注属性
├── 图像识别→颜色/材质/款式
├── OCR→品牌/型号/参数
├── NLP→标题解析→结构化属性
└── 准确率：85-95%(需人工审核)
2. AIGC商品内容生成
├── 商品标题优化(SEO)
├── 商品描述自动生成
├── 卖点提炼(基于评价分析)
├── 多语言翻译(跨境电商)
└── 商品图片生成(场景图/3D)
3. AI分类与类目推荐
├── 自动归类到后台类目
├── 推荐最佳前台类目
├── 新品类目建议
└── 同类商品聚合(去重)
4. 智能定价
├── 竞品价格监控
├── 动态定价建议
├── 促销效果预测
└── 弹性定价(需求曲线)
5. 商品质量检测
├── 图片质量检测(模糊/水印)
├── 违禁品识别(文本+图片)
├── 虚假宣传检测
└── 合规检查(3C/FDA等)
实际案例(2025)：
├── 淘宝：AIGC生成40%+商品描述
├── Amazon：AI Review Insights(评价摘要)
├── Shopify：Magic(AI商品文案生成)
└── 拼多多：AI辅助商品图片优化
与Web3/DeFi的关联
商品NFT化
商品NFT化方向：
1. 实物商品NFT凭证
├── 购买实物→获得NFT(数字凭证)
├── NFT可转让/交易(二手市场)
├── NFT验证真伪(防伪溯源)
└── 案例：Nike .SWOOSH运动鞋NFT
2. 数字商品(原生NFT)
├── 数字服装(虚拟穿搭)
├── 游戏道具
├── 数字艺术品
└── 音乐/视频NFT
3. 商品Token化
├── 碳信用Token化(商品碳足迹)
├── 供应链金融Token(应收账款)
├── 预售Token(商品期货)
└── 忠诚度Token(积分上链)
商品中心扩展(支持Web3)：
├── SKU增加Token合约地址字段
├── NFT元数据与商品属性映射
├── 链上验证API(真伪/所有权)
└── 跨平台商品互通(链上标准)
今日思考
三个深度问题
-
SPU/SKU模型在万物互联时代是否过时？ 传统SPU/SKU模型是为实物商品设计的。当商品形态扩展到数字商品(NFT)、服务(SaaS订阅)、虚拟+实物组合(手机+保险+延保+教程)时，现有模型是否需要根本性重构？还是通过扩展属性可以解决？
-
AIGC对商品中心的"颠覆"：当AI可以自动生成商品标题、描述、图片甚至定价建议时，商品中心的角色会如何变化？是从"人工录入的数据库"变为"AI生产的内容平台"？这对系统架构有什么影响？
-
全球商品编码的统一问题：Amazon用ASIN，阿里用SPU，各平台的商品ID体系互不兼容。Web3是否可以提供一个全球统一的商品ID标准(类似ERC-721的唯一性)？区块链上的商品注册是否有价值？
面试题准备
面试题1: SPU和SKU的关系？
30秒回答： SPU是标准化产品单元(一"款"产品)，SKU是库存量单位(一"件"可购买的具体商品)。一个SPU可以有多个SKU，通过销售属性(颜色/尺码/容量)的笛卡尔积生成。例如iPhone 16 Pro是一个SPU，iPhone 16 Pro银色256GB是一个SKU。SPU描述共同特征，SKU决定价格和库存。
2分钟详细回答： SPU/SKU的关系需要从三个层面理解：
数据层面：SPU是商品的抽象描述，包含品牌、型号、通用属性等；SKU是具体的可购买单元，由SPU+销售属性组合确定。SKU是库存管理和交易的最小单位。
生成规则：SKU通过销售属性的笛卡尔积生成。如颜色3种×尺码5种=15个SKU。但并非所有组合都必须生成——可以根据实际备货情况选择性开放。
平台差异：自营电商(京东自营)用SPU→SKU两层；平台电商(淘宝)用SPU→商家商品→SKU三层，因为同一个SPU可能有多个商家售卖。
追问准备：
- Q: SKU爆炸怎么处理？
- A: 三个策略——限制销售属性维度(不超过3-4个)、按需生成SKU(不预生成所有组合)、定期清理低销SKU。
面试题2: 大量SKU下如何高效管理属性？
30秒回答： 大规模SKU属性管理的核心方案是"类目属性模板+ES搜索"。通过类目属性模板标准化每个品类的属性定义(必填/选填/枚举)，MySQL存储核心实体关系，ES存储全量属性支持灵活搜索过滤，Redis缓存热点商品详情。属性变更通过MQ异步同步到ES，保证准实时一致性。
追问准备：
- Q: EAV和JSON字段为什么不选？
- A: EAV查询需要多次JOIN，性能差；JSON字段在MySQL中索引支持有限(虽然MySQL 8.0改善了)。ES天然支持动态Schema和全文搜索，是大规模商品属性管理的主流方案。
学习资源
| 资源 | 类型 | 说明 |
|---|---|---|
| 淘宝商品模型分析 | 文章 | SPU/SKU/商品层次详解 |
| Shopify Product API | 文档 | 商品数据模型参考 |
| Elasticsearch权威指南 | 文档 | 搜索引擎 |
| Amazon Product Advertising API | 文档 | 商品数据结构参考 |
| DDD与电商领域建模 | 书籍 | 领域驱动设计 |
明日预告
Day 68: 库存系统设计
- 库存类型(可售/实物/在途/预占/冻结)
- 库存扣减策略(下单减/支付减/发货减)
- 全渠道库存统一视图
- 分布式库存扣减(Redis预扣→DB持久化)
- 高并发下防超卖