Роми

Это уже проектирование архитектуры. Она работает в нескольких плоскостях и адекватных инструментов нет и быть не может. Есть archi, есть C4 model, но это предел на сегодня

Выдели отдельный сервис или экшн для манипуляций с моделью. Например

class UserHandler {
    static function handle($user, $data) {} 
}

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

class UserObserver {
    function saving(User $user) {}
}

// И в AppServiceProvider
User::observe(UserObserver::class);

$user->update($request->validated())
для создания аналогично с create

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

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

В большинстве случаев FK не нужны, от слова совсем.

Любая СУБД имеет достаточно мощную систему контроля целостности и непротиворечивости данных. Эта система работает, используя набор правил контроля, описанных в структуре БД, и жёстко следит за тем, чтобы ни одно из правил не было нарушено.

Внешний ключ - это как раз такое правило. Сформулировано оно так: в данном поле таблицы не может храниться значение, которое не присутствует в той таблице, на которую ссылается внешний ключ (rонечно, в зависимости от конкретного текста ссылки внешнего ключа и самого поля тут возможны варианты - например, в этом поле может храниться не только значение, присутствующее в ссылочной таблице, но и NULL). И, имея такое правило, СУБД ни при каких условиях не позволит его нарушить. Любая попытка вставить запись со значением, которого нет в ссылочной таблице, приведёт к ошибке. Любая попытка изменить существующее значение на такое, которого "там" нет - приведёт к ошибке. То же касается и "второй" стороны, СУБД не позволит изменить значение в ссылочной таблице или удалить его (потому что записи в нашей таблице при этом "потеряют" ссылку) - такая попытка корректировки приведёт к ошибке.

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

Советую для понимания посмотреть пример в англоязычной википедии и там же реализацию на Java. Суть в том, что у вас есть игра лабиринт. И есть два режима игры, обычный - когда игрок может перемещаться из комнаты только в смежную комнату и магический режим - когда игрок может перемещаться в любую комнату. Алгоритм самой игры для обоих режимов один и тот же, а вот бизнес-правила перемещения игрока по комнатам - разные. Вы реализуете эти бизнес-правила в OrdinaryRoom и MagicRoom, а в самом алгоритме игры вместо того, чтобы создавать какой-то из этих объектов - вызываете просто абстрактный метод makeRoom(). А затем создаете два подкласса, которые будут реализовывать метод makeRoom и возвращать нужный тип комнаты. Таким образом вы получаете два различных режима игры написав один алгоритм.

Вообще смысл данного шаблона довольно сложно понять. В интернете его почти всегда объясняют неверно. Прямо как пример на C#. Это совсем не то, о чем писали в книге банды четырех. Пример соответствующий тому о чем рассказывается в книге реализован в примере на Java. Нужно приложить усилия и постараться вникнуть в идею. Можно перед этим изучить Template method, его проще понять, там похожая идея, только там вы перекладываете часть поведения на подклассы, а здесь перекладываете создание объекта на подклассы. Factory method практически всегда используется в связке с Template method если мы говорим о классической реализации шаблона из книги банды четырех.

Вообще шаблон не настолько распространенный насколько может показаться. Мне с 2002 года в моей практике не пригодился ни разу.

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

Пользуйтесь платными сервисами типа контура или ростендентера. Там ищите по кодам КТРУ. На ЕИС можно фильтровать только по ОКПД2.

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

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

Абстрактный класс нужен для того, чтобы не было возможности создавать его экземпляры, а только его классов-наследников.
Простой пример. Пусть у нас будет абстрактный класс Фигура с методом Нарисовать; и есть его классы-наследники Круг и Квадрат.
Так вот. Экземпляры классов Круг и Квадрат мы имеем право создавать, а вот экземпляр Фигуры создавать не имеем права, т.к. это не имеет физического смысла. И уж тем более мы никак не можем реализовать метод Нарисовать у Фигуры. Поэтому и сделан такой запрет на абстрактные классы.
Это необходимо, чтобы код был надёжным и защищённым от кривых рук других программистов

Много ответов есть уже, лучше попробую идти рядом с вашими словами. Итак,
> Зачем мне создавать файл, контролирующий это, если я и сам могу контролировать то, какие методы у меня есть
Вы - это ваша голова, вы человек, не робот, ваш может не быть на работе например, или вы сами можете забыть, как у вас взаимодействуют части системы. Интерфейсы - это в общем-то тоже документация. И не нужно строго различать "чисто интерфейсы", и интерфейсы класса - те методы, которые у класса паблик - это точно такой же интерфейс, только он явно не отделен от класса. Когда у класса всего 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 и может без опаски использовать методы этого интерфейса.