pydantic ломают не модели, а границы ввода: где именно валидировать

pydantic ломают не модели, а границы ввода: где именно валидировать

Если pydantic используется везде подряд, проект быстро превращается в склад дублей и лишних преобразований. Нормальная схема простая: на входе — сырой payload, в домене — уже чистые типы, в БД — только то, что прошло проверку.

Три места, где pydantic реально помогает:
— запросы API: парсинг, coercion, обязательные поля, алиасы
— внутренние DTO между сервисами и слоями
— конфиги и env-переменные, где ошибка должна падать сразу

Типовая ошибка — тащить BaseModel глубоко в бизнес-логику и потом ловить сюрпризы из-за dict(), exclude_none и неявных преобразований. Лучше один раз отделить schema-модели от доменных объектов, чем потом чинить «магические» поля по всему коду.

Если pydantic нужен для границы, он экономит время; если как универсальный объект, он начинает мешать.