Why represent shopping carts and order invoices differently in a domain model?
- by Todd
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).
