Честно говоря не совсем понимаю почему такие выводы. Контроллеры все равно получаются тонкими. Например, есть выборка списка чего-либо. В контроллере есть репозиторий который отдает свой ответ оборачивая в Collection. В итоге получается максимум 5 строчек кода в контроллере.
В своей практике Repository использую не только на уровне сервисов, но из в Controller обращаюсь. Если сложные выборки функции-заготовки (насколько понял Вы имеете ввиду универсальные заготовки по типу getList итд) частично решат проблему, но все же это будет менее читаемый код по-моему мнению.
Спасибо за комментарий. По поводу UserDTO::fromRequest($request) Если мы привязываемся к $request, то когда нам понадобиться сделать DTO из чего-то отличного от объекта Request придется думать как это сделать (например из массива, файла итд).
При использовании UserDTO мы просто создадим еще несколько методов вида UserDTO::fromArray(...), UserDTO::fromFile(...) итд
Основная идея в том чтобы создать слой абстракции для переиспользования кода + удобнее читать код (для примера есть выборка 80+ строк кода или та же выборка но уже в классе $productRepository->getUserProducts(...). Думаю что когда эта выборка обернута в репозиторий то такой код легче читается.
В Вашем примере я бы вынес процесс оформления заказа в модуль Order в сервис OrderCreateService (заказ может создаваться например не только из под обычного пользователя, но и менеджером магазина, через обмен с внешними системами и др.).
Можно еще объединить модули которые имеют тесные связи, например, так для модулей магазина: Sale -> Order|Discount|etc, для модулей каталога Catalog -> Product|Feature|etc
Спасибо Вам за информацию. Обязательно ознакомлюсь.
Насчет единственного действия action здесь зависит как посмотреть. Например есть бизнес-процесс оформления заказа который может состоять из шагов:
расчет скидок и пр.,
сохранение сущностей,
рассылка уведомлений и др.
Этот бизнес-процесс можно как раз и рассматривать как некоторое единое действие.
В таком случае у нас есть action который оформляет заказ, но содержит в себе сервисы и репозитории нужные для каждого из шагов. Далее этот же action можно использовать в консольных командах (тк данные на вход через DTO подаются). Кроме того эти же сервисы мы можем использовать отдельно в других местах. Как вариант можно заменить action сервисом который также будет в себе агрегировать другие сервисы соответствующие шагам оформления заказов.
Спасибо, по пункту 1 полностью согласен, насчет Parameters Object спасибо за инфо, ознакомлюсь подробнее.
Спасибо за комментарий, использование framework (apiato) поверх framework (Laravel) как мне кажется ведет к избыточному усложению приложения
Честно говоря не совсем понимаю почему такие выводы. Контроллеры все равно получаются тонкими. Например, есть выборка списка чего-либо. В контроллере есть репозиторий который отдает свой ответ оборачивая в Collection. В итоге получается максимум 5 строчек кода в контроллере.
По второму пункту полностью с Вами согласен)
В своей практике Repository использую не только на уровне сервисов, но из в Controller обращаюсь. Если сложные выборки функции-заготовки (насколько понял Вы имеете ввиду универсальные заготовки по типу getList итд) частично решат проблему, но все же это будет менее читаемый код по-моему мнению.
Спасибо за комментарий. По поводу UserDTO::fromRequest($request) Если мы привязываемся к $request, то когда нам понадобиться сделать DTO из чего-то отличного от объекта Request придется думать как это сделать (например из массива, файла итд).
При использовании UserDTO мы просто создадим еще несколько методов вида UserDTO::fromArray(...), UserDTO::fromFile(...) итд
Основная идея в том чтобы создать слой абстракции для переиспользования кода + удобнее читать код (для примера есть выборка 80+ строк кода или та же выборка но уже в классе $productRepository->getUserProducts(...). Думаю что когда эта выборка обернута в репозиторий то такой код легче читается.
В Вашем примере я бы вынес процесс оформления заказа в модуль Order в сервис OrderCreateService (заказ может создаваться например не только из под обычного пользователя, но и менеджером магазина, через обмен с внешними системами и др.).
Можно еще объединить модули которые имеют тесные связи, например, так для модулей магазина: Sale -> Order|Discount|etc, для модулей каталога Catalog -> Product|Feature|etc
Те есть модули агрегирующие в себе другие модули.
Спасибо Вам за информацию. Обязательно ознакомлюсь.
Насчет единственного действия action здесь зависит как посмотреть.
Например есть бизнес-процесс оформления заказа который может состоять из шагов:
расчет скидок и пр.,
сохранение сущностей,
рассылка уведомлений и др.
Этот бизнес-процесс можно как раз и рассматривать как некоторое единое действие.
В таком случае у нас есть action который оформляет заказ, но содержит в себе сервисы и репозитории нужные для каждого из шагов. Далее этот же action можно использовать в консольных командах (тк данные на вход через DTO подаются). Кроме того эти же сервисы мы можем использовать отдельно в других местах. Как вариант можно заменить action сервисом который также будет в себе агрегировать другие сервисы соответствующие шагам оформления заказов.