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