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

Question

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

Answer 1

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.

Answer 2

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.