There are certain categories of apps that end up being coupled in other apps - a good example is the django.contrib.auth
: if you are using the Django User model you depend on that app and your own apps are coupled with it.
There is nothing wrong with that scenario. I tend to think of it less as coupling and more as dependency. Your app depends on the django.contrib.auth
being available. It is a natural thing because you need that functionality. You can always replace that app with some other app that provides the same interfaces you are currently using...
Now, if you have two of your own applications and they need knowledge of each other's models, I can think of two scenarios:
You need a third application for your shared models
They should be only one application (uncommon; you had a reason to make them separate to begin with!)
I usually have a core
application of my own (just like there is a django.core
) where I keep the code that is common across the apps in my project. If models of different applications are dependent on each other, they get moved to this app.
Now, it is also possible that your two applications really are only one application - but that should not be the default thinking. Monolithic apps are a very bad thing (TM).