My Django Rapid Architecture short overview

Source: Dev.to

The other day, I was browsing Reddit and found an architecture proposal for Django projects called Django Rapid Architecture. It’s a short document with a few guidelines and principles. I’m fond of Django, and I think Django is one of the best tools out there that you should use, so I read it and summarized it for you.

Django Rapid Architecture is a collection of curated patterns and idioms that aims to create maintainable Django codebases. The author claims it derives from 15+ years of experience and 100+ production projects.

What’s wrong with Django’s default architecture?

According to the author, Django’s apps are designed for reusable components, not for project‑specific business logic. Forcing all code into apps creates inflexibility:

• Migrations make early boundary decisions irrevocable, which inhibits the flexible refactoring necessary for dynamic projects.
• Apps favor vertical encapsulation, grouping views and models by feature. For real‑world systems with interconnected business domains and interfaces, this is not ideal.

How to structure projects according to Django Rapid Architecture

Instead of using Django’s default paradigm, structure by layers:

1. Data – models & migrations
2. Interfaces – HTTP views, management commands, etc.
3. Business logic – readers & actions (separate from models)

Remember: Django is a monolith.

File‑structure example

Below is a typical layout that follows the proposed approach:

project/
├── actions
│   └── some_domain.py
├── data
│   ├── migrations
│   │   └── 0001_initial.py
│   └── models
│       └── some_model.py
├── interfaces
│   ├── management_commands
│   │   └── management
│   │       └── commands
│   │           └── some_management_command.py
│   └── http
│       ├── api
│       │   ├── urls.py
│       │   └── views.py
│       └── urls.py
├── readers
│   └── some_domain.py
├── settings.py
└── wsgi.py

The key idea is that code is divided into actions, data, interfaces, and readers.

Layers in Django Rapid Architecture

How to handle data?

What to do with models?

• Put all models inside a single app called data.
• Avoid ultra‑large, complex models with many methods; keep complex logic outside of models.
• Avoid inheritance other than Django’s Model base class, so any developer can quickly understand a model’s purpose.

What about business logic?

Business‑logic code should live in plain functions with well‑understood interfaces that operate on model instances, querysets, or plain values. Avoid complex inheritance, mixins, decorators, or custom managers unless absolutely necessary.

How to deal with readers?

Serving a Django response involves three key parts:

1. The Query – built in the view using a queryset; defines which DB rows/columns to fetch, applying filters, joins, and optimizations. Some logic may live in custom querysets.
2. The Values – the data to be sent. Basic values come from model fields; complex business logic often lives in model methods (e.g., get_absolute_url) that transform raw data into usable values.
3. The Projection – final shaping of data for the client. For a JSON API, this is serialization into a dict/list; for HTML, it’s template rendering. Both use the values from step 2.

Types of functions in readers

The original source provides many examples, but the main categories are:

• Queryset functions – encapsulate queryset constructions; use composition and higher‑order functions.
• Producer functions – receive a model instance and return a derived value.
• Projector functions – built on top of producers; return a dictionary that maps field names to the produced values.

TL;DR – Django Rapid Architecture encourages a horizontal, layer‑based layout (data | readers | actions | interfaces) inside a single monolithic Django project, keeping models simple, business logic in plain functions, and separating concerns for easier maintenance and refactoring.

Overview

Actions

REST APIs are complex and non‑uniform. Therefore, we should forget about all secondary HTTP verbs and stick with POST and GET only.

A single URL should map to a single view that responds only to GET or POST, not both. This mirrors the RPC/gRPC paradigm described here.

Interfaces

Server‑Side Rendering (SSR) with Django

Generating HTML on the server instead of using an API with React can increase productivity.
HTMX combined with Django is recommended; the article even considers this approach superior to using React.

Nesting Interfaces to Avoid Complexity

Organize your code to mimic the hierarchy of URL segments:

project/interfaces/http/urls.py
project/interfaces/http/api/urls.py
project/interfaces/http/api/admin/urls.py
project/interfaces/http/api/admin/widgets/urls.py
project/interfaces/http/api/admin/widgets/views.py

Management Commands

Django Management commands are also an interface and should be treated similarly to views.

Where Can I Learn More about Django Rapid Architecture?

This text is only an overview of the main ideas. To dive deeper into the Django Rapid Architecture proposal, read the original source:

• Official site: (link not provided in the original article)

The documentation is short—just a few pages—with additional examples and justification for the design decisions.