Как эту причину выделить?
Смотрите на класс который у вас вышел, прикидываете причины по которым полезете внутрь для изменения. В данном примере в 2х случаях -изменить правила валидации, изменить процедуру логина.
Так уж четко сформулированный и так и нарушаю? А можно узнать, что такое "единственная обязанность"? что такое "одна причина для изменения"? Можно определение, не пример, а определение.
Вы какой то скрытый смысл ищете? Я его не знаю, в противном случае могу дать ссылку на словарь Даля.
Как определить уровень детализации который нужно использовать, чтобы отделить одну обязанность от другой? На основе чего решить, является ли валидация логина и пароля одной, а обращение за учетной записью к соответствующем объекту другой обязанностью, или что они обе являются частью обязанности "залогинить юзера"?
Так я вам встречных вопросов накидаю. У репозитория доступ к хранилищу юзеров, в форме введенные данные, у чего то еще доступ к сессии - как мне решить какие из этих данных "ключивее" остальных для логина?
Я могу обязанность формы LoginForm определить как "залогинить юзера", валидация логина и пароля, а также обращение за экземпляром $user под это подпадает? Будет ли это пресловутой "единственной обязанностью" и если нет, то почему?
Каким образом правило "в email должна быть @" относится к процедуре логина? Какое это имеет значение если логин производится по токену в рест апи?
А как бы вы его интерпретировали?
Использовал бы AuthService (да, да, я знаю что вы напишите). Так как он бы у меня находился в домене он бы мог и исключение доменное бросить и доменное событие, и репозиторий (или какая другая абстракция над хранилищем) рядом лежит.
А если определить обязанность LoginForm как "залогинить юзера" в приведенной интерпретации, то я ничего и не нарушил.
Вот честно, по вашему LoginForm это то место где программист ожидаете найти метод login?