引言
在这里,我们设计积分领域,完善总流程。
数据库设计
create table user_credit_account
(
id bigint unsigned auto_increment comment '自增ID'
primary key,
user_id varchar(32) not null comment '用户ID',
total_amount decimal(10, 2) not null comment '总积分,显示总账户值,记得一个人获得的总积分',
available_amount decimal(10, 2) not null comment '可用积分,每次扣减的值',
account_status varchar(8) not null comment '账户状态【open - 可用,close - 冻结】',
create_time datetime default CURRENT_TIMESTAMP not null comment '创建时间',
update_time datetime default CURRENT_TIMESTAMP not null on update CURRENT_TIMESTAMP comment '更新时间'
)
comment '用户积分账户';
create table user_credit_order_000
(
id bigint unsigned auto_increment comment '自增ID'
primary key,
user_id varchar(32) not null comment '用户ID',
order_id varchar(12) not null comment '订单ID',
trade_name varchar(32) not null comment '交易名称',
trade_type varchar(8) default 'forward' not null comment '交易类型;forward-正向、reverse-逆向',
trade_amount decimal(10, 2) not null comment '交易金额',
out_business_no varchar(64) not null comment '业务仿重ID - 外部透传。返利、行为等唯一标识',
create_time datetime default CURRENT_TIMESTAMP not null comment '创建时间',
update_time datetime default CURRENT_TIMESTAMP not null on update CURRENT_TIMESTAMP comment '更新时间',
constraint uq_order_id
unique (order_id),
constraint uq_out_business_no
unique (out_business_no)
)
comment '用户积分订单记录';
create index idx_user_id
on user_credit_order_000 (user_id);
流程图
详细设计
完成奖品分发
功能诉求
我们去完成奖品的一个分发。
在我们发放奖品的时候,每一种奖品他的发放策略都是一种不同的方法,如果我们使用 if -else 进行判断,这样的硬编码是不美的,我们就此可以使用策略设计模式就行改善,提高代码的可扩展性。
功能实现
奖品是有多种类型的实现的,这些实现可以定义为策略。而策略的唯一标识就是奖品表中的 award_key 值,这个值可以作为 bean 对象的名称。那么在拿到奖品ID,反查到奖品Key的时候,就可以获得到对应的 Bean 对象,以此方式来屏蔽 if···else 的判断使用。
就比如上面这个 每一个 award_key 不就是一个 方法策略么
我们实现每一种策略。
主要目的就是计算下积分的值和发奖更新奖品记录,写入用户积分账户。
我们在创建分发奖品的方法,根据奖品id 查询奖品的配置 根据他的 award_key 找到具体的策略,进行执行。
积分兑换商品抽奖次数
功能诉求
我们让用户通过他们获取到的积分 进行 抽奖次数兑换,用这种方法,提高用户的趣味性。
功能实现
首先 我们对于获取这种抽奖次数的操作,都可以称之为一种商品下单,比如说 我们的签到 会给我们抽奖次数 使用积分兑换也会给我们抽奖次数 ,那么,他们都可以称之为 一种 商品 ,也就是 sku 。
之后,这种商品下单 又分成了两种,也就是 有支付交易 下单 无支付交易 下单。
这两种 对应的 就是 使用积分交易下单 (积分兑换)还有 签到 下单(行为返利)。