What is the best way to fragment a Django project into apps?

Question

I’m doing a study project to apply what I’ve learned so far with Django. My question is: what is the best way to segment the project in apps? If you want to give an example so that something empirical is captured, let’s say that the project is from a library, where there will be books, authors, employees, where those who wish can through a register register the books, etc. How would you divide this project into apps?

Answer 1

It is not possible to answer in a generic way, as it depends much more on the domain being modeled, as well as its objectives with the project.

At first, it’s okay to have one app for the entire project. If your models.py is getting too big, you can break it into smaller files. The same goes for the views.py, etc.:

app
|- __init__.py
|- urls.py
|- admin.py
|- models
|  |- __init__.py
|  |- a.py
|  |- b.py
|  |- c.py
|- views.py

If you do this, yours models/__init__.py should import all others so that Django finds his models:

from .a import *
from .b import *
from .c import *

And each model of these sub-modules must have a class Meta indicating what your app (Source: that answer in Soen):

class Livro(models.Model):
    ...
    class Meta:
        app_label = 'minhaapp'

Whether or not this is good practice is debatable. But it is a possibility.

And when to use apps is definitely better?

1. When do you intend reuse part of the code in another project, and part of it does not; a app can be redistributed separately from the rest, and used in another context to compose another system.

   If you believe that one day you may want to develop a software for a bookstore, where there are still books, authors, etc., but there you do not lend books, but sell, then it is worth putting the specific features of the library (user register and register book) separately from those which simply catalogue books.

   Similarly, the code you write to manage employees can be useful in even more contexts, so it’s worth having a app separate for that too.

2. When there’s a dependency hierarchy clear. At first, nothing prevents the app A depends on the B, and the B also depends on the A (for example, a model of A has foreign key for a model of B and vice versa). But this brings a certain headache when it comes to making the Imports, or when deciding which app include first in settings.py. If the models are strongly coupled, best to leave everything in one app only...

   But if you can identify a set of models that only depend [at most] on each other, and no more, and another distinct set that depend on each other and some models of the first set, etc., it is more organized to divide them into two apps where the first is addiction to the second. Creating and maintaining a simple hierarchy you even force yourself to keep your project organized and, whenever the "temptation" to introduce a reverse dependency arises, you find yourself obliged to rethink your design. It takes more work, yes, but the end result pays off (the maintainability of the project becomes easier).

In the absence of other restrictions, you can make other divisions more or less arbitrary by following only your feeling. If a app has too many models, for example, you may want to divide it to facilitate the organization. Or if two models appear to belong to sufficiently different domains (e.g.: books vs. employees), you may want to separate them, although there are few models in total (one can even create apps without none model - only with auxiliary code, views for example, or also commands). These are some criteria, but there could be others. You can not even list all situations, but the two criteria above should already give a good guide.