我和我的同事在过去的两个小时中一直在聊天，试图为设计与客户购物篮的新在线商店设计的最佳方法，我'我仍然不确定我们是否得出很好的结论。
这听起来像是一个相当基本的问题，但是我们发现系统的不同部分之间实际上存在很大的相互依赖性。
零件（到目前为止！）是：
- 购物篮（跟踪客户选择购买的产品）。
- 交易（定义诸如" x以20英镑的x购买3"或"购买2的X和1免费1"的产品的促销）。
- 低订单费（根据一定价值，将额外的费用添加到订单中）。
- 运输费（基于一系列选项）。
- 代金券赎回。
- 客户信用（客户可能会在其帐户上获得信用，这将从订单总计中减去）。
我对所有这些对象相互交谈，并从彼此中获得价值，然后对这些价值观行事非常紧张。我想象它会变成一个大型，复杂，无与伦比的纸牌屋。
我敢肯定，让我的系统的不同部分直接彼此交谈是不好的，更不用依靠其他部件运行时在不同状态，如果他们都可以互相交谈，我无法确定我没有改变我所依赖的其他事情。
但是有很多例子，我看不到其他任何方式。例如：
- 当客户在篮子里用X签出时，需要将Y产品添加到篮子中。因此，有效地交易并影响了篮子。
- 确定是否申请低订单费是基于篮子中产品的价值，但是在多型折扣之后（例如，2的价格为3）。因此，它需要查看篮子，同时还要考虑交易。
- 篮子还需要在客户浏览网站时显示总价值，总计应考虑与产品相关的交易，但没有其他考虑。
我该如何实现此类事情，而不必在脚上射击自己并编写可能以意想不到的方式影响其他代码的代码？
看来您有以下抽象实体：
- 篮子
- 交易
- 费用（低订单，运输）
- 信用（代金券，未偿还信用）
您可能可以将这些概念包裹在单个业务逻辑类中，该类别使用许多网关来访问混凝土模型。乍一看，业务逻辑看起来是"将任何交易添加到篮子，应用任何费用，然后兑换任何信用选择"。这些组件中的每一个似乎都是装饰师的集合，每个组件都有可能在篮子上起作用。
在这里占用每个网关（交易，费用，信用）并在其各个组件上进行迭代是业务逻辑类的工作。每个组件将通过篮子，并询问是否应该影响它。如果应该影响篮子，则应应用效果并可以继续进行迭代。
以这种方式，业务逻辑被保存在一个地方，从而定义了操作顺序。每个组件通过业务逻辑松散地耦合了篮子。
更新：一种可能的方法。