UserManager объединяет несколько причин для изменения: правила валидации, хранение и доставку писем. Регистрацию лучше оставить сценарием, а зависимости разделить по ответственности.
Есть класс UserManager который регистрирует пользователя: валидирует username и email, сохраняет в БД, отправляет email-подтверждение. Код работает правильно, но что с ним не так?
UserManager объединяет несколько причин для изменения: правила валидации, хранение и доставку писем. Регистрацию лучше оставить сценарием, а зависимости разделить по ответственности.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
UserManager объединяет несколько причин для изменения: правила валидации, хранение и доставку писем. Регистрацию лучше оставить сценарием, а зависимости разделить по ответственности.
Выделите валидатор, репозиторий пользователей и отправку подтверждения за интерфейсами. Сценарий регистрации координирует их, но не знает SQL или SMTP. Отдельно решите согласованность: сбой письма не должен бесконтрольно повторять создание пользователя; подойдут транзакция с outbox и идемпотентная отправка. Не нужно механически делать отдельный класс на каждую строку — границы определяются изменениями и проверками.