Django and project/application organization

I'm just beginning to learn Django and am a little confused on the best way to layout and organize a project and applications. From my understanding, a project is your site as a whole and applications are the pieces that make up that site?

For a first project I am making a small e-commerce type site which will have users, items, etc... So should I have "users" and "items" applications? What about the smaller parts that would go along wit开发者_JAVA技巧h those like user registration/logging in, tags for items, comments for items? Should user authentication, tagging, and commenting be separate applications as well?

Basically I am having trouble on wrapping my head around the concept of what an application is and when to separate different use cases into separate applications while keeping everything manageable and DRY.

Ignacio is right in pointing out that some of the applications you mention already exist. You should also look at projects like Pinax for other pluggable apps that can be a starting point for your own project.

Now to your question: A Django project is a collection of Django apps - that part you got right. The Django book defines it better:

"A project is a collection of settings for an instance of Django, including database configuration, Django-specific options and application-specific settings."

The django book defines a Django app as:

"A bundle of Django code, including models and views, that lives together in a single Python package and represents a full Django application."

But in a recent class with Jacob Kaplan-Moss I understood (mind that I'm not saying that is what he said!!!) that a Django App is all about encapsulating common well defined behavior. I also understood that having many small apps is OK - better than having one monolithic app that does everything - and that some apps are just there to provide templates, some just models, some a complete collection of templates, models and views.

Most of my projects - which are internal facing apps for our company - have a common pluggable app internally developed that is pretty much a collection of templates, css, javascript, etc; that tie the projects together with a common look and feel. I have no views or models in that pluggable app.

I have one pluggable app, also internally developed, that houses a bunch of models that are shared between multiple projects. The models represent common database tables that are used by several different apps and having them duplicated in each of the apps would violate DRY.

Some good example of apps:

• authentication (Django already has a standard authentication app)
• gravatar support (Pinax has it)
• tagging (Several options available, Pinax has one)
• helpdesk (we developed one internally)

All of the above are tackling one logical problem. They don't try to be a do-it-all solution... The Gravatar app doesn't provide OpenID support (there is another app for OpenID), and my helpdesk internal app does not provide authentication (it uses the default django app for that).

A bad example of a Django app would be one that implemented authentication, openid support, helpdesk, and project tracking. Why would that be bad? Because now if you want to reuse your authentication app you have to extricate some models, some views, some templates from your all-encompassing app. If you decide that OpenId support is a must for your next project, you will have to go through the code of this behemoth of an app and find out what parts are relevant.

A good Django app provides one logical set of operations and does it well.