Post Pydantic полезен не только для API: где ставить границу валидации данных

Pydantic полезен не только для API: где ставить границу валидации данных Главная ошибка — протаскивать сырые dict по всему проекту. Pydantic-модель должна появляться на входе в систему: HTTP-запрос, webhook, CSV-строка, переменная окружения, ответ внешнего API. Дальше код работает уже с нормальными типами, а не с «там вроде строка». Минимальный рабочий паттерн: — входные схемы отдельно от доменных объектов; — extra="forbid" для публичных контрактов, чтобы не проглатывать мусор; — дефолты только там, где они правда безопасны; — кастомные валидаторы — для бизнес-правил, а не для парсинга всего подряд. Не превращайте модель в свалку логики. Если валидация начинает ходить в БД, дергать HTTP или считать скидки — это уже сервисный слой. Pydantic хорош как шлюз: принять, привести, отказать с понятной ошибкой. Для скриптов правило то же: сначала описываем схему данных, потом пишем обработку. Особенно для парсеров и ETL: один явный контракт экономит часы поиска, почему поле внезапно стало списком вместо строки.