Pydantic ломают не модели, а привычка валидировать «на глаз»

Pydantic ломают не модели, а привычка валидировать «на глаз»

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

Самые частые ошибки:
— хранить в модели поля, которые не нужны дальше по коду;
— смешивать DTO для API и внутренние сущности;
— писать сложную логику в валидаторах вместо отдельной функции;
— полагаться на молчаливые приведения типов, когда нужен строгий контракт.

Хорошая модель Pydantic отвечает на три вопроса: что пришло, что допустимо и что уйдёт дальше. Всё остальное — лишняя магия. Для сложных схем лучше разбивать большие модели на маленькие и собирать их через композицию, а не раздувать один класс до состояния монолита.

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