Java生鲜电商平台-电商促销业务分析设计与系统架构

Java生鲜电商平台-电商促销业务分析设计与系统架构

 

说明：Java开源生鲜电商平台-电商促销业务分析设计与系统架构,列举的是常见的促销场景与源代码下载

 

•  左侧为享受促销的资格，常见为这三种：

• 首单

• 大于或等于某个会员级别

• 特定会员组：好比女性，月消费满1000等等，都是经过查询条件查询出来的特定分组。

• 优惠类型，对于电商网站主要是下面4类：

• 金额

• 赠品：商品、优惠券、现金券、积分等

• 包邮（实际上也是钱）

• 其它：如送精美包装等。 对于其它业务类型的平台，则估计会有其它形式的优惠，好比赠送三个VIP会员等等。

• 范围，无非就是：

• 整单

• 指定品类或特定品类（临时的活动分类，好比夏季新品特卖）

• 指定商品

• 满减：针对金额的减免，能够指定金额或百分比，涉及阶梯累加和数量累加等。

• 满赠：知足条件后得到赠品，赠品能够是五花八门，对于电商平台通常是商品、现金券、优惠券、积分等。

• 包邮：金额减免的另外一种方式，但效果比减免小额金额要好。

• 其它规则：有些会带来设计的复杂度，但本质无非就是满减或满赠。

 

 

2促 销 的 表 现 形 式

 

    促销的表现形式主要分为促销活动和优惠券两种。

    站在系统的角度，促销活动是主动的，优惠券是被动的。

 

    促销活动表示只要知足条件，下单时自动会进行促销规则计算，进行减免或者赠送。可是优惠券必须客户进行选择（或者输入券码）。

 

    促销活动能够多个同时生效，好比：

• 首单包邮

• 满100减20

• 买电磁炉赠送餐具

 

    这三个促销活动对于新会员（不曾购买过）都是同时有效的。

 

    但促销活动存在互斥和优先级，这两个概念在后面再分析。

 

    优惠券只存在一张优惠券生效。

    即客户选择使用哪一张，就哪一张生效，无所谓互斥或者优先级。

 

    优惠券能够和促销活动同时生效，只要生效促销活动不排斥优惠券便可。

 

    那么，对于促销规则而言，促销活动和优惠券只是它上层的表现形式，实际的底层的促销规则是能够共用的（无非都是满减、满赠）

 

 

3促 销 规 则 分 析

 

 

    从第一节场景来看，促销无非就是看：

1.  是否知足资格

1. 没有资格享受该优惠，就没必要往下计算了。

2.   当前规则的优惠类型是什么？

1. 满减、满赠、包邮或者其它？

3.  当前规则的生效范围是什么？

1. 判断客户当前订单（购物车）是否知足当前规则生效范围以内，是则计算优惠。

4. 规则的累加规则是什么？

1. 阶梯累加：通常只针对金额

2. 数量累加：不然只计算一次，是则乘以倍数。

5. 规则之间的关系是怎样的？

1. 优先级

2. 兼容

3. 互斥

 

    能够经过这张图总体理解这个结构：

 

 

 

4促 销 规 则 的 关 系

 

    促销规则的关系是设计的一个难点，对于规则而言自己是独立的，因此所谓关系就是它的上层表现形式的关系，而前面第二节也谈到，优惠券之间是无所谓关系的，用那张就那张生效（前提是该张优惠券可用，能够用）。

    那么如今要分析的关系就只有：

 

• 促销活动之间的关系

• 促销活动和优惠券之间的关系

 

    其中促销活动与优惠券的关系是一票否决方式，即只要本次订单（购物车）对应的生效促销活动有任一个设置为：排斥优惠券，则本订单（购物车）不能使用优惠券。

 

    那么咱们剩下要分析的就是促销活动之间的关系了，详见下图：

 

 

5领 域 业 务 建 模（模块级别）

 

 

    

 

1. 促销规则独立为一个模块

1. 促销活动、优惠券的管理在模块内，共规则模型调用。

2. 规则模型对外提供接口，其它模块只能经过该接口访问模型。

3. 模型实现该接口。

4. 规则接口要求传入上下文参数

5. 该上下文参数包含：商品列表（购物车当前选择的商品，客户ID 和 使用的优惠券。

6. 规则接口是规则模块的边界。

2. 调用者为购物车模块。

1. 任什么时候候购物车发生修改时，调用规则接口从新计算。

2. 规则发生更改时，会发送事件出来。

3. 购物车模块计算价格业务监听此事件，有变动则更新相关购物车的价格。

4. 此监听器为异步。

3. 外部支持接口

1. 客户接口：供查询客户资格相关使用

2. 商品接口：供查询商品分类和其它定义使用。

 

 

6领 域 业 务 建 模（类级别）

 

    类图有些大，手机上若是看不清，能够分享到pc上查看。

 

    设计思路过程描述：

1.  提供CartRuleService做为对外接口

2. 分别调用：

1. PromotionService：促销活动接口

2. CouponService：优惠券接口

来处理促销活动和优惠券。

1. 促销活动接口和优惠券接口均是实际调用RuleService来实现促销规则计算。

2. RuleService的实现采用桥模式和策略模式，并经过工程模式得到各个策略的实例。

3. 传入的上下文参数封装为RuleContext，传给RuleService

4. RuleService返回RuleResult对象

5. PromotionResult和CoupontResult分别封装RuleResult对象进行返回。

 

    经过这个设计方案，当有新的资格判断方式、目标范围和优惠类型时，经过新增策略实现便可，符合开闭原则。

 

 

7规 则 的 持 久 化

 

 

    前面已经充分分析了规则的各个内容，如何将促销活动、优惠券和促销规则持久化以及持久化存储到那里其实已是水到渠成的事情。怎样存储其实均可以，哪怕是一个json结构。

    由于不管什么结构，最终在代码中都会被解析为对象并缓存起来供接口实现来调用。因此数据库设计在效率上不会要求过高。

 

    数据库结构ER图：

    

 

1.  规则定义和规则利益是独立的两个表，和优惠券、促销活动一对一关联。

2. 规则定义包含：

1. 资格类型、资格配置

2. 利益类型、利益参数（是否累加）

3. 目标范围类型、范围设置

4. 其它字段根据项目状况自由添加。

3. 规则利益

1. 能够对不一样的利益分别设计字段。

2. 也能够设置一个利益类型和利益配置（json结构）

3. 之因此独立出来做为子表，是由于存在阶梯累加的业务状况须要配置多条利益。

4. 优惠券的设计为常规方式

1. 定义：定义它的各类参数

2. 实体：具体某一张优惠券

3. 使用：通常一张优惠券只会使用一次，记录使用历史，也有优惠券能够使用屡次。   

5. 促销活动定义

1. 前面第4节说的促销规则的关系（实际上是促销活动的关系）就是定义在这里。

2. 分组、优先级、对优惠券的排斥等。

6. 促销活动的参与日志

1. 记录谁参与过

2. 有些促销活动只能参与一次，则经过此表判断。