我过去构建了一些购物车系统，但我总是将它们设计为最终订单发票只是一个已标记为“已购买”的购物车。在购物车中添加/删除/更改商品的所有逻辑也是订单的逻辑。所有数据都存储在数据库中的相同表中。但这似乎不是设计电子商务网站的正确方法。有人可以解释在域模型中将购物车与发票分开的好处吗？
在我看来，这会导致大量重复的代码、数据库中的一组额外的表，并且在系统需要开始容纳更复杂的订单的情况下更难维护（比如为一个项目指定选定的选项可能会或可能不会更改订单的价格/可用性/发货时间）。我假设我只是没有看到光明，因为我看到的每一本书和其他例子似乎都将这两个看似相似的问题分开了——但我找不到任何解释这样做的好处！在我设计的系统中，通常在确认初始订单后进行更改也是如此。之后（但在履行之前）移除、替换或添加项目的情况并不少见。
我正要争辩说，至少保留差异是好的，这样发票就不会改变，只是为了阅读你的评论，实际上在你的情况下发票往往会改变？我想说，在那个阶段，它们仍然类似于“订单”，而不是实际的发票。将它们分开的原因之一可能是您的购物车将引用可能会更改的产品，而您不希望发票引用可能会更改的产品（导致在查看发票与创建发票的日期/时间相比）。
通过使用接口和/或继承，您应该能够只对共享功能进行一次编程，但仍将发票和购物车分开。
在您的场景中，我认为您不想实际更改记录，而是对其应用更改。因此，您将拥有指示价格变化的记录。例如，如果加密狗的价格从 10 美元更改为 15 美元，那么您必须添加一条记录，表明价格变化为 +5 美元。
分离记录和复制的全部目的是确保 POS（销售点）的数据与现在相同。如果不是，那么您可以轻松查看定价发生了哪些变化以及何时发生的变化。
假设您以 25 美元的价格发布了一个 Widget B，并说明它有一个 Z-Dongle。你后来从制造商那里听说它有一个 X-Dongle，而不是 Z-Dongle，因此你需要降低你的价格。在您发布和纠正错误的时间之间，您已经有人以 25 美元的价格购买了上述 Widget。
然后，该客户在发现 Z-Dongle 不存在后致电并希望返回并获得全额退款。除了现在你有他们的记录显示他们用 X-Dongle 购买的产品比他们最初支付的价格低 15 美元。客户服务代表告诉他，描述清楚地表明它有一个 X-Dongle - 现在怎么办？
我喜欢把它想象成一个真实的商店里发生的事情，你有一个购物车，里面有所有的产品、选项、优惠券和其他关于你想购买的信息。
订单代表有关订单的信息......付款方式，交易信息等。这只是“这里是关于我如何购买购物车的所有信息”的表示。这是您去登记处付款时提供的所有信息。
我发现这是一种决定什么去哪里的简单方法，并提供了一个很好的模型来说明现实世界的相关性可能是什么。
考虑性能和订单转化率：
密集存储数据可能会导致大量的死锁。考虑一下：当客户将商品放入购物车或只是查看购物车的商品列表时，我们的履行人员正在处理一些订单修改，物流，分配等工作。这可能导致僵局。
高并发和低订单转化率会使情况变得更糟。