这是一个创建于 221 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
murmur 221 天前
不是有规则引擎么，这么多东西怕是第一个号第一次开所有服务才能享受到，等你以后买就没这么多规则了
|
 |
2
LiaoMatt 221 天前
包装模式, 每次包装减少对应的金额?
|
 |
3
wetalk 221 天前
价格打不过 PDD ，售后和物流比不过 JD
|
 |
4
SoyaDokio 221 天前  1
第一反应：
Naming things is hard, that's one of the hardest parts of programming. -- Linus Torvalds |
 |
5
ZeawinL 221 天前 via iPhone 1
if () {
} if () { } |
 |
6
FYFX 221 天前
看着这个求值顺序应该会影响结果?
|
 |
7
zhao8681286 OP 2
所以阿里还是很牛逼的，你看 PDD 都搞不出这些直接懒得算，便宜多少就卖多少。
|
 |
8
dlmy 221 天前 7
某大厂的处理逻辑：
1 、定义好所有的规则配置，形成基本规则项； 2 、当用户这个请求进入时，动态构建规则链条，该链条负责规则的过滤、筛选和具体选择； 3 、当该请求命中了某些规则之后，会执行对应的逻辑； 4 、把执行结果汇总并包装成一个属于该业务的规则数据对象； 5 、根据这个规则数据对象，进行预扣减，成功就返回结果； 6 、后台发 mq 消息，处理实际的逻辑。 |
 |
9
yuanmomo 221 天前 via iPhone 15
这不是什么好事，对于消费者，压力太大了，得花多少时间去研究，程序猿，测试就更不要说花多少时间在这个上面了。
我在瑞典购物这么久，只遇到过两种优惠券（除了 shein 和 temu ），一种就是直接满减，多少，全场通用；第二种，打折商品能不能用。 规则相当简单，清晰，只需要过去问问这个能不能叠加用就完了，哪里来这么多弯弯绕绕，相反的，这边的开发，测试，花了太多时间在隐私，权限，合规上。 |
 |
10
lichdkimba 221 天前
淘宝京东规则太多了 这个券那个券 这个 VIP 那个立减 有的能叠加有的不能叠加
|
 |
11
jeray 221 天前
管他多少个，策略模式封装好，至于用多少个策略，管他尼~
|
 |
12
dai269619118 221 天前
这逻辑多的离谱了 这样都不出 bug 这程序员真的有点东西
|
 |
13
fruitmonster 221 天前 2
@zhao8681286 哈哈哈，你这逻辑，PDD 便宜是因为 PDD 懒得算，阿里牛逼是因为阿里喜欢算，ahahahahahahhahaha
|
 |
14
flyqie 221 天前 via Android
|
|
15
murmur 221 天前 1
|
 |
16
Jinnrry 221 天前 via Android
我以前就是负责活动、计价的研发。这玩意有什么难的吗？你这里看着一大堆，其实不就“满减”一种类型吗。一般这种优惠本质上就满减，加价购，满赠，代金券，礼品卡这么几种，然后每种优惠可以配使用规则和优先级
运营给商品配上不同类型的优惠规则，计算价格的时候按优先级减金额就行了 |
 |
17
iosyyy 221 天前
不是啥难需求吧 每一步实际上输入都是钱输出不一样而已 做几个不同模式的适配本身都是优惠卷 还好没那么夸张
|
 |
19
wsxzpwps 221 天前
有幸做过这类购物车，重构前，chart.js 有 1.5w 行代码，叹为观止，代码屎香四溢，臭不可闻，然后就重构了 2 个月。
开发、测试、产品都榨干了。 |
 |
20
wu00 221 天前 17
从结果上来看，没那么难；
实际上对大部分公司来说难的一批。 一开始需求上只要求立减券，你会上这引擎那模式吗； 紧接着叠加折扣券的需求来了，“后天要上线哟”； 然后是满减，“上次做折扣券也只用了两天啊，咱先按简单的来” |
 |
