Clean Architecture with Django: Rethinking basic assumptions
2021-06-03, 12:15–13:00, Main Room

There are two main problems in implementing the Clean Architecture (CA) pattern with Django projects: developers are often not clear on what a Clean Architecture would look like with Django and secondly the framework itself resists adaption to the CA paradigm.


Clean Architectures and related architecture patterns like Hexagonal and Onion architecture are intended to provide more maintainable code and lower technical debt.

Two parts of Django's architecture, the Django ORM and 3rd party Django REST Frameworks, make it difficult to get the benefits of a Clean Architecture. We look at ways we can achieve the benefits of Clean Architecture (CA) while using the Django framework.

What are the various Clean Architecture Patterns and what do they promise to do for you?

What is the ideal architecture pattern that Django supports?

Problem 1: most Object Relational Mappings including Django's do two things:

1) Specify the persistence model: normalisation of data, efficient storage, efficient lookup, etc.

2) Specify the business entity domain: what business objects does the domain manage

The problem is that these are two different goals handled in one framework component, the ORM.

Problem 2: REST frameworks have a heavy reliance on the ORM. This ties together the business domain to storage semantics making it hard to achieve some of the benefits of a Clean Architecture.

Two solutions paths exist:

Django can serve a clean architecture-like paradigm, under specific circumstances. But there is some confusion about what CA looks like in practice that causes developers to go for solutions that are the opposite of CA.

The other solution is a more fundamental rethink of how to implement and use ORMs and REST frameworks (including remote request frameworks like GraphQL).

See also: Talk slides