А вот $post->cut($post->content, 100) - в каких-то случаях через accessor, в каких-то может кастомной директивой блейда...

в моделях нужно писать методы, которые отвечают за работу модели, в сервисах обычно пишут бизнес-логику. Т.е. если тебе нужно обработать какое то свойство модели, то пиши метод в модели, нужно посчитать площадь здания, пиши метод в сервисы. Это определяется из контекста задачи

я считаю, что в laravel модели не нужно никаких методов, кроме связей и в крайнем случае accessor, а все манипуляции с моделями через сервисы

почему?

laravel model это только сущность отражающая данные строки из базы данных и все, а вот функции, методы, лучше разместить в сервисе

понимание почему? как минимум если для метода формирования link потребуется зависимость не только от данных модели, но еще что-то, то в сервисе это будет доступно через DI, а в метод модели ты будешь это внедрять через app('что-то там'), да ну на х...

если будет несколько реализаций построения link ты будешь создать два метода в модели или просто возьмешь другую реализацию сервиса

я плох в том чтоб написать почему, т.к. в основном приходится иметь дело с legacy проектами, иногда очень старыми и всё умное, вроде как "правильно" не всегда удается применять, а иногда "нужно вчера", накидал и отдал, иногда просто лень пилить сервис ради чего-то простого

....

А ещё мутаторы

если обновление модели делать через сервисный слой, то мутатор и не нужен

из доки ларки, перевод гуглхромом. Я не согласен что это только отражение БД в приложении, это отдельная самостоятельная сущность со своим поведением. А если у тебя не БД, а например работа с данными по API, тогда это что сервис или модель?

на всякий если интересен первоисточник
https://laravel.com/docs/7.x/structure#introduction

"А если у тебя не БД, а например работа с данными по API, тогда это что сервис или модель?" - Это модель - в смысле буква M в MVC, но не модель Ларавел. А эти понятия путаются все время:)

+

в данном случае это будет сервис, который будет возращать данные, например DTO объекты

GuzzleHttp\Client это сервис или модель? в твоем понимании?

а почему просто данные ты отнес к сервисам, а не к моделям?

сервис который возвращает данные из некого стороннего API, с помощью другого сервиса например Guzzle,  обрабатывать их и отдавать в контроллер или другой сервис
куда дальше эти данные пойдут это уже другой вопрос

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

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

В рамках MVC наши сервисы - это лишь часть модели, один из слоев. Поэтому вопрос "это сервис или модель" не имеет смысла.
Просто не нужно это путать с моделями Ларавел. Они - тоже часть буквы M

почему сервисы это часть модели? это по моему может быть самостоятельной сущностью, в которую записывается бизнес логика. Сервисы как раз помогают понять куда выносить бизнес логику проекта, ранее спорили в модели или в контроллерах писать, и в итоге решили выносить ее в сервисы, и это уже стало нормой, хотя многие до сих пор пишут бизнес-лапшу в контроллеры или в модели