Each “application” should be small — a single reusable entity plus a few associated tables. We have about 5 plus/minus 2 tables per application model. Most of our half-dozen applications are smaller than 5 tables. One has zero tables in the model.
Each application should be designed to be one reusable concept. In our case, each application is a piece of the overall site; the applications could be removed and replaced separately.
Indeed, that’s our strategy. As our requirements expand and mature, we can remove and replace applications independently from each other.
It’s okay to have applications depend on each other. However, the dependency has to be limited to the obvious things like “models” and “forms”. Also, applications can depend on the names in each other’s URL’s. Consequently, your named URL’s must have a form like “application-view” so the reverse function or the {% url %} tag can find them properly.
Each application should contain it’s own batch commands (usually via a formal Command that can be found by the django-admin script.
Finally, anything that’s more complex than a simple model or form that’s shared probably doesn’t belong to either application, but needs to be a separate shared library. For example, we use XLRD, but wrap parts of it in our own class so it’s more like the built-in csv module. This wrapper for XLRD isn’t a proper part of any one application, to it’s a separate module, outside the Django applications.