GennadyS

Все так, о чем и речь, нет смысла делать разделение ради разделения, архитектору нужно взвесить возможное развитие проекта. К примеру, кэш вероятно придется однажды заменить с Redis на Memcached — вероятный сценарий, но вряд ли кто-то и когда-то будет значительно менять поток получения данных пользователя user($id) в контроллере, настолько, что придется подменять репозиторий или сервис, скорее всего смысл выносить логику в обычной жизни придется лишь тогда, когда захочется избежать повторения (скажем, если данные пользователя получаются разными действиями контроллера, нет смысла дублировать код, можно реализовать один метод getUser). При этом, бизнес-логика (логика домена) как правило уже значительно разделена на слои фреймворком: валидация, проверка прав доступа — это все относится к слоям логики, наиболее частые операции. Ровно так же в некоторых сценариях может понадобиться, скажем, отделить DTO, если вводимые данные отличаются от сохраняемых (из головы пример, если для удобства пользователя адрес вводится с помощью JS-плагина с дополнением адресов, на сервер попадают строка и код реестра, а в базу идет расшифрованный адрес, и тут может понадобиться сервис, что выполнит такое преобразование).

UserRepository? Или уже в AddressRepository

А нет простых решений. Идея-то в том, чтобы разделить инфраструктуру (база данных, кэш, файлы), бизнес логику и ввод-вывод (веб-сайт, API, событие, отправка почты ну или принтер). У автора статьи просто нелепый пример односложного CRUD, и к сожалению такие примеры в большинстве статей и даже книг. В Вашем примере, видимо, UserRepository будет иметь методы addAddress($userId, $address), getAddress ($userId), saveUser($user, $address, $photos) или getUser($id, $fields) — чтобы получить пользователя с зависимыми сущностями. Исходить можно из того, что адрес принадлежит пользователю. Но разделение слоев минимально необходимо. В определенном смысле оно уже выполняется ORM, и можно пренебречь созданием отдельной сущности, если есть уверенность, что существенных изменений вноситься не будет (и дело не в отказе от ORM, а, например, во внедрении кэша, в централизованном ведении лога, отправке событий и так далее, тут уже нужно смотреть по обстоятельствам). Думаю, если не существует бизнес логики, можно пренебречь созданием спагетти-сервиса и, действительно, вернуть напрямую из репозитория, в данном случае представленном ORM. Так что код контроллера return User::findOrFail($id) в принципе допустим. Тем более задача №1 создать прототип, а завернуть его в цепочку не составит труда, это не является тяжелым изменением. И в этом смысле Вы совершенно правы, просто разработчику стоит держать в уме разделение ввода-вывода вверх и вниз: в инфраструктуру приложения и внешние взаимодействия с клиентом, по возможности выделяя непосредственно логику в независимую и портируемую. Держаться именно за паттерн стоит разве что библиотечному приложению (вроде самого фреймворка, предполагающего максимальную универсальность и заменяемость компонент, как то делает ORM, абстрагируя от хранилища).