Where should business logic live in a Django application?

Balances model methods, QuerySets, managers, and application services by the responsibility they own.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I keep behavior that protects one entity's state close to the model, and reusable database selection or set-based operations in custom QuerySets or managers. A workflow that coordinates several models, authorization context, transactions, or external systems belongs in an explicit application service or use-case function. Views and serializers should translate HTTP input and output, then call that behavior rather than becoming the only place the rule exists.

Full answer below

Practice focus

Practical judgment about cohesive behavior without fat-model dogma or ceremonial service layers.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Overview
There is no single Django folder for all business logic; ownership follows the rule and its dependencies.
I keep behavior that protects one entity's state close to the model, and reusable database selection or set-based operations in custom QuerySets or managers. A workflow that coordinates several models, authorization context, transactions, or external systems belongs in an explicit application service or use-case function. Views and serializers should translate HTTP input and output, then call that behavior rather than becoming the only place the rule exists.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
The boundary is about cohesion, not line count. A model method is useful when callers should ask the entity to perform a valid transition. A QuerySet is useful when the operation is naturally about many rows and can stay in the database. A service earns its place when it gives a multi-step workflow one name, one transaction owner, and one testable entry point; it should not merely wrap every ORM call.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Putting every rule in views because they already have the request.
Using models as unstructured containers for unrelated workflows.
Creating one service class per model with only pass-through methods.

Where should business logic live in a Django application?

Practice focus

Answer path

Overview

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement

Found this answer useful?