If you’re coming to Django from other frameworks, I’ll start out by saying Django is different. If those other frameworks were not Python-based, Python is different. A lot of what you may have previously learned from structuring projects for other frameworks and languages is not particularly useful with Django.
<opinion>
Personally, I think you’ve way overcomplicated this as a starting point.
Unless, and until, you’ve reached a point where this type of organization becomes necessary, and, you understand why, and you’re prepared to handle the issues encountered by doing something like this, I would encourage you to adhere to the standard Django conventions.
e.g.:
project/
├─ project/ # Can be renamed to anything desired
├─ wsgi.py
├─ asgi.py
├─ urls.py
├─ settings.py
├─ fixtures/
├─ app1/
├─ models.py
├─ views.py
├─ urls.py
├─ forms.py
├─ admin.py
├─ templates/
├─ app1/
├─ management/
├─ commands/
├─ static/
├─ app1/
├─ static/
├─ templates/
And, if the project gets large enough, the directory structure for app1 can be replicated for an app2 and possibly more.
</opinion>
I’ve been using Django regularly for 10 years, and have deployed more than 20 production instances of different projects. I can only think of 3 of them where it has been necessary or desirable to create them as more than 1 app. Also, I’ve never encountered a situation where it has been desirable to use anything other than the standard Django project layout.
Don’t make things harder for yourself. Don’t add unnecessary complexity. Issues like this:
simply don’t exist if they’re all part of the same application.
For some other perspectives on this topic, see:
Note, a couple of these are quite lengthy. I would encourage you to read them through in their entirety.