> 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, абстрагируя от хранилища).