目前在开发一个优惠券的功能,卖家可以创建优惠券,买家可以领取卖家创建的优惠券。
api 初步的设想是:
卖家:
创建 POST /coupons
修改 PATCH /coupons/{id}
获取 GET /coupons
现在纠结的是买家的设计,原先的想法是:
领取 POST /buyer/coupons/{id} or {code}
获取 GET /buyer/coupons
如果是这样的设计的话,担心的一个点是,coupons 的概念会不会卖家与买家的混淆了,与之而来的买家优惠券 id 是该取名为 buyerCouponId 这样么,毕竟要与卖家的优惠券 id 给区分开来。
或者买家的 api 是不是可以设计成:
领取 POST /buyerCoupons/{id} or {code}
获取 GET /buyerCoupons
底层表命名的话,应该就是 coupon 表与 buyer_coupon 表这样。
还请各位大佬指点一下。
谢谢。
1
cpstar 2021-09-07 16:41:06 +08:00
/merchant/coupon
/consumer/coupon |
2
shanghai1943 OP @cpstar #1 感谢回复。按您的意思,买家的优惠券 id 的命名就是 consumerCouponId,卖家的就是 merchantCouponId 了吧?
|
3
cpstar 2021-09-07 16:55:11 +08:00
还得考虑这两个 coupon 之间的关联关系
这就是数据库或者系统设计里的『分析实体』,你先弄清楚,这两个 coupon 是不是一个 coupon,是两个独立的实体,还是一个实体派生出的两个实体。 |
4
shanghai1943 OP @cpstar #3 从功能上看,买家的优惠券是从卖家那里领取过来的,设计表结构的时候就是优惠券实体表 coupon,以及买家领取后的关联表 buyer_coupon,里面包含有买家账号 id 和 coupon 表的 id,比如 coupon_id,并且 buyer_coupon 里会记录是否使用过该优惠券之类的信息。
目前纠结的点,买家的优惠券是否可用 buyer_coupon 来表达,卖家创建的优惠券就默认用 coupon 来表达,不知这种方式是否可行。 |
5
cpstar 2021-09-07 17:09:50 +08:00
所以就一个实体呗,coupon,卖家生成,买家领取
那接口岂不就是 生成 COUPON POST /coupon 领取 COUPON PATCH /coupon/{id} 第二个岂不是跟卖家修改一致了?那是一致啊,因为买家的领取,某种意义上是修改了 coupon 的关联关系,与(卖家)修改 coupon 是一种行为。 当然这是建议,如果嫌一个接口,还要区分到底是修改还是领取,很麻烦,那就分开,就是你问题中的思路了。 |
6
cpstar 2021-09-07 17:11:48 +08:00
关于 coupon 的表结构设计,理论上应该三个实体表,COUPON, MERCHANT, CONSUMER,以及两个关联表,COUPON_MERCHANT, COUPON_CONSUMER,但是后两者如果都是 1:1 的关系,可以合并进 COUPON,两个“外键”关联到 MERCHANT 和 CONSUMER
|
7
qfdk 2021-09-07 18:20:36 +08:00 via iPhone
记得 加上 if qfdk isFree
|
9
ieiayaobb 2021-09-07 19:39:32 +08:00
买家,卖家的 id 要区分开来的意图是啥?
|
11
shanghai1943 OP @ieiayaobb #9 主要是为了避免沟通上的歧义。因为买家领了优惠券之后,相当于也有自己的优惠了,那相应的会存在一个优惠券 id 的说法,用于下单的时候指明是消费哪张优惠券。卖家那边创建了优惠券,所以也会有优惠券的 id 这种说法。需要从设计层面去解决这个沟通歧义的问题。
|
12
shanghai1943 OP @cpstar #10 额。这是 v 站的什么隐藏彩蛋吗
|