galithr

Для начинающих вот:
https://stepik.org/course/73/syllabus

Можно ссылаться на свойство объекта, на вашем примере:

class MyClass
{
    /**
     * @var string Название контроллера отвечающего за обработку запроса
     */
    private $controllerName;

    /**
     * @see MyClass::$controllerName
     * @param string Название контроллера
     */
    public function setСontrollerName($value)
    {
        $this->controllerName = $value;
    }

    /**
     * @see MyClass::$controllerName
     * @return string Название контроллера
     */
    public function getСontrollerName()
    {
        return $this->controllerName;
    }
}

Без разницы, главное, чтобы стиль был одним и тем же в пределах одной БД.

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

Из опыта могу сказать, что DBA чаще называют таблицы в единственном числе, а название первичного ключа начинают с имени таблицы. Девелоперы - наоборот.

Я бы сначала гуглил в другом комьюнити stackoverflow.com/questions/338156/table-naming-di...

www.sqlstyle.guide

С учетом что может быть список клиентов и подробные данные клиента - возможно существование и таблицы clients и таблицы client (или client_data)

В общем-то вопрос привычки и соглашений. Если работать в команде - то как правило существуют этакие style guide (иногда устные), которым сотрудники или стараются или обязаны следовать.

MVC, MVVM, MVP, FLUX, REDUX, HMVC, MVPVM, PAC, VVM, V... а по сути все это "болтология".

HMVC (Hierarchical model–view–controller)

как таковых стандартов нет, есть рекомендации.
например, по psr название интерфейса должно оканчиваться суффиксом Interface.

Interfaces MUST be suffixed by Interface: e.g. Psr\Foo\BarInterface.

в симфони,в обработчике повторно кидают это же исключение.

Паттерн репозиторий дает унифицированный набор общих операций над сущностью в БД.
Внутри репозитория может быть использован DataMapper. Назначение последнего именно в маппинге сущности из БД на доменную сущность (или модель).

Информация:

design-pattern.ru/patterns/repository.html
design-pattern.ru/patterns/repository.html

рискну

Repository

тут всего скорее под "пользователем", ты имеешь ввиду программиста использующего класс.. тогда, просто укажи тип в сигнатуре метода:
public function setData(int $value){

ну а если это ввод от какого-то пользователя, то его нужно валидировать до попадания в класс

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

Например сейчас в WP есть двухгодичный баг, как раз демонстрирующий такие последствия:
https://core.trac.wordpress.org/ticket/29750

Если задаться идеей "не навреди мозгу теоретика" то конечно в ActiveQuery
Но исходя из структуры yii2 часто удобнее в контроллере. Смысл раздувать ActiveQuery если такой набор используется 1 раз. Если есть необходимость использовать повторно, то точно есть смысл вынести в ActiveQuery.

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

Очень просто, через публичные свойства. Как вы модуль подключаете?

'modules' => [
        'admin' => [
            'class' => 'app\modules\admin\Module',
            'myClass1' => 'app\...\MyClass1', //myClass1 - это public $myClass1; в app\modules\admin\Module
            'myClass2' => 'app\...\MyClass1',
        ],
      
    ],

Добрый день.
Думаю, что эти статьи Вам помогут.
раз
два
три

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

А что Вас смущает? Вполне логичный ход. Можно еще через __set сделать, чтобы отдельный метод не писать (на самом деле не рекомендовал бы для одного свойства).