JohnxFFF

Попробуйте так:

public function getAdditionalCategories()
    {
        return $this->hasMany(self::className(), ['id' => 'category_id'])
                ->viaTable(CategoryAssign::tableName(), ['resource_id' => 'id'], function(ActiveQuery $query){
             return $query->andWhere(['type' => 0]);
         });
    }

Я думаю, у тебя есть несколько вариантов
Первый. Просто описать что сделал, откуда взял.
Второй, описать все полностью с нуля, как будто ты сделал новый продукт.
И третий. Описать подробно модуль который ты переделал и сделать к нему примечание, что ты изменил зависимые классы.

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

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

Я просто сам постоянно пишу документацию. И исхожу из ситуации.
То есть везде нужна золотая середина и умение лавировать ситуацией.

function createTree($data, $depthField) {
  $tree = [];

  foreach ($data as $n) {
    $arr = &$tree;

    for ($depth = 0; $n[$depthField] > $depth; $depth++) {
      $arr = &$arr[count($arr) - 1]['children'];
    }

    $arr[] = array_merge($n, [ 'children' => [] ]);
  }

  return $tree;
}


$tree = createTree($arr, 'depth');

Это дополнительные данные для команд (хуков) в секции scripts, в данном случае некий класс

Чтобы понять эту тему — изучить нужно этот раздел: Composer Scripts
Там будет про Event Handler и сами Events, через который и получают в своих обработчиках эти данные из extra через метод:

$extra = $event->getComposer()->getPackage()->getExtra();

В данном случае передается класс, может быть скаляр или json-объект, да что угодно в рамках синтаксиса и языка

https://getcomposer.org/doc/04-schema.md#extra

Arbitrary extra data for consumption by scripts.
This can be virtually anything.
Optional.

Простым языком - это секция, в которой можно устанавливать свои кастомные параметры, которые будут использоваться вашими скриптами или надстройками для Composer. Например, есть плагин composer/installers, позволяющий устанавливать пакеты не в vendor, а по нужным путям для разных платформ/CMS. Он использует секцию extra для конфигурации этих путей. Например, для WordPress у меня это выглядит вот так:

{
  "extra": {
    "wordpress-install-dir": "core",
    "installer-paths": {
      "app/{$name}": ["type:wordpress-dropin"],
      "app/mu-plugins/{$name}": ["type:wordpress-muplugin"],
      "app/plugins/{$name}/": ["type:wordpress-plugin"],
      "app/themes/{$name}/": ["type:wordpress-theme"]
    }
  }
}

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

2. Сервисы подключаются в контроллер через конструктор и обращаются к ним как

$this->userService->create($userFrom или $userDto);

3. Делить сервисы можно хоть на каждое действие (UseCase)
..../Service/User/Create/Service.php всё зависит от вашей архитектуры. Выносите тогда, когда кода в сервисе становится много. Либо сразу.

Можете ещё почитать это Архитектура приложения. Как сделать независимые модули (сервисы)? и посмотреть тот репозиторий из github, который вставлял в качестве примера.

Ваш код можно переписать так: Исключил контроллер и PageRepository

class UserService
{
    public $users; 
    public $pages; 

    public function __construct(UserRepository $users, PageRepository $pages) 
    {
        $this->users = $users;
        $this->pages = $pages;
    }
        
    public function createUser(CreateForm $form) : void
    {
        if($this->users->existsByEmail($form->email)) {
            thow new DomainExeption('Пользователь уже существует!')
        }

        $user = new User([
            'username' => $form->username,
            'name' => $form->name,
            'email' => $form->email
        ]);

        $page = new Page([
            'name' => $form->page->name
        ]);

        ...

        $transaction->begin();
        try{
            $this->users->save($user);
            $this->pages->save($page);
            $transaction->commit();
        }
        catch{
          $transaction->rollBack();
        }

        //PS Транзакцию тоже можно вынести в отдельный сервис.
    }
}

