<b>Pydantic ломает меньше, если сразу договориться о правилах на входе</b>

<b>Pydantic ломает меньше, если сразу договориться о правилах на входе</b>

Если модель используется в API, скриптах и фоновых задачах, держите один подход к данным:
— вход валидируйте на границе;
— внутри системы работайте уже с типизированным объектом;
— ошибки отдавайте до того, как логика успеет разъехаться.

Самая частая ошибка — смешивать проверку, преобразование и бизнес-логику в одном месте. В итоге строка внезапно становится числом, пустой список проходит как валидный payload, а дефолты прячут баги. Лучше явно описать обязательные поля, ограничения и преобразования в модели, чем потом искать «магическое» поведение в обработчике.

Полезная привычка: отдельные модели для входа, ответа и внутреннего представления. Тогда payload от клиента, DTO для сервиса и объект для хранения не начинают жить одной жизнью. Ещё один плюс — проще тестировать: вы проверяете схему, а не весь endpoint целиком.

И не злоупотребляйте «умными» валидаторами там, где достаточно простых типов и ограничений. Чем меньше скрытой логики в модели, тем легче читать код, переиспользовать его в FastAPI и не ловить сюрпризы в парсерах и скриптах.