если каждом странице будеть 10-15  штук gate(can) это вроде не страшно?

Не страшно.

спс

Тогда конкретизирую вопрос. Есть Shop и Order. В систему автоматически приходят заказы (из моб. приложения и с формы сайта), но они не сразу подтверждены, прежде чем заказ оформится он должен соответствовать некоторым правилам (иначе уйдёт на ручное подтверждение, но это другая история). Например одно из условий: у заказа есть его время, у торговой точки есть часы работы по дням недели, соответственно необходимо проверить входит ли время заказа в период времени работы торговой точки.

Тут можно выделить 1. проверка заказа 2. оформление заказа (смена статуса в БД и возможно побочные действия (отправка СМС, логирование)). Так вот, где делать проверки? Вынести в сервис? Не получается у меня что-то с определением зон ответственности пока что..

Shop ведь не должен знать о том можем ли мы ОФОРМИТЬ заказ или нет, и тем-более оформить его. Вообще по сути магазин ничего в данном случае не должен знать, кроме как вернуть в удобном виде своё расписание работы?

или он может иметь метод который примет в виде аргумента Order, и скажет, можно ли оформить или нет?

$shop->canAcceptance($order);

или тут магазин много знает об окружении?

Верно. Магазин должен знать только о наличии заказов, не более.

Логика проверки возможности заказа должна быть в сервисах, а из нужных мест обращаешься к нему и узнаешь можно ли его совершить.

И список заказов для администрации

Пара вопросов не по коду)

Если магазин уже закрыт — как от него может прилететь заказ?

Если заказ всё же прилетел, например, не внесли изменения в расписание, работаем 1 января, то что, не обрабатываем его?

Нафааааааняяяяяя!!!! Закааааз прилетееееел 😀

Про сервисы тоже отдельный вопрос, в инете одни видят сервис как место выноса кода из контроллера (сервис = use case), и получается что просто метод контроллера вызывает метод сервиса, который делает кучу разных действий с, возможно, множеством сущностей. Другие же видят сервис как model based, тут мы выносим логику из модели

Они у них обычно называются как ModelName+Service

кто прав?

Задача контроллера - контролировать: откуда что пришло, что вызвать для обработки и в каком виде вернуть.

Сервис хранит всю бизнес-логику приложения.

Модель содержит только информацию о сущности.

У меня тоже контроллеры вызывают соответствующий раздел сервиса, но сервисы именую, например, CarsService при том, что модели Cars, CarsClass, CarsBody, CarsEngine и т.д. используются в этом сервисе.

В качестве примера можно заглянуть в https://github.com/andrey-helldar/laravel-homework/tree/master/app/Services

ЗЫ: в репе есть некоторые недочёты в виде отсутствия $request->validated

@Adelf32 Адель любит такие вопросы)

если у тебя все в контроллерах, то какие проблемы то? взял, проверил что надо.. какой нужно статус выставил ордеру и радоваться можно...

перестроить свой мозг из анемичной модели в rich модель... очень сложно.

нужно этого сильно хотеть )