I've been using this service pattern although not in Django - in Flask. The main benefit is a lot of code doesn't need to depend on a request context. We can happily have backend scripts calling services and we intentionally don't let the request context bleed into that layer.
Also, may just be me, but I've mostly seen just bad Django apps - God object patterns galore, the schema/orm/business logic all being very tightly coupled and essentially nothing is able to be refactored because of this. They often have to be simply thrown away and you start over.
But, I think having an explicit service interface solves a lot of these problems - as long as you maintain the interface and pass back the same type of object, you're free to talk to whatever backing store you like. And you get a lot less issues with circular imports and whatnot in my experience. ymmv
I've been using this service pattern although not in Django - in Flask. The main benefit is a lot of code doesn't need to depend on a request context. We can happily have backend scripts calling services and we intentionally don't let the request context bleed into that layer.
Also, may just be me, but I've mostly seen just bad Django apps - God object patterns galore, the schema/orm/business logic all being very tightly coupled and essentially nothing is able to be refactored because of this. They often have to be simply thrown away and you start over.
But, I think having an explicit service interface solves a lot of these problems - as long as you maintain the interface and pass back the same type of object, you're free to talk to whatever backing store you like. And you get a lot less issues with circular imports and whatnot in my experience. ymmv