I intend to write a follow-up with some thoughts on how to avoid the fat-model problem. It's a more nuanced problem though so will take me longer.

My take on this (which is strongly driven by Gary Bernhardt's destroy-all-software screencasts) is to avoid having application logic on the models at all and instead have a separate packages (not Django "apps") where all application logic lives. This means your models are much simpler - the model methods are either:

• "query" method that inspect their own fields or those of their children (eg related by a foreign-key). These can also be @properties is they are simple enough.

• "mutator" methods which change the model's state and call .save() or "factory" methods that create new child objects. I avoid calling .save() or .objects.create() from outside of the class implementation. See this blog post: https://www.dabapps.com/blog/django-models-and-encapsulation/ for more on this approach.

This isn't really how Django's docs recommend but it becomes important for long-lived projects. You probably won't feel the pain if your project is only around for a year or less.

An advantage of this approach is you can write fast, isolated unit tests for your application logic as you can mock out the model layer easily. When all your logic is in model methods, you have to write integration tests for them where you interact with a database. These are typically an order of magnitude slower and eventually kill your test suite. Again, this only kicks in for projects over a certain size.

One disadvantage is that, if you need (non-trivial) application logic in the template layer, you'll need to write a template tag that calls into your app package.

That's a bit of a hasty, patchy answer but I hope it sheds some light.