Александр Макаров

Получается, что ProductRepository зависит от других репозиториев (Category, ProductType, Image, File....).

Это уж как сделаете. Может зависеть, а может и нет. Я бы не завязывал одно на другое. Пусть там будет похожий код... ничего страшного.

Теперь главный вопрос - как собирать товар (или другую сущность) из разных кусков?

Руками.

Как обрабатывать метод $productRepository->save($product), если разные куски товара сохраняются по-разному.

Индивидуально. Руками.

Как быть с масштабированием, если в будущем появится еще что-то?

Или взять ORM или, опять же, руками. Не бойтесь писать код и не бойтесь его дублирования в разумных пределах. Не всё то DRY что им кажется.

Ну, JOIN сделать... joinWith.

В Yii даже банальное ... порождает запрос к базе данных, для получения структуры таблицы news.

Смокать вполне реально. Не знаю, как через Mockery, но через PHPUnit у меня вполне получалось.

В шаблонах yii2-advanced и yii2-basic есть unit, functional, acceptance. Стоит выделить отдельную группу тестов - integration?

Это название означает, что тесты не строго модульные. Реализованы они могут быть тем же PHPUnit.

integration==functional

Нет. integration = тестирует реальную базу, но всё ещё в терминах кода. functional = тестирует в терминах конечного пользователя: страницы, URL-ы, парсинг тела ответа. При этом реальный браузер не запускается. acceptance = то же, но с реальным браузером.

$class->{$propertyName}

AR-класс в backend / frontend может не наследоваться от AR-класса из common, если логика их использования различна, пусть и немного схожа.

common нужен если у нас на уровне базы всё одинаково, а вот часть бизнес логики, заложенная прямо в AR-класс разная.

По хорошему, кстати, бизнес логику надо выносить в отдельный слой, но так как ради двух строчек лепить его не хочется, пока её мало, она остаётся в AR-классах.