One of the advantages of django apps is having cleanly divided responsibility. For example, I worked on a large django project that had 70+ apps and several dozen developers. Engineers were encouraged to create new apps for new functionality. In some cases apps could be cleanly pulled out of the code base and converted into a library. The ability to pull libraries out of the "main" repo also meant that certain teams could more easily "own" parts of the codebase. At a different company we actually decided to split our monolith into 3 separately deployed services and it was pretty easy for us to copy the appropriate Django apps into new services.
In general I've found that early in a company's life it is much easier to manage the complexity of a monolith and I've found that Django's app abstraction allows developers to communicate which parts of the codebase shouldn't be overly intimate with one another, which at least gives you a hope of breaking pieces into separately deployable libraries or services as the company/project scales up.
Also over the last few years I've hit multiple schema-migration bugs that only occur on relations spanning apps, and no such bugs within single apps, so there's definitely a "less well-trodden path" argument against multiple apps.
Finally migration squashing didn't work well when I tried it on my multiple-app project; it wasn't able to squash past the first foreign key to another app. This might have improved in the last couple releases.
I've not worked on a project as large as the one you describe, so I'm open to the possibility that at that scale there are new problems that crop up (e.g. managing a single migrations directory could be fun with that many developers), but I'd guess that most developers won't hit that scale, and yet the common wisdom for getting started is to try to split out small apps early, which I consider harmful.
Agreed - I would note that there is nothing stopping you from having good structure (with multiple independent/encapsulated services/apps) inside a single Django "app" (as the OP suggests).
For a detailed explanation of what Django app's are and why they are structured the way they are please refer to the `2. Intro to Django Applications` section of https://medium.com/@djstein/modern-django-part-2-rest-apis-a...
For any new Django engineers reading this, I would point you towards https://github.com/pydanny/cookiecutter-django for the best / most complete structure.
The proposed design does compartmentalize business logic; it's all in the `domain` package, divided by business application/use-case. This looks to be to be inspired by the DDD approach.
> no ability to make new versions of an app and use them concurrently
Anecdotal, but I've never required this in my monolithic web app (6 developers), and I don't foresee requiring it any time soon.
> Removing the battle tested skeleton may mean it is not the web framework for your particular project.
This is a bit dogmatic for my taste; Django is just a tool. If the default layout works for you, great. When your project outgrows that default, change it. (But I'd advise being sure that you really have outgrown the defaults before doing so).
I also think it depends on the project. If your project has 12 apps, you might want to do it around the apps. If it has 3, you might do it around data, domain, and interfaces.
Why data domain and interfaces, btw?
Yes, but this is all configurable/remappable; FTA:
> One last note to add is that this project structure results in fewer INSTALLED_APPS entries. The data/ directory, containing the models, and the interfaces directories, containing templates, static files, management commands, etc., all need to be included as entries.
Related; here's an example of an extreme surgery resulting in a single-file Django app:
Step 0, don't use Django, use Pyramid, unless most of your app is DRF.