хотя возможно у меня просто наболело на текущем проекте 😞

Проектов в открытом доступе конечно нет, т.к. NDA.

Используем ровно так как рассказано в докладе. Действие производиться над объектом. В толстых моделях не вижу ничего страшного, т.к. этот слой изначально создавался для того что бы хранить там бизнес логику. Я работаю с одним из разработчиков Yii framework, мы дискутировали на эту тему, его доводы как раз таки были в пользу логики в моделях. Для того что бы не нагромождать класс и случайно там не потеряться среди обилия методов, мы используем Single Use трейты. UserAttributes, UserRelations, UserActions …
Также одим из инструментов в докладе рассматривалось введение новых сущностей.

а как же single responsibility?

Введение, новых сущностей(Purchase например), мне очень похоже на сервис

Здесь чувтсвуется изначално не верных подход. Если есть кейсы получения данных о сущности из БД или из АПИ, здесь скорее нужена репозиторий

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

плодить методы уровня $model->reportA(), $model->reportB()?

Но метод Славы всеравно попробую. + лара явно способствует такой организации кода

Лара вообще не особо способствует какой либо организации кода, пожалуй

Не могу не согласиться)

Здесь тонкая грань понимания этого принципа. Если брать этот принцип жестко, то дефолтная модель в принципе нарушает SRP, т.к. Eloquent построенный по паттерну Active Record умеет и find, и get, и update и save.
Здесь можно почитать дисскуссию на эту тему - https://twitter.com/taylorotwell/status/1023223691465748480

Я бы сказал Лара и сообщество, способствует написанию чистого кода.

Не совсем понятно, зачем переписывать пол модели при изменении чего-то?

ну, я понимаю, что работаю с ужасно старым и плохо организованным кодом. И в целом, тут хватает проблем. Но то, что Active Records уже есть антипаттерн репозитория и нарушает SRP - не повод для дальнейшего усугубления ситуации расширением обязанностей модели

Здесь нужно понять важную вещь, когда ты добавляешь бизнес логику которая работает с данными непосредственно этой модели. Это наоборот упрощает работу с данными и способстувет инкапсуляции (Адам показывал примеры, как инкапсулируется код, при таком подходе)

ну, поскольку я нда никаким не связан, думаю, могу привести примеры.
Есть у нас некий сервис, который в обход SRP, составляет репорты. В нем написаны и запросы к бд, и колы апи, и композиция данных и формирование excel таблиц , и ссылки на файл получившийся

и вот задача стояла как "удалить зависимость от таблицы X, заменив данные из нее на данные из нового API"

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

Не думаю, что это как-то соотносится с темой про модели

скорее про SRP