Приходилось ли писать собственные валидаторы

Что проверяют

Понимаете ли, где живёт валидация и когда своё писать не нужно. Ответ показывает, знаете ли вы готовые инструменты и отличаете ли проверку формата от правила предметной области.

Как отвечать

Разделите уровни. Схема данных описывается декларативно: pydantic с field_validator и model_validator, ограничения через Annotated, в Django это формы и сериализаторы. Своё пишут для доменных правил: контрольная сумма номера документа, дата окончания позже даты начала, зависимость одного поля от другого, уникальность, которую видно только в базе.

Признаки хорошего валидатора:

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

Где спотыкаются

Пишут регулярное выражение для почты и считают вопрос закрытым. Стандарт допускает такие адреса, что полная проверка шаблоном бессмысленна, а строгий шаблон отрезает живых пользователей. Рабочая практика простая: грубая проверка плюс письмо со ссылкой подтверждения.

Второе: проверяют телефон на десять цифр подряд. Международный формат, ведущий плюс, скобки и разделители ломают такую проверку в первый же день, поэтому берут специализированную библиотеку, а не свою арифметику.

Третье: бросают голое исключение с русским текстом из середины бизнес-логики. Наверху непонятно, какое поле виновато, ответ API не собрать, а сам текст намертво прибит к одному языку.