标签：load 网站 设计方案 情况 接口 结构 它的 针对 根据
转：http://craft6.cn/detail/b2c_promotion_2017.do?tagKey=promotion
1常 见 的 电 商 促 销 场 景
左侧为享受促销的资格，常见为这三种：
首单
大于或等于某个会员级别
特定会员组：比如女性，月消费满1000等等，都是通过查询条件查询出来的特定分组。
优惠类型，对于电商网站主要是下面4类：
金额
赠品：商品、优惠券、现金券、积分等
包邮（实际上也是钱）
其它：如送精美包装等。 对于其它业务类型的平台，则估计会有其它形式的优惠，比如赠送三个VIP会员等等。
范围，无非就是：
整单
指定品类或特定品类（临时的活动分类，比如夏季新品特卖）
指定商品
满减：针对金额的减免，可以指定金额或百分比，涉及阶梯累加和数量累加等。
满赠：满足条件后获得赠品，赠品可以是五花八门，对于电商平台一般是商品、现金券、优惠券、积分等。
包邮：金额减免的另一种方式，但效果比减免小额金额要好。
其它规则：有些会带来设计的复杂度，但本质无非就是满减或满赠。
2促 销 的 表 现 形 式
促销的表现形式主要分为促销活动和优惠券两种。
站在系统的角度，促销活动是主动的，优惠券是被动的。
促销活动表示只要满足条件，下单时自动会进行促销规则计算，进行减免或者赠送。但是优惠券必须客户进行选择（或者输入券码）。
促销活动可以多个同时生效，比如：
首单包邮
满100减20
买电磁炉赠送餐具
这三个促销活动对于新会员（未曾购买过）都是同时有效的。
但促销活动存在互斥和优先级，这两个概念在后面再分析。
优惠券只存在一张优惠券生效。
即客户选择使用哪一张，就哪一张生效，无所谓互斥或者优先级。
优惠券可以和促销活动同时生效，只要生效促销活动不排斥优惠券即可。
那么，对于促销规则而言，促销活动和优惠券只是它上层的表现形式，实际的底层的促销规则是可以共用的（无非都是满减、满赠）
3促 销 规 则 分 析
从第一节场景来看，促销无非就是看：
是否满足资格
没有资格享受该优惠，就不必往下计算了。
当前规则的优惠类型是什么？
满减、满赠、包邮或者其它？
当前规则的生效范围是什么？
判断客户当前订单（购物车）是否满足当前规则生效范围之内，是则计算优惠。
规则的累加规则是什么？
阶梯累加：一般只针对金额
数量累加：否则只计算一次，是则乘以倍数。
规则之间的关系是怎样的？
优先级
兼容
互斥
可以通过这张图整体理解这个结构：
4促 销 规 则 的 关 系
促销规则的关系是设计的一个难点，对于规则而言本身是独立的，所以所谓关系就是它的上层表现形式的关系，而前面第二节也谈到，优惠券之间是无所谓关系的，用那张就那张生效（前提是该张优惠券可用，可以用）。
那么现在要分析的关系就只有：
促销活动之间的关系
促销活动和优惠券之间的关系
其中促销活动与优惠券的关系是一票否决方式，即只要本次订单（购物车）对应的生效促销活动有任一个设置为：排斥优惠券，则本订单（购物车）不能使用优惠券。
那么我们剩下要分析的就是促销活动之间的关系了，详见下图：
5领 域 业 务 建 模（模块级别）
促销规则独立为一个模块
促销活动、优惠券的管理在模块内，共规则模型调用。
规则模型对外提供接口，其它模块只能通过该接口访问模型。
模型实现该接口。
规则接口要求传入上下文参数
该上下文参数包含：商品列表（购物车当前选择的商品，客户ID 和 使用的优惠券。
规则接口是规则模块的边界。
调用者为购物车模块。
任何时候购物车发生修改时，调用规则接口重新计算。
规则发生更改时，会发送事件出来。
购物车模块计算价格业务监听此事件，有变更则更新相关购物车的价格。
此监听器为异步。
外部支持接口
客户接口：供查询客户资格相关使用
商品接口：供查询商品分类和其它定义使用。
6领 域 业 务 建 模（类级别）
类图有些大，手机上如果看不清，可以分享到pc上查看。
设计思路过程描述：
提供CartRuleService作为对外接口
分别调用：
PromotionService：促销活动接口
CouponService：优惠券接口
来处理促销活动和优惠券。
促销活动接口和优惠券接口均是实际调用RuleService来实现促销规则计算。
RuleService的实现采用桥模式和策略模式，并通过工程模式获得各个策略的实例。
传入的上下文参数封装为RuleContext，传给RuleService
RuleService返回RuleResult对象
PromotionResult和CoupontResult分别封装RuleResult对象进行返回。
通过这个设计方案，当有新的资格判断方式、目标范围和优惠类型时，通过新增策略实现即可，符合开闭原则。
7规 则 的 持 久 化
前面已经充分分析了规则的各个内容，如何将促销活动、优惠券和促销规则持久化以及持久化存储到那里其实已经是水到渠成的事情。怎样存储其实都可以，哪怕是一个json结构。
因为无论什么结构，最终在代码中都会被解析为对象并缓存起来供接口实现来调用。所以数据库设计在效率上不会要求太高。
数据库结构ER图：
规则定义和规则利益是独立的两个表，和优惠券、促销活动一对一关联。
规则定义包含：
资格类型、资格配置
利益类型、利益参数（是否累加）
目标范围类型、范围设置
其它字段根据项目情况自由添加。
规则利益
可以对不同的利益分别设计字段。
也可以设置一个利益类型和利益配置（json结构）
之所以独立出来作为子表，是因为存在阶梯累加的业务情况需要配置多条利益。
优惠券的设计为常规方式
定义：定义它的各种参数
实体：具体某一张优惠券
使用：一般一张优惠券只会使用一次，记录使用历史，也有优惠券可以使用多次。
促销活动定义
前面第4节说的促销规则的关系（其实是促销活动的关系）就是定义在这里。
分组、优先级、对优惠券的排斥等。
促销活动的参与日志
记录谁参与过
有些促销活动只能参与一次，则通过此表判断。
标签：load 网站 设计方案 情况 接口 结构 它的 针对 根据
原文地址：https://www.cnblogs.com/sheseido/p/9023470.html
