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

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

Главная ошибка — протаскивать сырые dict по всему проекту. Pydantic-модель должна появляться на входе в систему: HTTP-запрос, webhook, CSV-строка, переменная окружения, ответ внешнего API. Дальше код работает уже с нормальными типами, а не с «там вроде строка».

Минимальный рабочий паттерн:
— входные схемы отдельно от доменных объектов;
— extra="forbid" для публичных контрактов, чтобы не проглатывать мусор;
— дефолты только там, где они правда безопасны;
— кастомные валидаторы — для бизнес-правил, а не для парсинга всего подряд.

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

Для скриптов правило то же: сначала описываем схему данных, потом пишем обработку. Особенно для парсеров и ETL: один явный контракт экономит часы поиска, почему поле внезапно стало списком вместо строки.