Если нам необходима просто выборка, то можно не использовать сервисы, а обращаться напрямую к классу репозитория.
Зависит от бизнес-логики. В некоторых случаях выборку из репозитория стоит вызвать в сервисе, если предполагается дополнительная логика (какой-либо маппинг, рантайм фильтрация и т.п)
Controller обращается к action передавая DTO на вход
DTO могут создаваться через обычный конструктор, либо через вызова метода который возвращает сам DTO. Примерами может служить вызов
UserDTO::fromRequest($request)
UserDTO::fromArray($data
По хорошему DTO должен содержать только те поля, которые ему действительно нужны. Либо вместо примитивов другие DTO. DTO - это просто объект с данными. Собирать в нем самого себя из реквеста не стоит. Для таких целей удобнее всего создавать классы-ассемблеры для сборки необходимых вам DTO. Либо в пространстве App\Http\Assemblers, либо в App\Services\User\Assembler. Например: App\Services\User\Assembler\UserDTOAssembler.php
Код разбивается, исходя из логики принадлежности к Домену
Это уже касается скорее DDD, при таком подходе всю вашу структуру нужно переделывать, но далеко не везде и не всегда DDD нужен
В идеальном случае, модуль — это независимая часть бизнес-логики. При модульной организации кода структура у нас получается примерно следующей:
Если говорить о модульности, то все эти папки в целом не нужны - это отдельные под-проекты/микросервисы/библиотеки. Если на старте проекта изначально ясно, что будет какая-то админка - нужно создавать отдельный репозиторий для нее. Если же код для основного проекта и админки общий - выносить в отдельную библиотеку, желательно с DDD подходом. В таком случае код админки отвечает только за админку, шума и мусора в проектах становится меньше, поддерживаемость улучшается. Так же, стоит не забывать, что за таким подходом нужно тщательнее следить, тратить доп.время и т.д, поэтому все это индивидуально и зависит от требований конкретного бизнеса
P.S. Для простых проектов ваша структура хорошо подходит, но для более крупных уже нужно будет задумываться о реструктуризации
На мой взгляд, подход здравый и оптимальный
Зависит от бизнес-логики. В некоторых случаях выборку из репозитория стоит вызвать в сервисе, если предполагается дополнительная логика (какой-либо маппинг, рантайм фильтрация и т.п)
По хорошему DTO должен содержать только те поля, которые ему действительно нужны. Либо вместо примитивов другие DTO. DTO - это просто объект с данными. Собирать в нем самого себя из реквеста не стоит. Для таких целей удобнее всего создавать классы-ассемблеры для сборки необходимых вам DTO. Либо в пространстве App\Http\Assemblers, либо в App\Services\User\Assembler. Например: App\Services\User\Assembler\UserDTOAssembler.php
Это уже касается скорее DDD, при таком подходе всю вашу структуру нужно переделывать, но далеко не везде и не всегда DDD нужен
Если говорить о модульности, то все эти папки в целом не нужны - это отдельные под-проекты/микросервисы/библиотеки. Если на старте проекта изначально ясно, что будет какая-то админка - нужно создавать отдельный репозиторий для нее. Если же код для основного проекта и админки общий - выносить в отдельную библиотеку, желательно с DDD подходом. В таком случае код админки отвечает только за админку, шума и мусора в проектах становится меньше, поддерживаемость улучшается. Так же, стоит не забывать, что за таким подходом нужно тщательнее следить, тратить доп.время и т.д, поэтому все это индивидуально и зависит от требований конкретного бизнеса
P.S. Для простых проектов ваша структура хорошо подходит, но для более крупных уже нужно будет задумываться о реструктуризации