Игорь Воротнёв

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

URL Generation
Route URL Generation & Extra Parameters
In previous releases of Laravel, passing associative array parameters to the route helper or URL::route method would occasionally use these parameters as URI values when generating URLs for routes, even if the parameter value had no matching key within the route path. Beginning in Laravel 6.0, these values will be attached to the query string instead. For example, consider the following route:

Route::get('/profile/{location}', function ($location = null) {
    //
})->name('profile');

// Laravel 5.8: http://example.com/profile/active
echo route('profile', ['status' => 'active']);

// Laravel 6.0: http://example.com/profile?status=active
echo route('profile', ['status' => 'active']);

Взято как ни странно тут

Собственно так все будет работать

$banner = \App\Banner::find(1);
Route::resource('banners', 'BannerController');
echo  route('banners.show', $banner);

$photo = \App\Photo::find(1);
Route::resource('banners.photos', 'BannerPhotosController');
echo route('banners.photos.show', [$banner, $photo]);

Кстати ['name' => 'banners.*'] это лишнее, по дефолту у вас и так будет задано имя указанное первым аргументом

В PHP сообществе вообще не развиты вопросы проектирования и архитектуры. Большинство лепит, что придумает. PHP изначально родился для примитивных homepage, вобрал в себя всю несерьезность, низкий порог входа и как следствие довольно слабое комьюнити, что часто становится объектом для шуток.

Искать ответы на вопросы проектирования и архитектуры нужно в Java. Например там почти каждый с самых азов слышал о де факто ставшей стандартом слоистой архитектуре, она же layered architecture, она же n-tier architecture и видел изображение похожее на это

Из которой нужно понять, что всю программу можно разделить на несколько слоев и зависимость между слоями должна быть направлена сверху вниз, но не наоборот. Таким образом, например фреймворк может быть инкапсулирован в presentation слой и в любой момент безболезненно заменен на другой, так как другие слои ничего о нем не знают. Вся бизнес-логика инкапсулирована в domain слой в виде plain old java object, который не зависит вообще не от чего, а также предоставляет интерфейсы (репозиториев например) для инфраструктурного слоя и только в этом слое фактически и будет тот самый настоящий ООП, который все так упорно пытаются найти. Никакого стороннего кода в бизнес-логике нет, а соответственно весь сторонний код можно в любой момент поменять, не трогая бизнес-логику вообще.

Для этого нужно открыть какую-нибудь книгу, где за руку проведут с нуля до конкретного приложения построенного с использованием этой архитектуры. Например Implementing domain-driven design, хоть эта книга и о DDD, но я уже говорил, что слоистая архитектура это де факто. С опытом, будет понятно, что в более простых приложениях количество слоев можно уменьшить, понимая на какой компромисс придется пойти, что иногда можно объединить domain и часть infrastructure и получить всем известный шаблон Active Record или вообще выбросить эти слои и получить шаблон transaction script, когда для решения просто не требуется что-то более сложное. Придет понимание, как можно начать с transaction script и в итоге постепенно катиться в сторону domain layer, через active record или не через active record если это когда-нибудь понадобится и тому подобное. Cтанет понятно, зачем, как и когда использовать патерны о которых написал Мартин Фаулер в своей книге Patterns of Enterprise Application Architecture.

Полученные знания можно применить к любому языку. В том числе и PHP. Будет хорошо, если уровень этого сообщества хоть чуть-чуть будет подтягиваться к уровню Java, вместо того чтобы бомбить пятиуровневые ифы создавая такую цикломатическую сложность, что все метрики кода горят ярче красного.

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

Так, например, если вы работаете с государственным или окологогосударственным заказчиком/исполнителем, весьма вероятно, вам придётся подготовить ТЗ в соответствии с требованиями ГОСТ-19 и 34 (в особенности ГОСТ 34.602-89 и ГОСТ 19.201-78), которые предполагают создание очень формальных и подробных документов.

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

Для какой-нибудь дизайнерской разработки (стиль, лого, графика), когда велика изначальная неопределённость, что же требуется сделать, лучшим вариантом может являться вообще достаточно общий бриф.

Резюмируя: определитесь с требованиями к ТЗ, а, отталкиваясь от них, уже можно искать какие-то варианты.

они такие волшебные могут работать чуть ли не круглые сутки

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

Оплачиваются не языки программирование.

Оплачивается умение ими пользоваться.

Есть буквально одно исключение - Cobol.
Это один из старейших языков программирования, на котором начали писать еще тогда когда ваши родители еще не родились.
Приходится иметь дело с очень древними программами, причем выполняющими весьма ответственные вещи, где высока цена ошибки (первыми, кто мог позволить себе компьютеры был очень крупный бизнес)

о наблюдениям сервиса «Мой круг» в России последние пару лет по зарплатам лидируют...

Вы неверно интерпретируйте данные.

Просто ряд языков чаще используется в недорогих простых проектах. Что не отменяет их же использование в дорогих проектах. Но искажает понятие "средняя зарплата".

Плюс недорогих проектов всегда намного больше. Что еще более искажает понятие "средняя зарплата".

Ну то есть математически-формально всё так как описано в обзоре зарплат.

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

Причём если Scala и Elixir два года назад по зарплатам опережали прочие языки с сильным отрывом и за последние годы выросли по зарплате несильно, то Go и Objective-C за эти же два года совершили сильный отрыв от остальных языков и догнали Scala и Elixir

Все упомянутые нельзя назвать распространенными на простых (то бишь на дешевых) проектах.

P.S.:
Узнаю типичный страх начинающего новичка (и типичное заблуждения уже начавшего новичка, который уже успел разочароваться в том, что ему не предлагают сходу 100 500 миллионов баков в месяц, как об этом все трубят) -

"Я выучу не тот язык и карьера будет погублена"
"Я выучу тот язык и карьера пойдет вверх".

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

Важно ваше умение программировать. А это понимание/знание - алгоритмов, парадигм, концепций, паттернов.

Эти вещи из языка в язык повторяются.
Трудно выучить только первый.

Сменить язык программисту с опытом - не сложно.