jazzus

С помощью отношений

хелпером trans

orderBy

У тебя связи прописаны полиморфные. А схема бд нет.

Partner отношение? Тогда правильнее использовать методы отношений
$partner->relations
whereHas, with итд

Валидацию убрать в форм реквест, правила доступа в политики. Остальное зависит от логики. См инструменты Ларавел кроме контроллеров и роутов.

Для отправки группе абонентов нужно юзать фасад https://laravel.com/docs/8.x/notifications#using-t...
Проверку, которая в isNotificationEnabled можно сделать в where запросе до создания уведомлений.

Удалить Initial. Удалить InitialResource. Ибо это не ресурс. Передавать данные через json response. Внутри которого CategoryResource. Для правильного запроса квери билдер метод where. Если хочется вызывать методом из модели делай scope. Без get в модели. Передавать, как написано в документации
CategoryResource::collection($categories);

Внезапно пришла абсурдная идея (она автору не понравится), что
return response()->json(trans('errors.500'), 500);
итак прекрасно работает

Бест практику можно найти в самом Ларавел https://github.com/laravel/framework/blob/b1257c4e...

Переводы для множества языков с блоками большого текста можно размещать в коротких ключах языковых php файлов. Пример здесь https://laravel.com/docs/8.x/localization#using-sh...

Автор, как читающий документацию (хочется верить не вертикально) должен все это знать. И не надо рассказывать бред про неведомые "реальные проекты". Эти инструменты созданы для реальных проектов, а не для виртуальных. Велосипеды на реальных проектах пишут от незнания фреймворка и неумения им пользоваться, а не потому что там есть такая потребность. Именно такие письма пишу я, Ларавел и вижу в различных пакетах и проектах. Еще ни разу 1000 вьюх для 10 писем я не видел, но представляю какой геморой это поддерживать.

Количество попыток не гарантирует. юзер может 10 раз на кнопку нажать и везде будет 1 попытка. попробуй добавить уникальность с номером инвойса https://laravel.com/docs/8.x/queues#unique-jobs

Создавать среду для теста нужно в сетапе, а не в тесте.

Потом мне нужно проверить приложение от лица гостя

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