为什么在域模型中以不同的方式表示购物车和订单发票？
我过去构建过一些购物车系统，但我总是将它们设计为最终的订单发票只是一个被标记为“已购买”的购物车。在购物车中添加/删除/更改商品的所有逻辑也是订单的逻辑。所有数据都存储在数据库中的相同表中。但这似乎不是设计电子商务网站的正确方法。有人可以解释在域模型中将购物车与发票分开的好处吗？
在我看来，这会导致大量重复的代码、数据库中的一组额外的表，并且如果系统需要开始容纳更复杂的订单（例如为某个项目指定选定的选项），则维护会变得更加困难。可能会或可能不会更改订单的价格/供货情况/发货时间）。我假设我只是还没有看到光明，因为我看到的每一本书和其他例子似乎都将这两个看似相似的问题分开——但我找不到任何关于这样做的好处的解释！在我设计的系统中，也经常在初始订单确认后进行更改。事后（但在履行之前）删除、替换或添加物品的情况并不少见。
I've built some shopping cart systems in the past, but I always designed them such that the final order invoice is just a shopping cart that has been marked as "purchased". All the logic for adding/removing/changing items in a cart is also the logic for the order. All data is stored in the same tables in the database. But it seems this is not the proper way to design an e-commerce site.. Can someone explain the benefit of separating the shopping cart from invoices in the domain model?
It seems to me this would lead to a lot of duplicated code, an extra set of tables in the database, and make it harder to maintain in the event the system need to start accommodating more complicated orders (like specifying selected options for an item which may or may not change the price/availability/shipping time of the order). I'm assuming I just haven't seen the light, as every book and other example I see seems to separate these two seemingly similar concerns -- but I can't find any explanation as to the benefit of doing such! It's also the case in the systems that I design that changes are often made after the initial order is confirmed. It's not uncommon for items to be removed, replaced, or added afterwards (but prior to fulfillment).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我正想争辩说，至少保留这种差异是好的，这样发票就不会改变，只是读到你的评论，事实上在你的情况下，发票往往会改变？我想说，在那个阶段，它们仍然类似于“订单”，而不是真正的发票。将它们分开的原因之一可能是您的购物车将引用可能会发生变化的产品，而您不希望发票引用可能会发生变化的产品（导致在查看产品时描述不同的产品）发票与创建发票的日期/时间相比）。
通过使用接口和/或继承，您应该只能对共享函数进行一次编程，但仍将发票和购物车分开。
I was just about to argue that the difference would be good at least to keep it so that an invoice is not changeable, only to read your remark that in fact in your case invoices tend to change? I'd say at that stage they are still something like an 'order' and not actually an invoice. One of the reasons to make them separate items might be that your shopping cart will have references to products that are subject to change while you don't want your invoices to reference products that might change (leading to a different product being described on reviewing the invoice compared to the date/time the invoice was created).
By using interfaces and/or inheritance you should be able to program the shared functions only once, but still keep invoices and shopping carts separate.
我喜欢将其视为代表真实商店中发生的情况，在那里您有一个购物车，其中包含所有产品、选项、优惠券和有关您想要购买的其他信息。
订单代表有关订单的信息...付款方式、交易信息等。这只是“这里是有关我如何购买购物车的所有信息”的表示。这是您在收银机和付款时提供的所有信息。
我发现这是决定什么去哪里的简单方法，并提供了一个关于现实世界相关性的很好的模型。
I like to think of it as representing what happens in a real store, where you have a cart with all the products, options, coupons and other info about what you'd like to purchase.
The order represents the info about the order... payment method, transaction info, etc. This is just a representation of "here is all of the info about how I purchased a cart". Its all the info you provide when you go to the register and pay.
I find this to be an easy way to decide what goes where, and provides a nice model of what a real-world correlation might be.
在您的场景中，我认为您不想实际更改记录，而是对其应用更改。所以你会有表明价格变化的记录。例如，如果加密狗的价格从 10 美元更改为 15 美元，那么您必须添加一条记录，指示价格更改为 +5 美元。
分离记录和复制的目的是确保 POS（销售点）的数据与现在相同。如果不是，那么您可以轻松查看定价发生了什么变化以及何时发生变化。
假设您发布了一个 25 美元的小部件 B，并附有说明，说明它有一个 Z-Dongle。后来您从制造商那里得知它有 X-Dongle，而不是 Z-Dongle，因此您需要降低价格。在您发布错误和更正错误之间，已经有人以 25 美元的价格购买了上述 Widget。
该客户在发现 Z-Dongle 缺失后致电，希望退货并获得全额退款。但现在他们的记录显示，他们使用 X-Dongle 购买的产品比最初支付的价格低了 15 美元。客户服务代表告诉他，描述清楚表明它有一个 X-Dongle - 现在怎么办？
In your scenario, I don't think you want to actually change the record but rather apply changes to it. So you would have records indicating a price change. For instance if the price of a dongle was changed from $10 to $15, then you would have to add a record indicating a price change of +$5.
The whole point of separating out the records and duplicating is to ensure that the data at the POS (point of sale) is the same as it is now. If it isn't, then you can easily see what changes have occurred to the pricing and when.
Say you have posted a Widget B for $25 with a description stating it had a Z-Dongle. You later hear from the manufacturer that it has an X-Dongle, not a Z-Dongle, and as a result you need to lower your price. Between the time it took you to post and correct the error, you've had someone buy said Widget for $25.
That customer then calls up after discovering the absence of Z-Dongle and wants to return and get a full refund. Except now you have their record showing that they bought a product with X-Dongle for $15 less than what they originally paid. The Customer Service rep tells him that the description CLEARLY states it has an X-Dongle - now what?
考虑性能和订单转化率：
集中存储数据可能会导致大量死锁。想想看：当客户将商品放入购物车或只是查看购物车的商品列表时，我们的履行人员正在处理一些订单- 修改、物流、分配工作等，这可能会导致死锁。
高并发和低订单转化率会导致更糟糕的情况。
Considering about performance and order conversion rate:
Intensively store data may cause a large number of deadlock.think about this: when customers are putting goods into their carts or just view goods list of their carts, our fulfillment staffs are processing some order-modify, logistics, allocation jobs etc. This may lead to deadlock.
high concurrency and low order conversion rate will make a worse situation.