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

pydantic ломают не модели, а границы ввода: где именно валидировать Если pydantic используется везде подряд, проект быстро превращается в склад дублей и лишних преобразований. Нормальная схема простая: на входе — сырой payload, в домене — уже чистые типы, в БД — только то, что прошло проверку. Три места, где pydantic реально помогает: — запросы API: парсинг, coercion, обязательные поля, алиасы — внутренние DTO между сервисами и слоями — конфиги и env-переменные, где ошибка должна падать сразу Типовая ошибка — тащить BaseModel глубоко в бизнес-логику и потом ловить сюрпризы из-за dict(), exclude_none и неявных преобразований. Лучше один раз отделить schema-модели от доменных объектов, чем потом чинить «магические» поля по всему коду. Если pydantic нужен для границы, он экономит время; если как универсальный объект, он начинает мешать.