What belongs in Pydantic field or model validators, and what belongs in domain logic?

Separates deterministic request-shape validation from authorization, I/O, workflows, and durable business invariants.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

A field validator should normalize or validate one field, and a model validator can enforce consistency among fields in the same model. Examples include trimming a code, checking a bounded format, or requiring an end time after a start time. I keep database lookups, external calls, authorization, and workflow decisions out of Pydantic model construction. Those rules need explicit dependencies, current state, and application-level error handling rather than an apparently pure data model.

Full answer below

Practice focus

Validation ownership, predictable model construction, and resistance to hiding application work inside Pydantic.

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
Validators work best for facts available in the value being constructed, not for the whole application workflow.
A field validator should normalize or validate one field, and a model validator can enforce consistency among fields in the same model. Examples include trimming a code, checking a bounded format, or requiring an end time after a start time. I keep database lookups, external calls, authorization, and workflow decisions out of Pydantic model construction. Those rules need explicit dependencies, current state, and application-level error handling rather than an apparently pure data model.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
The distinction is whether the rule can be decided deterministically from the supplied values and remains true regardless of entry point. A request model may reject an impossible date range, while the application checks whether the current actor may book that resource and whether it is still available. Database uniqueness remains the final protection against a race. This keeps validation fast and predictable and lets jobs or message consumers enforce the same business invariant without constructing an HTTP DTO.

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

Querying a database from a Pydantic validator.
Using model validation as authorization.
Duplicating Pydantic conversion in a broad pre-validator.
Assuming a validator can protect every write path from a race.

What belongs in Pydantic field or model validators, and what belongs in domain logic?

Practice focus

Answer path

Overview

Review signals

Follow-up prompts

Continue practice

Next interviewer turn

Tech stacks

Skill areas

Suggest an improvement

Found this answer useful?