18年我们也做了一个C端，当然非常小，为了扩大一些影响，想着怎么吸引用户，最起码注册一下。C端是卖课程的，每个课程我感觉还挺贵，当然还有一些列不好说的原因。针对这些问题可能做一个送学习金（对，一开始就是想送钱）的功能，会对平台有些促进作用。想着如果用户真领到钱，可能会愿意注册和使用。本着这个目的，设计并开发了一个优惠券服务。
优惠券
对于已经熟悉互联网应用的人来收，优惠券是最常见的东西了。除了一些小商家外，淘宝、京东基本上每天都会有大量的优惠券对外发放，吸引用户抢领并用于消费。但是优惠券并不是互联网发明的，由来已久，它本身是一个商业行为。
我中学时在河南一个县城，周末是有一下午可以出校门的。那个时候偶尔是能够收到街上发放的红色、绿色纸张印刷的促销优惠宣纸；后来在郑州上大学时，在陈寨家乐福商业区附近，经常都能收到一些商家印刷精美的几折卡。这些都是优惠券，可能没有现在淘宝京东的优惠券高大尚，也没那么多人领取，领取了也没那么多人去消费；但本质上和现在互联网的优惠券是相同属性的东西。
对于有交易行为电商来说，优惠券的行为是他们不可或缺的一种功能，在他们运营的体系中承担着重要的作用。从我的理解上看，优惠券的主要作用有：
吸引用户，引流宣传的目的，直白就是广告，广告到位，可能会进一步引流价格和赚钱，会不会是欺骗行为？优惠券究竟给谁才有用？不管是线下的商铺还是电商，他们的目的肯定还是赚钱。如果给大家发放很多优惠券，直接减钱，还怎么赚钱呢？
以前公司附近有一家新疆馆，刚开业那段时间（大约持续了两周），我和一些小伙伴原来每天去吃拉面，但在那两周我们每天都点几个菜，因为那段时间所有消费都是半价。老板的思路很简单，先吸引用户过来，最差也要让周围的群众知道有这么一家店。那么在这段时间就不用顾及是否赚钱了。这种思路也很明白，那电商呢？发那么多优惠券，用户都是进行消费，怎么赚钱呢？
不管这个能否想明白，我们是要做一个优惠券服务的。
分析
考虑优惠券服务的受众群体之前，先考虑一下，优惠券服务的主要目的：为慧读提供一种优惠券服务，能够使得运营对某些资源，发放一个优惠活动，促使C用户注册或者使用，先达到用户积累的目的。
上述中可能和很多网站平台不一样，首要目的是为了做活动，通过活动激励用户使用，从而达到一个非常小的目标：使用户增加。
从这个目的出发，得出慧读优惠券的用户基础：
运营人员、C用户。基本上服务上线后，大部分情况下，应该只有这两种类型的用户。
上图描述了该服务的三种核心对象：
运营、优惠券、C用户。行为如下：
运营人员通过服务创建并上线一个优惠券用户领取优惠券。用户如何领取，目前也没太好的想法，因此当前的优惠券主要功能是挂接在活动中，通过活动促使用户领取；也许更好的是学习电商，首页有提醒，有领券中心比较好些用户领取后，会进行消费，此时运营人员需要参考优惠券的分析、和C用户的领取、消费行为分析，从分析中得到此次优惠券活动的结果数据，为下次的活动做出预测，或者成为数据参考设计
上图为优惠券的业务流，总体上说：包含了
三种角色、两种行为。
三种角色：
运营人员领导C用户运营人员创建优惠券，一般都是送钱，因此需要领导审核，查看预算等。由于资源是数字课程，本身不好分析预算的好坏，预留了审核流程和接口，但本期并没有实现，创建即可自动通过。
两种行为：
创建优惠券领券行为创建优惠券行为，是运营方的主要工作，具体又包含：创建优惠券、审核、上线（即发放的行为）。
领券行为，是用户的主要操作场景。其细分为：查看活动，领券、查看券规则，消费。
数据结构
上图为数据模型的关系。其实就是对现实的一个抽象：商家先印刷张优惠券，之后大街上发给每一个用户，之后用户去商家消费，优惠券作废。
针对这一行为进行抽象，最终形成系统优惠券，当运营创建优惠券后，并设置必备的参数条件，系统优惠券就形成了。当用户通过平台进行领券时，系统优惠券自动与用户绑定，形成了用户优惠券，用户优惠券只是系统优惠券的一个关系，其各种条件均来源于系统优惠券。当用户进行消费时，自动与订单进行关联，最终形成了消费优惠券，此时用户的当前优惠券消亡，完成了整个生命周期。
系统优惠券
优惠券唯一编码优惠券名称，简单直接，可被用户一眼明白优惠券领取条件，属于业务规则生效时间，在本服务中，表示当前优惠券可以使用的起始时间点。但优惠券可以早于该时间进行创建和发放失效时间，表示当前优惠券的最后可用时间点。优惠券面额，单位元。但该属性也不一定必备，为了支持慧读的业务，在系统优惠券做了很多特定业务的处理折扣率。同优惠券面额相同，属于送的钱，满场7折使用条件。在本服务中主要支持时间类型、满额使用、奖品类型。时间、满额减都属于常见类型，奖品类型属于特有业务，在活动中，总会有一些数字课程奖品，此时也通过优惠券形式发放。满额减数值。当使用条件为满额减时，具有该属性，当消费金额满足此数据即可使用外部商品。当使用条件为奖品时，使用该数据关联奖品。优惠券可直接兑换该商品。单人领取类型。个人可重复领取或不可重复领取开关个人可领取数量。当单人领取类型为可重复性领取时，通过该值进行限制用户最多领取数量库存。即该优惠券最大数量，可支持无限量首页提醒。当设置该属性时，优惠券启用后，将首页推送给用户，进行强提醒首页推送图片。一般作为活动运营时，可以制作图片进行强提醒，达到更引人的目的上述中，比较特殊的是奖品和优惠券关联的操作，通过该操作可实现活动中，虚拟奖品的自动发放功能。
用户优惠券
优惠券唯一编码用户唯一标识优惠券领取来源，主要用于记录从那个平台领取优惠券状态。主要分为：可用（领取），已使用，失效（超时），锁定（使用中，该值主要是考虑慧读本身会有一部分实物的奖品，用户消费后，会有一个过程，该值设置后，将不可取消也不可再次使用）消费优惠券
订单优惠券唯一编码用户唯一标识使用优惠券状态，分为：待支付，已使用，支付失败。待支付时，会锁定一张优惠券，如果支付成功，需要更改状态为已使用，同时会将用户优惠券状态设置为已使用，如果支付失败，需要修改状态为支付失败，同时将用户优惠券锁定状态，恢复到可用状态。添加优惠券
添加优惠券功能是最终要的一步，目前的创建功能，基本上和上面的数据结构同步，保持了一对一的属性编辑。当优惠券成功创建后，通过审核，基本上就剩下了优惠券管理功能，无非是一些数据的统计，另外就是可以对优惠券的库存、时效、状态等进行调整。
领取优惠券
对于领券比较简单，就是一个简单的秒杀过程。创建优惠券的时候，依据业务关系，目前慧读只创建-0左右的优惠券，因此需要加锁，服务分布式部署后，采取了redisLock。未抢到锁都直接返回未抢到即可。
优惠券使用
使用优惠券，大部分行为和支付行为绑定了，如几折、满减等。支付的时候选择合适的优惠券即可。对于送钱、奖品，比较特殊。
送钱的话，目前在领取优惠券成功时，直接在后台启用了一个使用优惠券的流程，这个流程和支付流程也是绑定的，是原有支持流程中的一个充值业务。充值时，直接关联了送钱类型优惠券，直接将优惠券面额加入到用户账号。奖品。该功能主要是活动，当活动参与过程中，对于获奖用户，运营人员可以在管理页面中，直接给中奖人员分发一个奖品类型优惠券。此后用户可以使用该优惠券直接兑换商品。