finds.dev← search

// the find

HackSoftware/Django-Styleguide

★ 6,299 · Python · MIT · updated Sep 2025

Django styleguide used in HackSoft projects

A style guide (not a library) from HackSoft laying out an opinionated way to structure Django/DRF projects around thin models, service functions for writes, selector functions for reads, and API views stripped of business logic. It's for teams building non-trivial Django APIs who are tired of fat models, fat views, or logic scattered across serializers and signals.

The service/selector split is explained with real trade-offs, not dogma — it tells you when a model property or custom manager is fine and when it isn't, instead of a blanket 'never do X'. Code examples are pulled straight from a companion reference project (Django-Styleguide-Example) so you can see the pattern in a full app, not just snippets. It's kept current with Django itself — e.g. calling out that `full_clean()` started checking constraints in Django 4.1, which changes the constraints-vs-clean-validation trade-off it recommends.

It's a markdown document with zero enforcement — there's no linter, no mypy plugin, no cookiecutter template shipped in this repo to make anyone actually follow the conventions; discipline comes entirely from code review. Several of its own rules contradict in practice: it says services should be simple `entity_action` functions, then spends a section justifying class-based services for 'flows,' with no clear line for when to switch. Guidance leans on 'use your best judgement' in the exact spots (model property vs. selector, clean() vs. service validation) where teams most need a firm rule to avoid bikeshedding in review.

View on GitHub →

// want more like this?

We dig through GitHub every week and send a few repos picked for what you actually care about — each with an honest take like this one.

Get finds in your inbox → Search again →