Refactoring Business Logic from Django Views

When working with Django, the primary components we deal with are:

• Model — see https://docs.djangoproject.com/en/5.1/topics/db/models/
• Template — see https://docs.djangoproject.com/en/5.1/topics/templates/
• View — see https://docs.djangoproject.com/en/5.1/topics/http/views/

Some people call it the MTV (Model-Template-View) paradigm. Some consider it simply as Django’s take on the more general MVC (Model-View-Controller) paradigm (though due to the unfortunate naming it’s confusing to make that mapping since the Django Template seems to function as the View and the Django View seems to function as the Controller in MVC).

It is particularly that last part, where the Django View serves as the Controller of an MVC system, that is where things can get complicated.

It is this giant component that pretty much implements the application’s business rules. Despite the scope of the task, there are cases when I see people just write thousands of lines of code in a Django View. After all, it is the Controller, right? So, I’d see something like:

from django.views.generic import TemplateView
...
class OrdersView(TemplateView):
  template_name = "orders.html"
  ...

  def post(self, request, *args, **kwargs):
    # GIANT BLOB of business logic code here

    return HttpResponse(...)

Or, even more bare bone, a view function (thanks to the influence of the Django tutorial pages):

from django.http import HttpResponse

...

def orders(request, *args, **kwargs):
  user = request.user
  # GIANT BLOB of business logic code here 

  return HttpResponse(...)

Other than aesthetics, there is a pragmatic issue with this. Our Django app has several of what I’d call “edge endpoints” where the same data (orders in this example) needs to be queried:

• Django View (this and possibly others)
• API Views (e.g. Django REST Framework’s APIViews)
• GraphQL resolvers
• Django custom commands (management/commands/*.py)
• Celery tasks

What do most people do at this point? They’d see the error of their ways and start refactoring some common code in order to avoid redundancy and copy pasting and all the stuff that DRY clerics have been preaching about?

The Roundabout

OR they can illustrate their cleverness by calling the View class or its methods. This is an example from a Celery task:

@shared_task
def seed_orders(user_ids):
  ...
  for user in User.objects.filter(id__in=user_ids):
    ...
    response = requests.post(
      reverse("orders"), data={...}, headers=...
    ).json()
    ...

This is one way to reuse and dogfooding the code, I suppose. 🤔

My Way

Refactor Out Business Logic to a Reusable Service

To borrow one small aspect of DDD, create a separate module wherein a “service” (or factory) class encapsulates the submission of an order. Optionally, have a variant that handles multiple orders:

@dataobject
class CreateOrderProp:
  """
  All the properties and context required to create
  an order.
  """
  ...
  user: User

class OrderService:
  ...
  def create_order(order_prop: CreateOrderProp) -> Order:
    """
    Creates an order and return the created order.
    ...
    """
    # Business logic to create an order
    ...

  def create_orders(order_props: Sequence[CreateOrderProp]) -> List[Orders]:
    """
    Creates orders and return the orders created.
    ...
    """
    orders = []
    for prop in order_props:
      ...
      orders.append(create_order(prop))
    ...
    return orders

Call the Service from the Edge Endpoints

Django View

from django.views.generic import TemplateView
...
class OrdersView(TemplateView):
  template_name = "orders.html"
  ...

  def post(self, request, *args, **kwargs):
    service = OrderService(...)
    order = service.create_order(
      CreateOrderProp(..., user=request.user)
    )
    return HttpResponse(...)

Celery Task

@shared_task
def seed_orders(user_ids):
  ...
  service = OrderService(...)
  for user in User.objects.filter(id__in=user_ids):
    ...
    order = service.create_order(
      CreateOrderProps(..., user=user)
    )
    ...

Custom Command

from django.core.management.base import BaseCommand

class Command(BaseCommand):
    def add_arguments(self, parser):
        parser.add_argument("user_ids", nargs="+", type=int)

    def handle(self, *args, **options):
        user_ids = options.get("user_ids")
        service = OrderService(...)
        for user in User.objects.filter(id__in=user_ids):
            ...
            order = service.create_order(
                CreateOrderProps(..., user=user)
            )

There will most likely be more refactoring of the business logic in the OrderService. However, at least none of that will affect the Django Views, Celery tasks, or any other place that needs to create orders.

Another benefit is that unit tests for OrderService now don’t need to worry about setting up the context for calling a Django View or starting a Celery task or whatever other places that will create an order.