James Bennett has written a blog entry about this,
Django tips: laying out an application, section "Projects versus applications":
An application tries to provide a single, relatively self-contained set of related functions. An application is allowed to define a set of models (though it doesn’t have to) and to define and register custom template tags and filters (though, again, it doesn’t have to).
A project is a collection of applications, installed into the same database, and all using the same settings file. In a sense, the defining aspect of a project is that it supplies a settings file that specifies the database to use, the applications to install, and other bits of configuration. A project may correspond to a single website, but doesn’t have to — multiple projects can run on the same site. The project is also responsible for the root URL configuration, though in most cases it’s useful to just have that consist of calls to include which pull in URL configurations from individual applications.
I can understand why you have such doubt. Django’s documentation about the application concept isn’t very clear when it comes to how to organize a database / ER model into specific applications.
Let’s say you’re building an API using Django and Django REST Framework (DRF) and your ER diagram has many foreign keys and you’re not sure how applications really work. In that case, I suggest you organize the API code into a single application.
- Django admin add custom filter
- How to use ModelMultipleChoiceFilter?
- Python Django custom template tags register.assignment_tag not working
- Django 2.0: sqlite IntegrityError: FOREIGN KEY constraint failed