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

это логика одной модели(не путай с моделькой лары)

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

всегда есть side effects

та же регистрация к примеру, должна отправлять мыло, должна создать комманду и тп

я бы посмотрел как у вас выглядит это в сервис классах

нет, отправить мыло это уже не ответсвенность регистрации

с фига ли?

Команды это тоже интересный подход, но не панацея. Декаплить логику можно до бесконечности, и если тебе нужны именно команды, чтобы их декорировать/композировать и в таком роде - то используешь такой подход, если тебе просто нужно вынести часть логики, чтобы не мозолила глаза - выносишь в сервис с максимально возможно абстрагирвоанным апи. Если тебе нужна действительно расширяемая система - то просто разбить весь код на мелкие куски - не выход, ибо на крупной логике менеджмент и подстройка всех этих команд превращается в головную боль. Я не говорю, что это плохой подход. Он имеет место быть и полезен в некоторых случаях, но таки использовать только его - стрелять себе в ногу

я понял что раздолбал аирлок в апке... сср

вот так вот

регистрация делает всё чтобы пользователь появился в системе

если нужно отправить мыло при регистрации, сервис регистрации передаёт данные сервису отправки мыла

Порой именно подход инкапсуляции сверху-вниз (а с командами это снизу вверх) банально более читабелен

а если у тебя команда регистрации отправляет почту, это уже не srp

А о чем спор вообще был? Сервисы vs команды?

$отдел_кадров->найми_на_работу($Вася);

А на командах это не так же звучать будет?

у меня есть 4 вещи для регистрации пользователя (создание пользователя, отправка welcome email, создание персональной комманды для пользователя и тп)
- php artisan user:create
- POST /api/users
- POST /register
- POST /admin/users

интересно посмотреть как это будет с сервисами

и какая лапша будет в коде