Dto ? ????????????

А что будешь делать с полями типа

    private String passwordConfirm;

    @Captcha(message = "{validation.captcha.wrong}")
    private String captcha;

Это RegisterUserDto

Что касается валидации через рест сервис, то пока эти поля не используются, что касается валидации по умолчанию, то она будет проходить как и раньше.

Да, но выходит в сервисах будут скопляться ненужные и неизвестные ему поля. Можно как вариант сделать:

BasicRegistrationDto {
  String username;
  String email;
  String password;
 ...
}

WebRegistrationDto {
  @Valid
  BasicRegistrationDto basicRegistration;
  String captcha;
  ...
}

Кто что скажет? jk1, примешь участие в обсуждении?

Я бы придерживался следующих принципов относительно DTO:

1. Не смешиваем DTO для плагинов и DTO, использующееся в самом форуме, для spring mvc например. Это делается для стабильности и совместимости API плагинов, ведь их основная идея в том, что плагины пишет не только команда разработчиков JTalks. При изменении API мы теряем совместимость со сторонними плагинами, которая может уже никогда и не восстановиться.
2. Все DTO для плагинов живут в model, потому как эти DTO описывают предметную область происходящего с точки зрения плагина. Опять же, JSR-303 аннотации на DTO - бизнес-правила и ограничения на передаваемые данные. Еще одним аргументом в пользу этого подхода является то, что классы модели часто используются наравне с DTO, то есть мы приходим к унифицированному подходу при размещении и использовании любых value objects.
3. DTO для плагинов меняются только в крайнем случае. Для расширения функциональности лучше наклепать дополнительный интерфейс для плагинов.

З.Ы. Фича с уведомлением на почту об упоминании твоего ника на форуме - клевая штука

Я правильно понимаю, что ты предлагаешь то же, что и я, только DTO поместить в модель? Как это будет выглядеть?

Да



Очень просто. Рядом с пакетом model будет пакет dto. Если задуматься, то это эти сущности выполняют весьма схожие функции, только одни персистентны, а другие нет.
DTO для плагинов я бы положил отдельно в пределах того же model, чтобы не путаться.

Давайте так и попробуем, sptp, у тебя есть вопросы/возражения?

Я так понимаю мы сейчас говорим про размещение всех Dto (включая RegisterUserDto), а не только Dto плагинов, в пакете model?

По мере надобности, переносить все одним махом не надо.

Тогда, на настоящий момент, в model выносим RegisterUserDao и всю необходимую ему валидацию.

Только сделай как я написал выше, плагину не нужны лишние веб-ориентированные поля, раздели их лучше на два класса.