python – What's 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 into apps ? If you want to give an example so that something empirical can be captured, let's say the project is a library, where there will be books, authors, employees, where those who wish can register the books through a register, etc. How would you divide this project into apps ?

Answer:

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

In principle, it's okay to have a single app for the entire project. If your models.py is getting too big, you can break it into smaller files. The same goes for views.py , etc:

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

If you do, your models/__init__.py should import all the others so that Django finds your models:

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

And each model of these sub-modules should have a Meta class indicating what your app is (Source: this answer on SOen ):

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

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

And when is using apps definitely better?

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

   If you believe that one day you may want to develop software for a bookstore, where there are still books, authors, etc., but books are not loaned there, but sold, then it is worth putting the library's specific functionalities (user register and register book) separately from simply cataloging the books.

   Likewise, the code you write to manage employees can be useful in even more contexts, so it's worth having a separate app for that as well.

2. When there is a clear dependency hierarchy . In principle, nothing prevents app A from depending on B , and app B also depending on A (for example, a model from A has a foreign key to a model from B and vice versa). But this brings some headache when doing the imports , or when deciding which app to include first in settings.py . If the models are tightly coupled, better leave everything in one app …

   But if you can identify one set of models that only depend [at most] on each other, and none else, and another distinct set that depend on each other and some models in the first set, etc., it's more organized to break them down in two apps where the first is a dependency for the second. By creating and maintaining a simple hierarchy, you even force yourself to keep your design organized, and whenever the "temptation" arises to introduce a reverse dependency, you are forced to rethink your design. It takes more work, yes, but the end result is worth it (the maintainability of the project is easier).

In the absence of other restrictions, you can make other more or less arbitrary divisions, just following your feeling . If an app has too many templates, for example, you might want to split it up for easier organization. Or if two models seem to belong to sufficiently distinct domains (e.g. books vs. employees), you might want to separate them even though there are few models in total (you can even create apps without any models – just with helper code , views for example, or also commands). Those are some criteria, but there could be others. It is not even possible to list all situations, but the two criteria above should already provide a good guide.