Django RAPID Architecture is available online, free to read: https://www.django-rapid-architecture.org

For the past decade and a half at DabApps, we’ve been building, scaling and maintaining Django applications for clients of all shapes and sizes. Along the way we’ve picked up a lot of scars, a lot of lessons, and a strong sense of what tends to work (and what very much doesn’t) when a Django project has to live for years, not months.

Django itself is a remarkably solid foundation. Most of the pain we see doesn’t come from the framework, but from the way real teams end up structuring models, views, background jobs and business logic as products grow and requirements change. Patterns that feel sensible at the start of a project can become anchors a few years later.

Over time, we found ourselves giving the same architectural advice again and again in code reviews, in client workshops, in internal training. Eventually it became obvious that this needed to be written down properly.

Today I’m very happy to share the result: Django RAPID Architecture, a free online guidebook to structuring maintainable, production‑grade Django codebases.

Why another Django architecture guide?

There’s no shortage of blog posts and talks about “service layers”, “clean architecture”, “hexagonal design”, and the like. A lot of those ideas are useful, but many of them try to hide Django behind layers of abstraction that make life harder, not easier.

RAPID takes a different stance:

• Lean into Django, don’t fight it. Django’s ORM, views and URL routing are powerful and well‑understood. We don’t try to replace or obscure them.
• Optimise for real teams. The patterns have been shaped by dozens of long‑lived client projects, multiple codebases and many different developers over many years.
• Favour simplicity over purity. If a rule is hard to explain or routinely gets in the way of shipping features, it doesn’t make the cut.

The aim isn’t to invent a grand new theory of web architecture. It’s to document a set of boring, repeatable practices that make Django projects easier to read, change and reason about over the long term.

What does RAPID stand for?

• Readers: functions that encapsulate reads from the database: query construction, annotations, derived values and projection into simple data structures.
• Actions: functions that encapsulate writes and side‑effects: creating or updating data, sending emails, enqueueing jobs, calling external services and so on.
• Interfaces: the places where the outside world meets your system: HTTP views (HTML or APIs), management commands.
• Data: your models and migrations. Kept intentionally thin: table definitions and relationships, not “fat models” full of business logic.
• Patterns / Programming style: a set of guiding principles around function‑oriented design, avoiding “complexity cliffs”, and keeping flow control visible rather than buried in deep inheritance hierarchies and hidden magic.

Taken together, RAPID is less a framework and more a way of slicing a Django project so that responsibilities are clear: models define structure, readers and actions implement behaviour, interfaces orchestrate these building blocks for specific use cases.

Key ideas in the guide

The book goes into detail, but a few themes run throughout.

Horizontal layers, not app silos

Instead of carving your project into many vertical “apps” that each contain their own models, views and templates, RAPID recommends three top‑level layers: data (your models), business logic (in the form of readers and actions) and interfaces (HTTP views and management commands). Domain partitioning still happens, but within these layers rather than across them.

Function‑oriented business logic

Rather than pushing ever more behaviour into models, managers and querysets, RAPID leans on plain functions with simple, standard protocols. By sticking to these conventions, you get composable building blocks for complex queries and projections, and much better control over where queries are executed (and far fewer N+1 surprises). This is a natural fit with tools like django-readers, which formalise these patterns.

Views as thin interfaces

On the interface side, the guide argues for a fairly opinionated view of HTTP. We advocate using only two verbs: treat GET as “read some data” and POST as “perform an action”. A URL should map to one behaviour.

Backend‑for‑frontend by design

RAPID is unapologetically backend‑for‑frontend (BFF) oriented. You design endpoints around frontend use cases, not theoretical “resources”. It’s normal and expected to have multiple views over the same underlying data, each tailored to a particular screen, user role or client. Because readers and actions are shared, duplication is much lower than you might expect, and each interface layer stays pleasantly shallow.

In practice, this often leads to faster iteration with frontend teams (“we need one extra field on this screen” is a tiny change). It results in fewer performance surprises, because each endpoint is tuned for exactly the data it returns. And it gives developers a much easier mental model of “what happens when I hit this URL?”.

How this fits with our open source work

If you’ve come across our libraries like django-readers, django-zen-queries or django-db-queue, you’ll recognise some of the ideas in RAPID. The guide is deliberately library‑agnostic: you can adopt the patterns without adding any new dependencies. But it’s pragmatically opinionated: when a tool really does make a pattern easier to apply, we say so.

Who is this for?

RAPID is aimed at:

• Teams maintaining medium‑to‑large Django projects that need to stay healthy over the long term.
• Developers who already know Django and want a clearer mental model for where code should live.
• Technical leads trying to reduce cognitive load for new joiners and keep architectures from drifting into unhelpful complexity.

It’s not a Django tutorial. If you’re just starting out, you’ll want to get comfortable with the framework first. But if you’ve ever looked at a sprawling models.py or an over‑abstracted view class hierarchy and thought “there has to be a better way”, this guide is for you.

Read the guide and tell us what you think

Django RAPID Architecture is available online, free to read: https://www.django-rapid-architecture.org

It’s very much a living document. As we learn more from our own projects and from the wider community, we’ll keep refining and expanding it. If you try out some of the patterns and have feedback, disagree strongly with part of the approach, or want help applying RAPID to a codebase you’re responsible for we’d love to hear from you.

And if you’d like to talk about how DabApps can help you design, build or rescue a Django application, get in touch. We’re always happy to chat about architecture, trade‑offs and the realities of running Python in production.