Best Django project structure?

Question

Django

Problem
I can't figure out what is the best structure in Django projects. Googled, but everywhere everyone writes differently with the addition "not the fact that this is 'correct', but I do it this way ...". But I would like to understand once and for all what is the correct, flexible and most logical structure in Django projects?

What have I tried?
I’ve been studying Django for 3 months already using Dronov’s 2021 book, and there the structure is something like this:

root_folder/
--.git/
--my_project/
----my_project/
----app_1/
----app_n/
----static/
----template/
----media/
----db.sqlite3
----manage.py
--venv
--.gitignore
--README.md
--requirements.txt

What problems did you have to face?
But, using such a structure, I ran into a number of problems:

• When there are many applications, it becomes very difficult to navigate the project folder. Does it make sense to put them in the apps folder?
  
• Where to store the shared code? For example, common models, common templates, common static files, common common Python code (some functionality, own libraries, if any)?
  
• What is the right way to work with settings.py? I saw examples where the file was replaced with the settings/ package, which contained the dev.py, prod.py, base.py modules. But these were all subjective opinions, I hope I won’t offend anyone, know-name developers. Is there a so-called best practice?
  
• Also, due to my inexperience, it is not entirely clear to me where to include the functionality that does not belong to any application in the project, but which is small enough to make it into a separate independent application? For example, the "Home" and "About us" pages. In one of my projects, these are small pages with minimal logic. And I had to combine them into one main application, although strictly speaking, "Home" and "About Us" are not related to each other in any way, but I had to put them somewhere.
  

What have I come to?
Here's the Django project structure I ended up with. Please rate or suggest a really good and versatile Django project structure. To simplify the demonstration, I did not indicate generally accepted things like urls.py, asgi.py, etc.:

root_folder/
--.git/
--my_project/
----core/
------settings/
--------base.py
--------dev.py
--------prod.py
----apps/
------app_1/
------app_n/
----common/
------template/
------static/
------models/
------any_other_module_or_package/
----manage.py
--venv
--.gitignore
--README.md
--requirements.txt

Answer 1

Answering the question, alas, there is none. You must decide for yourself and not after three months.
But if you want to be more specific, then here are my feelings about your structure, which you came to ...
The first thing that catches your eye is the settings. Yes, you are following the Django ideology, which implicitly whispers to all of us how to compose them: but it is not safe. Why do you have modules in the settings, two of which reflect some kind of environment (development, combat, and something in common between the two)? Based on your structure, the question immediately hovers in the air: "Why should the settings of the combat environment suddenly be in the repository? What about the secret key? Is it safe?". The next logical convenience question is: why should I, as a developer, suddenly have to force my DevOps to build and maintain settings for me in the form of files (modules)? It's an executable file, and there are countless possibilities; Moreover, it is not safe. Now most of the projects are raised using docker-compose, cubers and other delights: it is wildly inconvenient to collect and maintain settings in the form of files for each launched container (we have environment variables, after all). I hope the main message here is clear: security and usability.
( here I did not immediately understand that this is a project, not an application; details in the comments )
Moving on - core . Why exactly this name? Of course, the core, Django does all that in its sources... But when you enter such a project, will it be immediately clear what this application is responsible for? No. In general, even in the documentation for Django in quick start, the name of the application is based on its main business need.
Moving on to the next one: the apps folderwith applications. For starters, everything seems to be convenient and logical: there is a core of the project, but there are additions to it, which means they need to be somehow separated from this core. But what if the core is always the same in the project? But what if there is only one additional application? And why then does he need a whole folder (application) if the application itself is a folder (or a module in our case)? So leave or change the level of nesting? In fact, both core and appN are the same Django applications (the same), which means that they have the same level of abstraction; one level of abstraction tells us that appN should also be placed somewhere near core (there should be a different name here, as I wrote). Often I see in projects that core remains just a single core folder with no further extensibility.
template folder. Here I always trust Django and put the templates in the application folder (making two more folders - templates, and in it - a folder with the name of the application). Here, I think, the rule is to put what is used closer to the place where it is used (but adjusted for the recommendations of the Django documentation).
static folder. In the debugging environment, in principle, it should not be; usually all static is always first of all related to the application, where we try to put it (as with the templates folder), which is also advice from the Django documentation.
models folder. Taking it somewhere different from the application folder, we immediately score on the autonomy of the application itself; the application immediately becomes dependent on external code (which should be avoided). Usually, each application has its own models and does not depend on the models of another application.
venv. Relevant only on the computer of each developer; in my opinion this is a bad decision to put platform-specific files under version control.