<b>Pydantic ломается не на валидации, а на неявных правилах модели</b>

<b>Pydantic ломается не на валидации, а на неявных правилах модели</b>

Если поле может быть пустым, это должно быть видно в типе, а не спрятано в комментарии. Если значение приходит из разных источников, нормализуйте его до модели, а не внутри бизнес-логики. И если объект используется как контракт между слоями, держите его узким: лишние поля чаще всего превращаются в тихие баги, а не в удобство.

Три ошибки встречаются особенно часто:
• смешивают <code>str | None</code> и обязательное поле с дефолтом, потом ловят странные ответы API;
• валидируют только вход, но не проверяют данные после преобразований;
• тащат в одну модель и запрос, и ответ, и внутреннее состояние.

Сильная сторона Pydantic — не в «магии», а в дисциплине границ. Модель должна описывать форму данных, а не логику. Для правил используйте валидаторы, для преобразований — явные функции, для внешнего JSON — отдельные схемы. Тогда ошибки всплывают рядом с входом, а не в середине цепочки вызовов.

Если модель стала длиннее экрана, это обычно сигнал: пора резать её на несколько контрактов.