Lots of different ways to do this. However, a couple of things before we start.

You (customer) may think you have told me what you want, but in fact, you have told me what you think you want. You will change your mind. I will misinterpret you. You will explain things later on in the process that are totally contrary to what you have explained before. Requirements will change (I'll look up some numbers quoted in some of the classes I took about how large a part of the requirements is actually not or seldom used tomorrow). This may read as kind of condescending towards customers, but it isn't meant as such. We just need to keep in mind that communication is HARD. And you need lots of communication for an IT project.

So, given that requirements will change, it'd sure be nice to have (good, frequent) feedback. That is an important part of the "Agile" methodology of software development. The classical way of developing software is sometimes called waterfall. You make up requirements, you plan, you develop, you test, you deliver. Project over. In processes in line with the Agile methodology you do those same things (albeit maybe differently), but you do them in small pieces. You divide your requirements into 2 week to 2 month (commonly) "sprints", pieces of time in which you go through this process, and thus you get more frequent feedback from your client (you may not ask for testing/feedback at every sprint, again, the key is good communication). A very important thing to remember here, is that there isn't one waterfall or one agile. There are tonnes of processes, some standardized, some adapted to suit individual needs. Experiment, talk to others, find what works for you and your team.

As for the higher-level architecture of your code: read a good book on design patterns. For Object Oriented programming, I like Shalloway & Trott's "Design Patterns Explained". I'm nearing the end of a course on design patterns using this book, and I really enjoyed it.

Disclaimer: This is sort of pieced together from (what I think are) the most important parts of my education (in my third (last) year of Bachelor Applied Computer Science) so far. It is very incomplete.

Bottom line is: you never stop learning. Asking the question you asked here is important. Be curious. Does this last part make me sound arrogant?

EDIT: Wrong link formatting.

Algorithms, Design Patterns, VCS, being familiar with typical CS interviews questions and something that will be really needed

Some Books:

For Algorithms:
http://www.amazon.co.uk/Algorithms-Sanjoy-Dasgupta-ebook/dp/B006Z0QR3I/
http://www.amazon.co.uk/Algorithm-Design-Edition-published-Springer/dp/B00E28CR4I/
http://www.amazon.com/Introduction-Algorithms-Thomas-H-Cormen/dp/0262033844/

Design Patterns:
http://www.amazon.com/Design-Patterns-Explained-Perspective-Object-Oriented/dp/0321247140/
http://www.amazon.com/First-Design-Patterns-Elisabeth-Freeman/dp/0596007124/
http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/
http://www.amazon.com/Design-Patterns-Dummies-Steve-Holzner/dp/0471798541/


Interviews:
http://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/098478280X
http://www.amazon.com/Programming-Interviews-Exposed-Secrets-Landing/dp/1118261364/

I've never used Django so I'm making some assumption here based on my Rails experience. Their feedback is pretty good.

1. You're not using inheritance in obvious places like a WeightedItem and a UnitItem should be children of a parent Item class (or some other better named class). I would put all similar methods in the parent class (item name, description) and then the business logic for calculating the price can go in the children classes. It's possible they wanted the Item class here to be abstract (so you will never have an Item object, only items of the subclasses).
   
2. The Promotion and Coupons implementation feels odd to me, maybe someone else can comment on it though. I've never designed a checkout app so I haven't really thought about it but it seems that there must be a better way to handle this.
   
3. They are correct in that your controller/views should not handle much business logic at all, controllers are just for using the parameters from your views and the data from your models to route what gets show to the user, what gets stored in the backend, etc. If you're putting business logic in a controller that's usually a sign that you need another model.
   
   ​
   
   cart_items = CartItem.objects.all()
   total = cart_items.aggregate(Sum('price'))['pricesum'] or 0
   coupons = Coupon.objects.filter(total_spending_thresholdlt=total)
   
   

   Apply coupon if necessary
   

   if request.method == 'POST' and request.POST.get('coupon', '') != '':
   total -= Coupon.objects.get(pk=request.POST['coupon']).discount
   
   All of this should certainly be in a model. You might want a Cart model that holds Items. The Cart would then have a method you call total_price that would do the calculation inside that model and the controller would simply access that data.
   
   A Cart could also hold coupons and discounts too in whatever implementation they end up being.
   
   I would rework this controller quite a bit, I would create new routes so you have a `cart' controller with a 'reset' route separate from the 'checkout' route, no need to send those requests to the same controller action and use an IF statement to determine where to send it.
   
   So really your checkout action should basically be
   
   context = {
   'items': cart.items,
   'total': cart.total_price,
   'discounts': cart.discounts
   }
   
   return render(request, 'checkout/index.html', context)
   
   Having an action 'unitItems' that sits under the route 'checkout/unit_items.html' that isn't used for actually checking out is a bad design choice. If this view is used to view an individual item, just have it be its own path like '/items/item_description' or whatever.
   
   Same goes for 'addUnitItemToCartItems', this should just be a simple 'Cart.addItem(item)' line of code in your controller and then all the business logic goes in your Cart class. You could either return an error from that method or have something like Cart.errors that you check after (not sure what the best practice is in Django).
   
   Also you'll see the advantage of designing everything the way I told you is you will only need a single "addItemToCart" action and only a single "viewItem" action, no need to duplicate your code to handle for weighed/unit priced items. Any of those logical differences will occur in the classes which won't matter to the controller because they will all share the same interface that they inherit from the abstract parent Item class.
   
   My advice to you would be to get this book Design Patterns Explained. It's a bit expensive and "old", but the design patterns in it are timeless and get you thinking in the right way for OOP design. Another book that was hugely beneficial for me was Practical Object-Oriented Design in Ruby, but if you're focusing on Python maybe you can find something similar in that realm.
   
   My biggest tips for you would be 1. if you're repeating code like you did several times in your unitItems vs weighedItems implementation, then it's time to stop and figure out how you can DRY it up (Don't Repeat Yourself) 2. Models are for business logic, views/helpers are for display, models are for business logic.

Great advice, totally agree.

I think it's a mix of experience and knowing what is possible to make. The book that helped me is Design Patterns Explained, by Allan Shalloway and James R. Trott. It's not really game-oriented, but it's about programming, so I definitely use patterns described there. They also give explanation on UML diagram and try to answer the question you've asked, "How does one design code"

For a design patterns book I prefer Design Patterns Explained. I've heard the same thing about patterns being a kludge for non-functional languages. I'd love to find an article that goes through the patterns and shows examples for each how first class functions make them unnecessary.

Design Patterns is the de facto standard, although Design Patterns Explained is probably better as an introduction.

To clarify, you mean this right?