21
carpeDiemJll 221 天前
@dlmy #8 大佬，有没有 demo 方案落地代码，挺感兴趣。
|
 |
22
sss15 221 天前 1
liteflow 就是专门处理这种场景的，可以看下 liteflow 的 demo2
https://liteflow.cc/pages/0a8188/ |
 |
24
zxkxhnqwe123 221 天前 2
如果不想用框架，自己写个责任链就行
|
 |
25
worldlist 221 天前
规则、玩法太多，直接把用户赶去其他平台了
|
 |
26
MoYi123 221 天前
不管是写个界面还是搞个 json 配置, 关键是要把任务甩给运营, 这样就算他配错价格了, 也不是你的锅.
|
 |
27
Senorsen 221 天前
所以我用 pdd ，不用减这减那的说不定还更便宜。。脑子都交给上班了，买东西时根本不想动脑子只想花钱。
|
 |
29
mightybruce 221 天前
这个是标准的规则引擎实现的， 然后运营和营销人员只要添加一些规则就能实现这些效果，本身不是开发写死的呦
这些规则也往往鼠标在 GUI 界面上点点就能搞定 比如 java 的 drools 例子 https://www.cnblogs.com/binyue/p/17428268.html |
 |
30
zqfxch 221 天前
开发根据产品梳理出来的价格优惠模型开发就行，比如列举条件和优惠规则（满减，打折等），且这个规则可以随时新增和定义。然后线上运行的时候，各种运营人员（ 88 VIP 会员运营，商家店铺运营，淘金币运营等等）在后台配置对应规则就可以。主要这个规则命中的太多了看起来复杂。
|
 |
31
sxms77777 221 天前
让服务器排列好返给你，我一个 ui 崽给我说这么多
|
 |
32
Fred18 221 天前
这帖子发的 拿我当 GPT 是吧
|
 |
33
1543544726zy 221 天前
简单点，能减钱就直接在优惠里面。搞得消费者有点懵逼，下次不来了。
|
 |
34
wangjunniit 221 天前 10
你在偷窥我？
 |
 |
36
opticalproperti 221 天前
没啥说的，很简单啊责任链，好像是动态链，我一直在用
|
 |
37
Foralrec 221 天前
@wangjunniit 能想出这么多名字，产品跟运营也挺厉害的。会不会以后再来个`优惠整合战役`
|
 |
38
crysislinux 221 天前 via Android
这么多东西，数据库压力怎么样？
|
 |
39
voidmnwzp 221 天前
@wangjunniit 看到这种需求我心里已经问候产品父母几百遍了
|
 |
40
yuzo555 221 天前
系统底层分工明确、逻辑合理的话，这其实不是什么麻烦事情。每个部分处理自己的职责范围就行。
|
|
41
Jinnrry 221 天前 via Android
|
 |
42
me1onsoda 221 天前
淘宝感觉还是有点东西，这么复杂的规则在购物车切换商品计算很丝滑，像在客户端计算一样
|
 |
43
Goooooos 221 天前
从技术上说，并不复杂
就是运营配的券有点多才显得复杂 |
 |
44
lambdaq 221 天前
@wangjunniit 卧槽。
|
 |
45
flyme2them00n 221 天前
还能怎么办？干呗
|
 |
46
ixoy 221 天前
不干人事，卷用户，券运营，卷开发，卷商家，最后把自己也卷进去了。这一套下来得消耗多少社会隐形成本。
|
 |
47
dobelee 221 天前 via iPhone
@Goooooos 其实非常复杂，涉及到不同的商品优惠池子，池子的优先级，有的池子能继承优惠价，有的是用基准价计算，同时池子有商品交叉。最后要算出各个池子排列的最优解。以上要保证高性能，不能用太暴力的解法。下单时又涉及到各个优惠对应的业务线的一致性。然后是另一个最复杂的部分，优惠券的组合结算及退款处理。
|
 |
