Why represent shopping carts and order invoices differently in a domain model?

I've built some shopping cart systems in the past, but I always d开发者_开发百科esigned 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).

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.

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?

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.

Considering about performance and order conversion rate:

1. 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.

2. high concurrency and low order conversion rate will make a worse situation.