У меня речь шла только про бэк, попробую на реальном примере сформулировать вопрос

Там их несколько разных может быть. Например у тебя есть интерфейс с методом одним методом
void validate(Object data) {}
и по сути каждай реализация выкидывает Exception -> если данные невалидны.

И дальше у тебя есть много реализация этого класса с ValidationRule1()
EmailHasAtSignRule()
EmaiDoesntExistAtDb()
etc
и по сути ты их хранишь в каком-то масиве и в цикле перед самой функцией вызываешь нужные проверки (можно даже на аспектах написать логику)
forEach rule -> rule.validate(myInputData)

второй вариант:
создать класс который в конструкторе принимает объект и все методы в нем делают атомарные проверки и возращаются this если все хорошо, или кидают эксепшн, если данные невалидны.
получается что-то в духе:
new UserValidation(userData).emailIsValid().emailNotInTheBase().userHaveValidName()….

//real business logic

вот я как раз второй юзаю но на уровне отдельных атрибутов а не целых объектов

+1 только не экспешн кидать, а возвращать ValidationResult и избавиться от Object data
и тогда вместо forEach можно будет нормальный композит собрать:

registration_validator = CompositeValidator(
   UniqueEmailValidator(),
   NameIsNotReservedValidator(reserved_named),
   ZipCodesValidator(allowed_zipcodes),
)
errors = registration_validator.validate(user)

Давайте не примере: Скажем есть условный сервис чатов, с публичным методом SendMessage который принимает на вход набор параметров или структура типа userId, chatId, message.

Полноценна валидация скажем должны включать:
1) Сообщение: санитайзинг, обрезка проблелов, проверка максимальной и минимальной длины
2) Существование юзера
3) Существование чата
4) Наличие прав у этого юзера отправлять сообщения этот чат

И вопрос спора в том что из этого должно к примеру происходить в контроллере а что в сервисе, вопрос КАК - дело второе.

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

Санитайзинг и обрезка пробелов - это уже не валидация, лучше отдельным шагом делать.

эти все правила должны быть на уровне вашей модели (которая ddd, а не active record). если модели нет, то сервис ближе. задача контроллера только проверить что он может сделать анмаршалинг и передать дальше

Я бы хранил в контроллере техническую валидацию (email, набор символов, ненулевой размер), а бизнес-логику - в сервис.

к слову, на хабре на днях была очень хорошая статья про ddd и hexagonal architecture: https://m.habr.com/ru/post/559560/
как выносить доменную логику

начал писать про это и понял что формально это все же бизнес логика, как ни крути.

а где происходит проверка аутентификации/авторизации?

Что email должен быть валидным - это не бизнес-логика, кмк.

это не универсальное правило. что валидно для одних сервисов вполне может быть не валидным для других :)

ага, ну то есть не важно где валидация, во внешнем валидторе, в модели, которая ни в коем случае не active record и вообще тупая, кроме валидаций и простейших методов типа вернуть имя как склейку first & last name не умеет, но кто то должен дрнуть ручку и вот я считаю что только сервис)

Ну нет. Адрес или валиден, или нет. Код страны и языка или соответствует RFC, или нет. Дата-время, телефонные номера, вот это вот всё.

еще раньше но формально на уровне контроллера

это же тоже формально бизнес логика, верно?

ну я бы сказал с участием бизнес логики

к имейлу скорее полушутя, ибо не счесть вариантов его проверки.
с остальным согласен