dmitriy

Генератор — просто инструмент для помощи, по итогу сущности чисты, не считая аннотаций/атрибутов для маппинга в ORM, но это просто мета-информации и завязка не существенна (не считая маленького компромисса с ArrayCollection). То есть если вы выберите др ORM, то эти аннотации вам не помешают никак, просто лишние заюзанные классы аннотаций

Имея сущности доктрины — у нас не связанный от фреймворка код, пишите спокойно бизнесуху, не обращая внимания на то, как оно потом маппится. То есть практически все по каннонам

Чтобы отделить репозиторий от домена — просто в домене делайте интерфейс, а вот реализация этого репозитория будет в Infrastrucure Layer, но это избыточно... риск минимальный, если сделаете не совсем по канону, а именно риск стоит как основной аргумент такового отделения (не просто же вы словам следуете, а причину понимаете?)
Разработка строится на компромисах, если смените доктрину на др ORM — так и так писать новые репозиторий, вероятность низкая и многие например не делают такие интерфейсы — слишком усложнит код...
Вам надо будет просто репозиторий в маппинге ORM\Repository заменить в таком случае

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

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

phpStorm + docker, в современном мире отпала необходимость в сборках (типа xampp или denver), все прекрасно заводится и переносится в docker, очень приближенно к production окружению

в основном так и есть.
бизнесу насрать на наши модели и архитектуру, ему надо деньги делать и ещё вчера.

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

это итеративный процесс: сначала столбим делянку как-нибудь (MVP), затем так и живём или приводим её в порядок.

1. Работу с request используют высокоуровневые вещи вроде контроллеров, поэтому использовать их в своих сервисах не стоит. Ваш сервис это по сути слой связи приложения и вашего кода. Поэтому правильней всего переложить данные из request в какую-то DTO например из патерна CQRS это может быть Command(), Query()

2. Даже когда вам потребуется передавать Request в какие-то свои классы, то лучше для этого использовать PSR интерфейсы. Тогда ваш Request будет фреймворконезависимым. .

эмм.... а зачем нужен laravel-excel для импорта csv?
возьмите пакет из лиги и читайте построчно. я им миллионы строк каждый день импортирую, без всяких очередей.

https://csv.thephpleague.com/

Не понятно, зачем UTF-8 вначале в CP437 конвертировать, а затем из CP437 в CP865.

Вот здесь есть решение: https://ru.stackoverflow.com/questions/606882

$name = $zip->getNameIndex($i, \ZipArchive::FL_ENC_RAW);
$name = iconv('cp866','UTF-8//IGNORE',$name);