I'm unconvinced by the "skinny models" and "service layer" arguments. Django's ORM is an active record style ORM, its at its best if you use it that way. If you want to have a service layer type architecture, use SqlAlchemy with implements the data mapper scheme.

I follow this general rule of thumb, in order:

If it's a complicated business logic touching multiple models or external apis, put in in a `utils` module (keeping this sensibly organised by model/role/activity depending on what you are building, i.e. utils.{model_name}.{methods} or utils.{e.g. order_processing/email/accounts}.{methods}). You can add a shortcut to it as a method on the model if this makes sence. (some may argue this is a service layer)

If I'm only doing something once in one place (in one view), then keep the logic there.

If it's a custom create method, stick it on the models manager class.

If it's something you want to do to a set of objects (from a query set), put it on the manager class or a QuerySet subclass (to make it chain-able).

If you haven't put it elsewhere put it on the model class, as a method or a property if it seems cleaner (don't do get_... and set_... use a property)

Some recommends Service layers, but not the total extreme extent that the service layer is flexible/transferable between frameworks/databases.

https://alexkrupp.typepad.com/sensemaking/2021/06/django-for...

https://news.ycombinator.com/item?id=27605052

IMO service objects are an OOP-cargo-cult abomination, especially the kind named after a verb with a "call" method (CreateFooFromBar#call), so the first thing I reach for to offload my business logic involving multiple models or just lots of logic are PORO domain objects with meaningful non-generic method names (a CampaignReservation with "#create!", "#persisted?" or "#available?" methods, a XlsxClientImport with "#perform" or "#check_format" methods).