django_project/top_level_app/second_level_app/
in top_level_app you then could do
from second_level_app.models import model1
or from a different top level app:
from other_top_level_app.second_level_app.mixins import a_mixin
Unfortunately app names have a global namespace within Django's model registry, so we often have to prefix nested apps.
The place where this really works nicely is user facing features and internal editing interfaces, or in features where we have N of a feature that are all similar. For the former, we might have an app such as "blog", and then a nested app within that called "blog_editor". This way we can separate blog models, business logic and user-facing behaviour, from CRUD interfaces designed for internal users. In the latter, if we have 3 shipping providers, we might have an app "shipping" with the core shipping models, with nested apps for "ups", "royal_mail", "dpd", etc, each of which might have the necessary models needed to manage uploading to their APIs, business logic, etc. There may be a common-ish interface exposed by these apps.
This structure is probably the thing I like most about Django over, say, Rails. It's not necessary for all Django projects, but I think it's pretty nice.
I usually organize my apps by having a services layer between models and views, such that the view functions have little to no knowledge about the underlying models.
This, in place of nested apps, I have "upsmodels.py" and "upsservice.py" and the view functions handles routing logic.
