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

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