Post Pydantic ломается не на моделях, а на границах входных данных

Pydantic ломается не на моделях, а на границах входных данных Если проект на Python начинает расти, pydantic быстро превращается из «удобной валидации» в слой контракта. И тут полезно держать в голове три вещи: вход должен быть грязным, модель — строгой, ошибки — читаемыми. • Не тащите всю логику в validators: проверяйте типы и форму данных, а бизнес-правила оставляйте в сервисах. • Используйте алиасы и явные названия полей, если JSON и код живут в разных мирах. • Для вложенных объектов лучше несколько маленьких моделей, чем одна огромная простыня. • Если поле необязательно, задайте понятное поведение по умолчанию, а не «магическое None». Самая частая ошибка — воспринимать pydantic как замену доменной логике. Он хорошо отвечает на вопрос «данные вообще можно принять?», но не должен решать, можно ли их проводить дальше по процессу. Ещё один полезный приём — отдельно смотреть на схемы для входа и выхода. В API это снижает сюрпризы: то, что клиент прислал, и то, что вы отдаёте, почти никогда не должны быть одной и той же моделью. Если pydantic в проекте уже есть, проверьте не количество моделей, а то, где именно они стоят в цепочке. Правильная граница экономит часы дебага.