面向对象的结账流程设计

Question

我和我的同事在过去的两个小时里一直在谈论，试图找出最好的方法来设计我们新的网上商店的方面，处理客户的购物篮，我仍然不确定我们'得出了一个很好的结论。

这听起来像是一个相当基本的问题，但我们发现实际上系统的不同部分之间存在着巨大的相互依赖性。

部分（到目前为止！）是：

• 购物篮（跟踪客户选择购买的产品）。
• 优惠（定义产品的促销活动，例如“以20英镑购买3个x”或“购买2个x并获得1个免费”）。
• 低订单费用（在特定价值下，订单中会增加额外费用）。
• 运费（基于一系列选项）。
• 优惠券兑换。
• 客户信用（客户可能会在其帐户中获得信用，这将从订单总额中扣除）。

我非常担心所有这些物体彼此交谈并相互获取价值，然后根据这些价值观行事。我想象它会变成一个庞大，复杂，难以维护的纸牌屋。

我确信让我的系统的不同部分直接相互交谈是不好的做法，更不用说允许它们改变彼此的状态（无论他们如何做到这一点），因为系统的一部分结束了当他们跑步时，他们依赖处于不同状态的其他部分，如果他们都可以互相交谈，我无法确定某些事情没有改变我依赖的其他部分。

但是有很多例子让我看不到任何其他方式。例如：

• 当顾客在购物篮中用X结账时，“购买X，免费获得”这种交易需要将Y产品添加到购物篮中。因此，交易有效地看起来和AND影响篮子。
• 确定是否应用低价订单是基于购物篮中产品的价值，但是在购买多折后（例如2的价格为3）。因此，它需要查看篮子，同时还要考虑交易。
• 当客户浏览网站时，购物篮还需要显示总价值，并且该总额应考虑与产品相关的交易，但没有别的。

我怎样才能实现这样的目标，不会让自己陷入困境并编写可能会以意想不到的方式影响大量其他代码的代码？

Answer 1

您似乎有以下抽象实体：

• 篮
• 交易
• 费用（低订单，运费）
• 信用（凭证，未偿还信用）

您可以将这些概念包装到单个业务逻辑类中，该类使用多个网关来访问具体模型。乍一看，业务逻辑似乎是“将任何交易添加到购物篮中，应用任何费用，然后兑换任何信用选项。”这些组件中的每一个似乎都是装饰器的集合，每个装饰器都有可能作用于篮子。

这里的业务逻辑类的工作是采用每个网关（Deal，Fee，Credit）并迭代它们各自的组件。每个组件都将通过篮子并询问是否应该影响它。如果篮子应该受到影响，应该应用效果并且迭代可以继续。

通过这种方式，业务逻辑保存在一个地方，定义了操作的顺序。每个组件都通过业务逻辑与篮子松散耦合。

更新：A possible approach。