Роми

Много ответов есть уже, лучше попробую идти рядом с вашими словами. Итак,
> Зачем мне создавать файл, контролирующий это, если я и сам могу контролировать то, какие методы у меня есть
Вы - это ваша голова, вы человек, не робот, ваш может не быть на работе например, или вы сами можете забыть, как у вас взаимодействуют части системы. Интерфейсы - это в общем-то тоже документация. И не нужно строго различать "чисто интерфейсы", и интерфейсы класса - те методы, которые у класса паблик - это точно такой же интерфейс, только он явно не отделен от класса. Когда у класса всего 3-4 метода, и все они связаны простой идеей, то и выделять ничего не надо. Когда у класса уже 10 методов, и среди них есть небольшие смысловые группы, то уже имеет смысл эти группы подчеркнуть. И, в конце концов, вместо каши из 10 методов, вы читаете следующее: class Graph : IEnumerable, IIndexable, IDrawable - и вы знаете, что ваш граф перечисляется, индексируется и рисуется. Это уже очень много информации, вы уже понимаете, как взаимодействуют части вашей системы.

> Может создано это для работы в больших коллективах? Но ведь тогда любой участник сможет поправить и интерфейс.
Да, совершенно верно, для больших коллективов. Нет, участник просто так не сможет поправить интерфейс, не побеседовав с остальными. В лучшем случае участнику придется поправить весь код, который "висит" на этом интерфейсе, в худшем - он в принципе ничего не сможет поменять, если интерфейс "публичный" и используется несколькими командами разработчиков. Классический пример - системы плагинов. Если к MS Word-у уже написано куча плагинов, то MS не может взять и просто так поменять ифейсы, не поломав совместимость. Хотя некоторые аспекты реализации - может. Потому что, как уже сказали выше, интерфейс - это ДОГОВОР. Чем БОЛЕЕ он стабилен, тем ЛУЧШЕ. Команды договариваются (!), создавая интерфейсы, чтобы потом было как можно МЕНЬШЕ конфликтов и разногласий, т.к. проблемы с интерфейсом затрагивают всех. Найдите любую команду от 30 человек, и вы увидите, насколько это все важно.

Еще две вещи напоследок:
1) интерфейсы из ОО языков лишь частный пример понятие интерфейса в жизни вообще. Вы же, когда покупаете SATA-диск, наверное рассчитываете, что сможете его подключить к своему компу? А с чего вы взяли? А, ну конечно, ведь на упаковке написано SATA - значит производитель соблюдает ДОГОВОР - интерфейс передачи данных;
2) необходимость в некоторых фичах языков сложно осознать в личных проектах и даже в маленьких командах. Это тоже как в жизни: свой дом, как говорится, должен построить каждый мужик, а чтобы построить бизнес-центр или высотку, нужны определенные знания, т.к. другие масштабы. Это нормально. Тем не менее, нужно читать и искать примеры. Хотя современные ОО-языки и сами дают много примеров. Раз у вас PHP, почитайте про Iterator например.

Приведу пример на коленке. Хотим, например, написать абстрактную файловую систему. Для начала, определим интерфейс, для ФС:

interface FileSystemInterface {
  public function write($file, $data);
  public function read($file);
}

Затем, хочу реализацию интерфейса ФС для работы с файликами:

class OSFileSystem implements FileSystemInterface {
  public function write($file, $data) {
     // открываем файлик, пишем данные
  }

  public function read($file) {
    // открываем файлик, возвращаем данные
  }
}

Вдруг, кому-то захотелось файловую систему в облаке. Окей, не проблема, реализуем это:

class CloudFileSystem implements FileSystemInterface {
  public function write($file, $data) {
     // открываем соединение с облаком, пишем данные
  }

  public function read($file) {
    // открываем соединение с облаком, возвращаем данные
  }
}

Пусть у нас есть кой-то код, работающий с файловой системой, назовем его "Хранилище файлов". Пусть он выглядит примерно так:

class FileStorage {
  protected $Fs;
  
  public function __construct(FileSystemInterface $Fs) {
    $this->Fs = $Fs;
  }  

  public function saveFile() {
    $this->Fs->write('file.txt', 'file data');
  }

  public function getFile() {
    return $this->Fs->read('file.txt', 'file data');
  }
}