class UserRepository
{        
    public function save(User $user): bool
    {
        if (!$user->save(false)) {
            throw new \RuntimeException('Saving error.');
        }
    }
        
    public function existsByEmail(string $email): bool
    {
        return User::find()->andWhere(['email' => $email])->exists();
    }
}

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

Данная схема мне нравится тем, что новый созданный домен наследует настройки от своих "родителей" без новых записей в таблицу Assignment. Но при этом, ничего не мешает явно кастомизировать настройки для данного домена, добавив записи в таблицу Assignment. Внешний код сначала ищет в Assignment настройки для данного домена, если их нет, то применят настройки родителей.
Хотелось бы услышать критику данного варианта схемы, так как она является моей придумкой (наверняка не уникальной) и я не до конца в нем уверен.

первый вариант.
второй вариант - усложнение логики с непонятными целями.

Если предполагается что для каждого языка одинаковый список категорий и статей, то лучше второй вариант.
Причём содержимое статьи для любого языка лучше отделить от самой обёртки статьи.
То есть 2 таблицы
1. article - только общая информация, которая повторяется для каждой статьи, и никакой "общей версии" не содержит.
2. article_data - содержимое статьи на определённом языке.

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

Хорошо, что вы уже знаете про nested sets. Вам только нужно разобраться как это сделать. Надеюсь, уже погуглили эту тему и имеете представление. Осталось понять, как это сделать на Yii. Для него есть готовое расширение

Двумя словами это не описать. Дмитрий Елисеев в своём уроке Yii shop как раз показывает как это сделать. Можете найти урок и посмотреть.

Да просто чтобы дырок в ключах не было.

Смотря зачем)). Я когда делаю Code Review критерии следующие:

* Безопасность:
- Каждый аргумент метода простого типа должен проверяться на тип в случае его проксирования и на граничные значения в случае обработки. Чуть что не так - бросается исключение. Если метод с кучкой аргументов на 80% состоит из поверки из аргументов - это вполне норм))
- Никаких trigger_error, только исключения.
- Исключения ДОЛЖНЫ быть человеко-понятны, всякие "Something went wrong" можно отдавать пользователю, но в лог должно попасть исключение со стектрейсом и человеко-понятным описанием, что же там пошло не так.
- Каждый аргумент (объект) метода должен быть с тайпхинтингом на этот его класс, или интерфейс.
- За eval как правило шлю на **й.
- @ допускается только в безвыходных ситуациях, например проверка json_last_error.
- Перед работой с БД - обязательная проверка данных.
- Никаких == и !=. Со swtich - единственное исключение, по ситуации.
- Если метод возвращает не только bool, а еще что-то - жесткая проверка с ===, или !== обязательна.
- Никаких условий с присваиваниями внутри. while($row = ...) - тоже идет лесом.
- Магические геттеры/сеттеры разрешаются только в безвыходных ситуациях, в остальном - запрещены.
- Конкатенации в sql - только в безвыходных ситуациях.
- Параметры в sql - ТОЛЬКО через плейсхолдеры.
- Никаких глобальных переменных.
- Даты в виде строки разрешаются только в шаблонах и в БД, в пхп коде сразу преобразуется в \DateTimeImmutable (в безвыходных ситуациях разрешено \DateTime)
- Конечно зависит от проекта, но как приавло должно быть всего две точки входа: index.php для web и console(или как-то по другому назваться) - для консоли.

* Кодстайл PSR-2 + PSR-5 как минимум, + еще куча более жестких требований (для начала все то что в PSR помечено как SHOULD - становится MUST)
- В PhpStorm ни одна строчка не должна подсвечиваться (исключением является typo ошибки, например словарик не знает какой-то из аббревиатур, принятых в вашем проекте). При этом разрешается использовать /** @noinspection *** */ для безвыходных ситуаций.
- Если кто-то говорит, что пишет в другом редакторе и у него не подсвечивается, на эти отговорки кладется ВОТ ТАКЕЕЕНЫЙ мужской половой **й и отправляется на доработку)).

