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

Pydantic ломают не модели, а привычка валидировать «на глаз» Если Pydantic используется как типобезопасный слой, он экономит часы на отладке. Если как контейнер для всего подряд — начинает мешать. Базовое правило: входные данные валидируем на границе системы, внутри домена работаем уже с нормальными объектами. Самые частые ошибки: — хранить в модели поля, которые не нужны дальше по коду; — смешивать DTO для API и внутренние сущности; — писать сложную логику в валидаторах вместо отдельной функции; — полагаться на молчаливые приведения типов, когда нужен строгий контракт. Хорошая модель Pydantic отвечает на три вопроса: что пришло, что допустимо и что уйдёт дальше. Всё остальное — лишняя магия. Для сложных схем лучше разбивать большие модели на маленькие и собирать их через композицию, а не раздувать один класс до состояния монолита. Ещё один полезный приём — отделять сериализацию от бизнес-логики. Тогда ошибки видно сразу: либо данные не прошли валидацию, либо проблема уже в обработке. Именно так Pydantic перестаёт быть «удобной обёрткой» и становится нормальным контрактом между слоями.