Отлично! Теперь мы можем хранилищу файлов отдать любой объект с реализованным интерфейсом FileSystemInterface. Пример:

// Хранилище файлов работает с файловой системой ОС:
$FS = new OSFileSystem();
$FileStorage = new FileStorage($Fs);
$FileStorage->getFile();

// Хранилище файлов работает с файловой системой в облаке:
$FS = new CloudFileSystem();
$FileStorage = new FileStorage($Fs);
$FileStorage->getFile();

Использование интерфейса, в данном случае. позволяет нам писать только реализацию работы файловой системы, а бизнес-логика, работающая с файловой системой никак не меняется, она знает, что в любом случае файловая система реализует интерфейс FileSystemInterface и может без опаски использовать методы этого интерфейса.

Я делаю систему контроля яркости.
Я хочу настраивать яркость всего (гирлянды, люстры, фонарика, экрана телефона).
В коде выглядит примерно так

class BrightControl
   public void setDefaultBright(Object obj){
         obj.setBright(10);
   }
}

Метод setDefaultBright принимает любой объект. Ведь мне всё равно яркость чего настраивать.
Мой код используют другие разработчики, я не могу контролировать их.
Как мне убедиться, что у объекта, который мне пришел в качестве аргумента, есть метод setBright?
Я пишу интерфейс, и говорю, что метод setDefaultBright принимает только объекты, которые реализуют этот интерфейс.

Если кроме меня самого никто не будет использовать эту систему контроля яркости. То я просто буду держать у себя в голове, что в метод setDefaultBright можно отправлять только объекты, у которых есть метод setBright, но поддержка кода усложняется, через год и не вспомнишь...

В общем случае это плагины

В случае пхр это обычно hooks или middleware
Основная мысль в том что приложение имеет жизненный цикл и вы можете добавить в определенную точку свой обработчик.

В какой-то мере это Separation of Concerns

https://github.com/heynickc/awesome-ddd#sample-projects

Carlos Buenosvinos: Domain Driven Design in PHP
Я ее читала задолго до Эванса, поэтому не уверенна что она качественная, но лучше чем ничего)

И да, я использую 'sync' (для тестирования) - может поэтому Auth::user() доступен?

Да.

Вообще, может посоветует кто:

- Я использую для хранения и передачи некоторых данных - сессии.

Но внутри Job - Request, а, значит, и сессии - недоступны.

Переписывать логику без сессий - неохота :D

Или по любому придется, если я хочу использовать Jobs?

По-любому.

Используй docker

На русском
На английском

В примере по ссылке на википедии - представьте, что у вас есть таблица с ресторанами, таблица с видами пиццы и таблица с районами доставки. Теперь Вам надо заложить в схему БД объекты для указания: а) в каком ресторане какой вид пиццы производят и б) из какого ресторана в какой район можно доставить. В примере рассмотрены 2 варианта - 1) таблица с полями (ид_ресторана, ид_вида_пиццы, ид_района_доставки) и 2) две таблицы, одна с полями (ид_ресторана, ид_вида_пиццы) и вторая с полями (ид_ресторана, ид_района_доставки) - и описано, почему первый вариант не в 4НФ. Суть в том, что при первом варианте реализации в БД возможны случаи, когда какие-то из ресторанов одни виды пицц могут поставлять в определенный районы, а другие виды пицц - не могут. Кроме этого, при добавлении нового вида пиццы, мало создать 1 элемент таблицы в справочнике и 1 элемент в таблице связи, а надо сделать это для всех районов доставки. И далее рассматривается другой случай, когда цена пиццы определяется как функция от ресторана, вида пиццы и района доставки (видимо. в этом примере стоимость доставки включена в стоимость пиццы). Вот для этого случая, из-за наличия функциональной зависимости, таблица с ценами будет иметь альтернативный ключ из трех полей как в примере 1) и этого уже не будет нарушением 4НФ.
Вы можете не использовать первичные составные ключи. Однако, более-менее сложная система скорее всего будет иметь сущности с составными альтернативными ключами - если такой ключ не сделать, возможны логические дубли, составной альтернативный ключ в виде констрейна или уникального индекса убережет от этого. Например, когда в таблице связи ресторанов и видов пиццы будут 2 или более строки с одинаковым набором значений (ид_ресторана, ид_пиццы).