Pydantic ломается не на типах, а на границах данных: 5 мест для проверки

Pydantic ломается не на типах, а на границах данных: 5 мест для проверки

Pydantic любят за валидацию, но в бою он чаще всего спасает не от «ошибочного int», а от грязного контракта между слоями. Если модель строится из JSON, формы, очереди или внешнего API, проверять нужно не только поля, но и то, как они приходят.

— Делайте отдельные схемы на вход и на выход. Один и тот же класс для request/response быстро начинает тащить лишние поля и скрывать проблемы.
— Не полагайтесь на alias без явного контроля: имя в API, имя в коде и имя в БД лучше разводить сразу.
— Для вложенных структур проверяйте необязательные поля отдельно: None в глубине объекта часто всплывает уже в бизнес-логике.
— Не храните вычисляемые значения как «данные по умолчанию», если они зависят от других полей.
— Для списков и словарей явно ограничивайте форму, а не только тип контейнера.

Есть наблюдение, которое стоит проверить: чем раньше вы отделяете «сырые данные» от доменной модели, тем меньше у вас странных ошибок в сервисах, Celery-задачах и скриптах импорта. Pydantic хорош именно как граница, а не как универсальная сущность на все случаи.

Если нужна рабочая схема, держите простое правило: одна модель — одна ответственность, а валидация должна описывать контракт, а не угадывать намерения кода.