Against service layers in Django

Recently I’ve seen posts and questions pop up in a few places about a sort of “enterprise” Django style guide that’s been getting attention. There are a number of things I disagree with in that guide, but the big one, and the one people have mostly been asking about, is the recommendation to add a “service layer” to Django applications. The short version of my opinion on this is: it’s probably not what you want in Django apps.

First it’s helpful to understand what’s meant by “service” and what the theoretical goal is, so let’s take an example. Suppose you have a Django-powered blog app, with an Entry model representing entries in the blog. The standard way to query for entries would be something like:

Where the service module implements a variety of functions/methods that, under the hood, call various Django ORM methods to actually perform queries and manipulate model objects. Typical “service” implementations provide at least things like get(), list(), create(), update(), and delete() (or other synonyms for those operations), and often also provide more complex “business logic” methods. In a simple case, things like “publishing” a blog entry by changing its status from draft to live. More complex data models and logic will end up with more complex service layers.

Leave a Comment