48
danhahaha 221 天前 2
中国人真累，程序员忙着开发折扣券算法，商家忙着计算如何提价叠加折扣券，消费者忙着计算怎么使用折扣券，这难道就是内卷本卷？本来大家可以很简单的
|
 |
49
Donaldo 221 天前
@yuanmomo #9 恕难苟同。这上面除了跨店的基本都是同一个 if 逻辑，设计好对应的接口，就用不到程序员和测试什么功夫了。至于消费者，不想花精力省钱的大可不参加。本就是一种促销手段，你情我愿的，我很懒，也不差这些小钱，所以我每次都不搞这些，我女朋友就乐在其中，并没有什么压力，反而会有额外的情绪价值。
|
 |
50
agagega 221 天前
结算的时候做一遍不复杂，难的是搞运营的人要把这些优惠的真正力度搞清楚并估测出一个模型，还有就是现在的电商网站都会帮用户预估到手价，这个也挺麻烦的。
|
 |
52
nathanleeinph 221 天前
给运营提供个模拟器和配置器随便玩，反正程序上就是减减减
|
 |
53
HaroldFinchNYC 221 天前
costco 没这么多费劲的规则
只有一个：多少钱 off 说白了，你别扯那么多，就一条：到底现在多少钱！ |
 |
55
xuanbg 221 天前
就是查一下数据库，把能用的优惠都查出来。如果没有那种互斥的，就直接用。有的话，就要按顺序遍历，去掉互斥的数据。
|
 |
56
zfyStars 221 天前 1
这就是我不用淘宝的原因
|
 |
58
daybreakfangyang 221 天前 via Android
作茧自缚
|
 |
59
ixixi 221 天前
看到这种一层一层的套路 实在是够够的了
不打折不搞活动的时候买 总有种冤大头的感觉 |
 |
61
wanqiangcrack 221 天前
这个肯定是用规则引擎啊，谁闲着没事儿天天给他改这玩意儿，不疯了么。
|
 |
62
LowBi 221 天前
绷不住了 头一次见到凑齐这么多劵的，不过不得不佩服后面的工程师，但也挺恶心这样的运营的
|
 |
63
Torpedo 221 天前 1
@Donaldo #49 你想的太简单了。最终这里的逻辑当然简单。但是整个产品逻辑来看，这里面每一张优惠劵都要有配置平台、封控。并且不同优惠券能否叠加、库存等等。
这些需求最终都要堆人的。 |
 |
64
dododada 221 天前
@wangjunniit 😂
|
 |
65
daysv 221 天前
不如拼多多
|
 |
66
chobitssp 221 天前
|
 |
67
superrichman 221 天前
算盘打的啪啪响，最后发现拼多多每一家都比他便宜
 |
 |
69
F7TsdQL45E0jmoiG 221 天前
这个小意思，运营商的计费系统规则比这个复杂太多了
|
 |
70
afxcn 220 天前
简单问题复杂化，太闲了。
|
 |
71
Jancy 220 天前
支付和对账部门估计骂娘了
|
 |
72
nicht 220 天前
怎么保证复杂规则校验 下 性能在 200ms 以内 目前就碰到这种情况 不知道怎么优化，不敢乱改
|
 |
73
leegradyllljjjj 220 天前
求求你别减了，别到时候商家还得给我送东西还倒发钱
|
 |
74
epiloguess 220 天前
我不是做后端的，不过，很多 config 的配置都是出入参类型保持一致，这种思路也能解决这个问题吧
|
 |
75
boqiqita 220 天前
除了立减相对简单些，其他优惠都需要前置流程。估计需要上百人的研发，还要沉淀多年才堆的出来。
|
 |
76
nomytwins 219 天前
阿里规则引擎 QLExpress ，我们用过给产品算计价
|
 |
77
ffeennggg 219 天前
|
Select Language