0
电子商务促销优惠组件设计25
现在各大电商都有自己的促销优惠方式，满减，立减，折扣，现金券，返现，积分抵现，赠送积分，使用范围也可能是单种商品，大类商品，单笔订单等，优惠环节涉及购买时，订单时和支付时，可谓非常纷繁复杂。
现在我正在开发的电子商务平台有商品Goods和货品Product，有订单Order和订单项OrderItem，我希望能尽量减少与现有功能的耦合，而设计一个尽可能全面覆盖上述优惠促销的组件，并可在以后进行扩展，现在初步有一个设计雏形，但是实际过程中发现还是太复杂，并且不得不开始耦合了，所以决定停工重新整理思路。
希望有能人给点思路和建议问题补充：多谢各位的帮助，感觉还是规则引擎最靠谱，我决定使用规则引擎试试看。问题补充：最佳答案给了第一个回复我的chinaagan，在评论中提醒了我规则引擎，原本我自己写，其实也就是写一个类似的东西，但是肯定没有主流开源的功能强大和专业
2013年2月18日 09:42
h248980496
461
1 1 20
添加评论
关注(2)
6个答案按时间排序按投票排序
00
采纳的答案
如果统一来处理是很麻烦的，跨多个应用边界了，购买、订单、支付多个环节，并涉及不同范围及相应的不同的促销优惠方式。。。根据应用边界拆分成购买、订单、支付环节吧。。。个人意见，如有雷同，纯属巧合
2013年2月18日 10:13
chinaagan
60
0 0 5
- 11条评论
00
去年我们也做过一个类似的促销系统，目的跟你们一样，也是想把促销的内容从现有的平台中解耦出来，可以跟你一起探讨一下，先说下我们的思路吧：
1.提供一个促销管理程序，自己人用，可以在上面添加订单满金额、产品满金额或满数量的一些促销，种类包括立减、打折、买赠、送积分、换购、送券等等，可以设促销地区时间，到时间自动启用停用，也可以设各种促销的档位，满100怎么着满200怎么着，以及是否可以累计。
2.再提供一个促销计算接口，客户进入购物车的时候，调用一下促销接口，把购买的产品ID传过来，计算接口实时算出促销并回传信息。
大体思路就是这样，缺点是促销是实时算出来的，可以应付一下中小型的电商系统，访问量大了肯定会成为瓶颈，如果楼主有更好的思路，我们可以一起改进！
2013年2月19日 09:52
mmhotsky
0
0 1 3
- 添加评论
00
这个问题其实是非常麻烦的，因为涉及到业务太多了。想完全解耦完全是不可能的。说说我的思路吧。
1 首先可以定义出各种促销方式，金额，数量，附赠品等
2 对于某种类型的促销方式，使用的规则是什么。可以自定义一套规则来定义其形式，拿金额来说，可以通过读取数据库拿去指定货品的金额打折方法，然后计算金额，最终得出一个折后的金额。
3 对规则的定义。考虑到不同产品的规则不一样，规则的指定肯定是针对单品来算的。
其实对于我们来讲最终关注的是最终优惠后的金额，所以我们只需要记录处每一项单品的原始价格以，最终价格以及优惠方式即可。这样就可以完全了解整个订单的所处优惠方式以及计算策略了。你所说的订单和订单项，无非是总订单信息和详细订单信息，对应关系应该为1:n，这个完全是不需要做处理的。数据库方面应该添加些字段即可。
关键就是规则的定义，建议你在这方面做一个详细的分析，比如影响规则的纬度，规则定义的范围等等。另外，象携程网的话好像就是出了你这样的类似的一个规则引擎，用于机票和酒店的打折优惠的。这个不好做，但是还是祝你成功。
2013年2月18日 18:34
ieanwfg201
55
0 1 3
- 2条评论
00
优惠改变订单的不外有三种
1.改变数量。
2.改变金额。
3.增加物品——积分，点数，金券或实物等。
我的考虑，订单估计要做两份。
- 原始订单
- 优惠处理过的订单。数量，金额或物品（其他Item）的变化。
优惠引擎，接受原始订单，生成最终订单。
不知道你说的耦合发生在什么地方，优惠引擎依赖订单是必然的，订单部分就不用依赖优惠引擎。
这种单向依赖还可以接受吧？
至于单件商品和整体的计算逻辑在优惠的设计范围内，这里又不会有什么耦合发生的，对吧？
倒是支付，能否使用积分，点数或金券等这些支付逻辑，恐怕要做为订单属性和订单绑在一起的。
举例来说：特价商品不能用金券。
这里有
- 优惠——特价商品。
- 原始订单。
- 优惠处理过的最终订单——总金额减少了，并且被添加了不能用金券的属性。
- 支付时金券被无效。客户需要按最终订单的金额付款。
大致如此，随便聊聊。
祝好运。
1537
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
