Hi, author here. I have been building Django and DRF applications commercially for about fifteen years at DabApps, and this guidebook is an attempt to write down the architecture patterns we have arrived at, for projects that have to survive years of ongoing maintenance.
High level summary:
* We don’t hide Django under layers of abstraction, we just slice it up a bit differently than you would by default.
* Organise code by responsibility (readers, actions, interfaces, data) rather than by app.
* Put most business logic in plain functions, not in fat models or deep class hierarchies.
* Keep views thin: treat GET as "read some data" and POST as "do an action".
* Design endpoints around real frontend use cases (backend for frontend) instead of idealised resources.
* Control queries carefully to avoid performance traps.
Happy to answer questions!
syga•1mo ago
Thank you for sharing this — I found it really fascinating and insightful. It's a shame it didn’t get more attention here. I work in an environment similar to yours and have come to similar conclusions, though not quite as "radical," for the most part.
The part about the query/values/projection of the readers layer was the most foreign to me, but I have to say, it really clicked and finally put my finger on something that’s been nagging me for a long time.
Since you mention that this came out of your work projects, I’m curious — how has your experience been onboarding developers with this way of managing Django projects?
j4mie•1mo ago
High level summary:
* We don’t hide Django under layers of abstraction, we just slice it up a bit differently than you would by default.
* Organise code by responsibility (readers, actions, interfaces, data) rather than by app.
* Put most business logic in plain functions, not in fat models or deep class hierarchies.
* Keep views thin: treat GET as "read some data" and POST as "do an action".
* Design endpoints around real frontend use cases (backend for frontend) instead of idealised resources.
* Control queries carefully to avoid performance traps.
Happy to answer questions!
syga•1mo ago
The part about the query/values/projection of the readers layer was the most foreign to me, but I have to say, it really clicked and finally put my finger on something that’s been nagging me for a long time.
Since you mention that this came out of your work projects, I’m curious — how has your experience been onboarding developers with this way of managing Django projects?