一、核心架构设计知识点
1. 项目模块与数据库设计
- 促销模块独立化：电商促销核心模块为
tulingmall-promotion，与主体业务解耦，降低促销规则变更对核心业务的影响。 - 数据库独立部署：单独分配
tu_mall_promotion数据库，包含 13 张核心表，按业务类型分类：- 优惠券相关：
sms_coupon、sms_coupon_history、sms_coupon_product_category_relation、sms_coupon_product_relation - 秒杀相关：
sms_flash_promotion、sms_flash_promotion_log、sms_flash_promotion_product_relation、sms_flash_promotion_session - 首页推荐相关：
sms_home_advertise、sms_home_brand、sms_home_new_product、sms_home_recommend_product、sms_home_recommend_subject
- 优惠券相关：
- 性能优化点：首页推荐表因数据量大、访问频繁，需结合缓存做优化设计（如 Redis 缓存热点数据）。
2. 系统设计核心原则
促销系统设计的核心：在最小化影响主体业务的前提下，保证促销规则的灵活性，支持后续满减、套餐、积分、F 码等复杂规则的扩展。
二、优惠券业务核心功能与实现
1. 优惠券核心业务流程
优惠券实现了发布 - 领取 - 使用 全流程，当前项目实现全场通用券简化版，预留了指定分类、指定商品券的扩展设计，流程如下：
2. 优惠券发布配置项
后台发布优惠券时需配置核心字段，为全场通用券的必选配置：
| 配置项 | 示例值 | 说明 |
|---|---|---|
| 优惠券名称 | 移动端全品类通用券 | 标识优惠券用途 |
| 适用平台 | 移动平台 | 限定使用终端（可扩展 PC / 小程序等） |
| 总发行量 | 100 | 控制优惠券发放总量，防止超发 |
| 面额 | 10 元 | 优惠金额 |
| 每人限领 | 1 张 | 限制用户领取数量，控制成本 |
| 使用门槛 | 满 100 元可用 | 消费金额阈值，满足才可用 |
| 有效期 | 2022-11-11 至 2024-11-14 | 券的有效使用时间范围 |
| 可使用商品 | 全场通用 | 当前实现仅该类型，预留指定分类 / 商品 |
3. 前端核心交互设计
- 商品详情页：根据商品价格匹配优惠券使用门槛，展示可领取的优惠券；
- 订单确认页：展示用户已领取的优惠券列表，选择后实时计算商品总价 - 优惠活动 - 优惠券 - 运费 = 应付总额；
- 扩展预留：前端代码中注释了
指定分类（label=1）、指定商品（label=2）的使用类型选择器，为后续扩展预留接口。
4. 核心表作用
| 表名 | 核心作用 | 关键字段扩展 |
|---|---|---|
sms_coupon |
优惠券主表，存储券的基础配置 | 面额、使用门槛、有效期、使用类型等 |
sms_coupon_history |
优惠券领取 / 使用历史表，存储用户与券的关联 | couponcode：预留字段，为 F 码等扩展使用 |
sms_coupon_product_category_relation |
券与商品分类的关联表 | 为指定分类券做设计，当前未实现 |
sms_coupon_product_relation |
券与商品的关联表 | 为指定商品券做设计，当前未实现 |
三、促销流程扩展设计
1. 现有扩展预留点
- 表设计：
sms_coupon_history的couponcode字段，为F 码通道等特殊促销预留； - 字段设计：订单确认页的优惠活动字段，可扩展会员减免、积分兑换等规则；
- 类型设计：优惠券使用类型预留指定分类、指定商品，可扩展品类券、单品券；
- 模块设计：秒杀、首页推荐模块独立，可单独扩展规则且不影响优惠券核心业务。
2. F 码通道扩展实现步骤
基于现有预留设计，实现小米商城类似F 码专属优惠 的流程，核心利用couponcode唯一标识：
3. 其他扩展方向
- 商品 / 品类券：实现
couponcode与商品 / 分类表的关联查询，商品详情页仅展示该商品 / 品类的专属券； - 会员减免：基于用户会员等级，在
优惠活动字段中增加会员等级与减免金额的映射； - 积分兑换：对接积分表，将积分抵扣金额计算到
优惠活动字段，与优惠券叠加 / 互斥。