А по поводу сервисных классов...
Одни пишут:
https://m.dotdev.co/design-pattern-service-layer-with-laravel-5-740ff0a7b65fThe Service Layer is a design pattern that will help you to abstract your logic when you need to use different front-end on your application, for your domain logic. Actually, you delegate the application logic to a common service (the service layer) and have only one class to maintain when your application grows or needs an update. This is also a good way to clean up your controllers, and make them more readable.
Т.е. мы просто выносим application logic (логику юзкейсов) в сервис, и теперь нам пофиг, будет ли это кнопка на фронте, запрос по АПИ или вызовем мы этот метод в Job'е, дублировать код везде не нужно, достаточно обратиться к нему. Но тут возникает тавтология, по сути экшен контроллера это и есть юзкейс, и тогда экшены выглядят очень тупо:
public function doSomething(SomeRequest $request)
{
$this->service->doSomething(...);
// отдаём ответ
}
Т.е. в экшенах просто происходит 1. принятие запроса 2. вызов единственного метода сервиса 3. отдача ответа.
Получили реиспользуемый но при этом каждый метод контроллера вызывает всего 1 метод сервиса.
Есть и другие статьи
https://medium.com/@smayzes/how-do-you-work-in-laravel-5a763fe5c5a0тут сервис описывается как
Services
I like to use Services to handle the logic in my apps. A Service to me can be a Domain Driven concept or 1-to-1 with a Model (database table). I have an abstract class that handles the common methods that I use a lot in my Services.
Т.е. тут уже видимо цель сервиса не просто отвязаться от интерфейса. Я изначально думал что Service Layer в Laravel это какой-то конкретный подход (или даже паттерн в рамках комьюнити). А тут похоже это вольная интерпретация каждого разработчика