* Организация кода:
- Никаких глобальных функций.
- Классы без неймспейса разрешаются только в исключительно безвыходных ситуациях.

* Тестируемость (в смысле простота тестирования) кода должна быть высокая.
- Покрытие кода обязательно для всех возможных кейсов использования каждого публичного метода с моками зависимостей.

* Принципы MVC:
- Никаких обработок пользовательского ввода в моделях, от слова совсем.
- Никаких ***ть запросов в БД из шаблонов.
- Никаких верстки/js/css/sql-ин в контроллерах.
- В моделях НИКАКОЙ МАГИИ, только приватные свойства + геттеры с сеттерами.
- В моделях разрешено использовать метод save(при наличии такого разумеется) только в исключительных ситуациях. Во всех остальных - либо insert, либо update.

* Принципы SOLD:
- Никаких божественных объектов умеющих во все.
- Если метод для внутреннего пользования - private, никаких public.
- Статические методы разрешаются только в случае безвыходности.

* Принцип DRY разрешено нарушать в случаях:
- Явного разделения обязанностей
- В тестах (каждый тест должен быть независимым, на сколько это возможно)

* Работа с БД:
- Запрос в цикле должен быть РЕАЛЬНО обоснован.
- За ORDER BY RAND() - шлю на***й.
- Поиск не по ключам (конечно если таблица НЕ на 5 строк) запрещен.
- Поиск без LIMIT (опять же если таблица НЕ на 5 строк) запрещен.
- SELECT * - запрещен.
- Денормализация БД должна быть обоснована.
- MyISAM не используется (так уж)) )
- Множественные операции обязательно в транзакции, с откатом если чо пошло не так.
- БД не должна содержать бизнес логики, только данные в целостном виде.
- Не должно быть нецелесообразного дерганья БД там, где без этого можно обойтись.

* Кэш должен очищаться по двум условиям (не по одному из, а именно по двум):
- Время.
- Протухание по бизнес логике.
Разрешается по только времени в безвыходных ситуациях, но тогда время - короткий период.
- При расчете ключей кэша должна использоваться переменная из конфигурации приложения (на случай обновлений кэш сбрасывается кодом, а не флашем кэш-сервера). В случае использования множества серверов - это очень удобный и гибкий инструмент при диплое.

* О людях:
- "Я привык писать так и буду дальше" - не вопрос, ревью пройдешь только когда поменяешь свое мнение.
- "Я пишу в vim-е и мне так удобно" - здорово, код консолью я тоже в нем пишу)) но есть требования к коду, если в них не сможешь - не пройдешь ревью.
- "Я скопировал этот страшный метод и поменял 2 строчки" - это конечно замечательно, но по блейму автор всего этого метода ты, так что давай без говняшек, хорошо?
- "Оно же работает!" - вот эта фраза переводится примерно так: "да, я понимаю, что пишу полную хрень, но не могу писать нормально потому, что руки из жо", я правильно тебя понял?))
- "У меня все работает!" - рад за тебя, а как на счет продакшна?
- "Там все просто" - не используй слово "просто", от слова "совсем". Вот тебе кусок кода (первого попавшегося с сложной бизнес логикой), где там ошибка (не важно есть она, или нет)? Ты смотришь его уже 2 минуты, в чем проблема, там же все "просто"))

* Всякое:
ActiveRecord (это я вам как в прошлом фанат Yii говорю) - полное говно, примите за исходную. По факту у вас бесконтрольно по проекту гуляют модельки с подключением к БД. Не раз натыкался на то, что в тех же шаблонах вызывают save, или update (за такое надо сжигать).
То, что используется Laravel - это печально((. Что бы выполнить требования приведенные выше, приходится "воевать" с фреймворком.

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

UPD

Формализировал данные критерии по ссылочке: https://github.com/index0h/php-conventions