促销系统业务模型 - 1

什么是促销业务

在淘宝、京东、美团的商品页面上，往往会有逻辑复杂的优惠项，比如单纯的折扣，或者满件赠、满额赠等。复杂的优惠事项可以实现精准的筛选——有钱的客户一般没有时间，也就没有机会拿到优惠，从而赚取更多的钱；没钱的客户对价格更加敏感，也就更有时间和精力研究优惠项，从而获取更多优惠。这样，无论贫穷或富有，都能将货卖出去，赚取对应的成本。

然而这一套规则过于复杂，光靠一个单一的商城系统加模块是无法维护的，因此需要在后台新建一个促销管理模块，由运营填充促销相关信息。

领域模型设计

活动模型设计

一项优惠活动应该关注哪些维度呢？

促销活动领域核心的操作单元是促销品，从实际业务场景来看，无论是业务场景还是消费者最终面向的都是促销品，运营投入的补贴、设定的限制、指定的规则以及消费者最终享受的优惠，实际都是作用在促销品上。围绕促销品，不同的角色有不同的关注点，消费者更多是关注省了多少钱（优惠了多少），运营更多是关注花了多少钱（补贴了多少），同时辅以限制和门槛来保证一定的企业营收和业务增长。

结合上述分析，以促销品为核心抽象促销活动领域的关键几个领域概念：补贴、限制、门槛、优惠、促销品（商品、虚拟卡等均可以被称为促销品）。

最终领域图如下

限制

限制是参加促销活动的准入条件，通过限制决定谁来参加，只有符合促销活动准入条件才有资格享受促销优惠

• 渠道：通过什么方式查看促销的，如APP、微信/支付宝小程序、网页等
• 区域：门店维度或者城市维度。用于区分该活动是全城市通用还是特定的门店通用
• 时间：单次活动，或者是一周固定时日生效，或者是一天固定时间段生效
• 客群：不同的客人显示不同的优惠，如新客往往优惠幅度更大
  • 普通客群，分为新客、幸运客或普通客人
  • 会员，分为老客与新客

门槛

达到限制条件后，通过门槛来决定顾客应该怎么参加活动。只有符合促销规则的条件才能享受优惠

• 无门槛：无门槛也是一种门槛，没有任何限制
• 数量：满X件
• 价格：满X元
• 第N件

优惠

满足限制与门槛后，用户可以享受到的优惠

• 特价：多个SKU总价优惠或单个SKU价格优惠
• 折扣
• 减额：总金额减免价格或每个SKU都减免一定价格
• 赠品：更关注能免费送几个
• 换购：更关注多少钱换购

补贴

促销活动是要花钱的，这笔钱该谁来出？这就是补贴需要关注的问题

• 预算承担方补贴
• 供应商补差补贴

促销品

促销品有两类，一种是参与品，一种是促销品，门槛作用在参与品上，优惠作用在优惠品上，即购买参与品到达一定门槛后可以享受优惠品的优惠。一个促销的规则，就基于门槛和优惠。

促销活动的各种玩法的实现在于门槛和优惠的组合方式，复杂之处也在于多种门槛和多种优惠的组合。门槛和优惠组合才能决定一种促销玩法，两者存在强关联关系。

graph TD
sku((参与品))
gift((优惠品))
barrier[门槛]
offer[优惠]
rule((优惠))
sku-->barrier-->rule
gift-->offer-->rule

校验模型设计

一个已上线的促销系统，一般有很多种类型，二十多种到三十多种不等，每种类型创建时都要做合法性校验，但不同类型的检查规则是不一样的，怎么设计才能保证不乱呢？

促销活动校验规则项是相对不变的，但是相同校验规则项是基于不同促销活动类型有不同的规则实现。例如优惠品的数值上限这一字段，一口价允许50个，但秒杀只允许20个。

因此不太好给每种促销类型写一套促销代码，而是

1. 所有类型共享同一份检查清单
2. 如果某个类型不需要某条检查，就把那条检查的开关设置成 false
3. 如果某个类型需要不同的阈值，就在配置里给这个类型设置它自己的数值

然后具体的校验行为由各个领域对象的校验器来执行，比如折扣力度的检查对象只管拿到数据去比大小，不关心这个值是一口价的还是秒杀的。配置的单个规则项如下（-1 表示不受限）

{
    "ruleName": [
        {
            "source": -1,
            "promotionTypeList": [1],
            "value": "15"
        }
    ]
}

可以看到这里也对来源做了处理，用于保证同一活动统一规则在不同来源下处理的粒度区分。比如同是一口价活动，通过外卖渠道和线下店渠道的校验规则就不一样。各个规则项——如限制条件、补贴配置、参与品、促销规则、价格倒挂、POP配置、线下门店校验等——的校验行为由其所属的领域对象来完成，通过领域服务来编排各个领域对象。

该架构在未来可能还会出现更多维度组合。与其每来一个新维度就修改配置结构，不如直接引入“场景”这个抽象概念，比如出清秒杀场景、外卖渠道促销场景等。单个规则项可以基于不同的场景由不同的配置值来支持差异化。校验行为本身并不需要感知场景，校验器本身拿到的始终是已解析好的检查清单，场景和校验本身之间完全解耦。

由于校验事项复杂，可能校验失败的原因较多。为了一次性能将所有的错误原因列出，就需要互斥叠加这一步骤。此处需要注意有哪些场景下的校验是是可以略过的，可以直接return，否则需要抛出异常，在互斥叠加中处理。

活动自动机设计

任何一个需要审核的定时活动（包括大学活动管理，包括会议室预订），其活动状态都可以按照如下状态机流转

其审核活动可以分为四种状态

营销业务拆分

除了单纯的促销，像美团外卖、饿了么之类的外卖平台，还有大量的优惠券服务，这些和这里电商的营销业务一起可以统称为营销业务。这么大一个服务，应该如何划分呢？以下是一种可能的方式

• 营销服务，负责制定促销活动玩法
  • B端后台服务，用于给运营提供接口，以及给其他服务提供接口服务
  • C端客户服务，用于给APP、小程序等提供优惠信息
• 优惠券服务，负责制定优惠券活动玩法
  • 优惠券管理服务，用于优惠券的库存管理，算价和基础CRUD服务
  • 优惠券离线服务，用于运行在指定时刻发优惠券，进行过期提醒等与时序强相关的业务
  • 券活动服务，用于针对不同的活动需求发放不同的优惠券
• 礼品卡服务，负责制定礼品卡服务的具体逻辑
  • 礼品卡B端服务，用于给运营提供礼品卡制作和管理等服务
  • C端客户服务，用于进行实体卡激活、核销、绑定等功能
• 提报服务，针对B端，指供应商或运营将商品提交到活动的过程
• 盘货服务，针对B端，指采购或运营针对商品进行盘点、确定活动商品清单的过程
• 选品服务，针对B端，指给不同品类划分种类，从而提供不同服务，如进行特定活动（如双十一）、热卖榜单等。其作用可以看这篇文章
• 库存服务、用户认证服务、门店服务等服务需要按照具体需求来定