Кирилл Несмеянов

Экземпляры классов создаются с помощью ключевого слова new: php.net/manual/ru/language.oop5.basic.php

Какая ещё информация вам требуется?

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

Если грубо говоря - да. Если вдаваться в детали - нет (ну или слишком далеко от реальности).

В ларке контракты служат для описания инвариантности поведения и сигнатур сервиса (интерфейсы как бы этим и занимаются - орут во всю глотку, что ты забыл реализовать какой-то там метод при имплементации этого интерфейса. "Г - гениально"). Т.е. в нашем случае это просто тавтология, а названы они так для удобства, чтобы понимать, что имя является (а) локатором для доступа к сервису и (б) допустимым тайп-хинтингом в методах для инъекций реализаций. Параллели этих "контрактов" на DbC хоть и можно проводить, так как идеи схожие, но не стоит, т.к. всё же немного (сильно) подходы разные.

Сервис-провайды - это провайдеры сервисов. Ещё одно гениальное умозаключение. Переводим на русский и получаем "поставщик услуг". А если грубо говоря - регистратор этих самых злосчастных сервисов.

Фасад в нормальном мире - это хренотень, которая объединяет набор разных сервисов в одном месте. В мире ларки - это прокси, который используя сервис-локацию стучится в контейнер и перенаправляет все вызовы методов в этот самый сервис, который зареган в этом самом контейнере. В качестве локатора для сервиса вполне может выступать его интерфейс, ака "контракт".

Vlad Savelev,
1) chmod -R на `~/storage`
2) chmod -R на `~/app/bootstrap`

Это две директории, где может сохраняться кеш

Отвечая на первый вопрос:

interface TripsRepository extends Repository
{
    public function getAllWithRoutesAndVechicles(): Collection;
}

//
// Не забыть зарегать интерфейс репозитория в контейнере и использовать DatabaseTripsRepository 
// в качестве реализации интерфейса по-умолчанию. А через контекстуальный биндинг подменять, если что.
// 1) $container->singleton(TripsRepository::class, DatabaseTripsRepository::class);
// 2) $container->when('somthing')->needs(TripsRepository::class)->give(...);
//
class DatabaseTripsRepository implements TripsRepository
{  
    // DI usage
    public function __construct(Trips $trips)
    {
        $this->trips = $trips;
    }

    public function getAllWithRoutesAndVechicles(): Collection
    {
        return $this->trips
            ->join('routes', 'routes.trip_id', '=', 'trips.id')
            ->join('vehicles', 'trips.vehicle_id', '=', 'vehicles.id')
            ->where('trips.user_id', '=', $id)
            ->get(['trips.id','from', 'to', 'brand', 'model', 'start_at', 'end_at']);
    }
}

Пример:
1) Репа: https://github.com/SerafimArts/SerafimArts/blob/ma...
2) Реализация: https://github.com/SerafimArts/SerafimArts/blob/ma...
3) Использование: https://github.com/SerafimArts/SerafimArts/blob/ma...
4) Пример в классической вариации через DataMapper (вместо ActiveRecord): www.laraveldoctrine.org/docs/1.3/orm/repositories

Отвечая на второй вопрос: Нет, чтобы так заработало надо принудительно прописать жадную загрузку этих связей для модели (поле with).

$user->password = bcrypt('123123');

ikudryash:
1) Модель (везде) - это просто прикладной уровень доменного объекта (т.е. некоторый объект, отображающий предметную область). Она ни от чего не зависит и ничего не требует (в т.ч. наследования).
2) AR-модели (ну или любые другие анемичные модели) никогда и не при каких условиях не должны содержать валидацию бизнес-процессов. Эта зона ответсвенности DbC инвариантов. Если это не нравится - обычной практикой считается DTO. В случае Laravel - вам всё упростили и запили на блюдечке FormRequest'ы, которые автоматом валидируются при резолве из контейнера (т.е. при инжектах).
3) Валидация бизнес-логики должна всегда находиться на уровень выше, т.к. правила создания сущностей привязаны к непосредственной области действия (в том числе прав пользователя и прочего, т.е. зависит от задачи) и может быть разной в разных местах.
4) Для использования внешних сервисов в Laravel есть контейнер, который реализует автовайринг и двойную диспатчеризацию, в отличие от Yii, где подобного нет и фрейм нашпигован скрытыми зависимостями.

Вопрос не понятен. Группе и так делегируется заказ, зачем что-то ещё дублировать? Обычная one2many связь.

UPD: Да и полиморфичные связи ещё пока никто не отменял: https://laravel.com/docs/5.4/eloquent-relationship...