DollyPapper

Не существует.

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

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

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

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

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

Стратегия = полиморфизм, то есть мы завязаны на некий интерфейс, а какая реализация — нам не важно. Это история про зависимости. Ну например почтальон отдает пенсию бабушкам (любым, какой бабушке именно — зависит от стратегии, КОТОРАЯ НЕ СВЯЗАНА с модификацией конкретной бабушки:)

Декоратор, это про добавить функционал в рамках одного интерфейса, тут вообще не рассматривается вопрос каких-либо отношений (к примеру бабушки и почтальона), тут рассматривается — бабушка в шубе или бабушка с загаром или бабушка на коляске, все та же бабушка, но "обернутая" неким поведением :) Главное что бабушка всегда остается быть той самой для всех бабушкой. То есть это не противопоставление — ни в начале ни в середине мы не завязываемся на дополнительное поведение бабушки у почтальона. Бабушка и все, а какая именно — зависит от стратегии разноса (например по названию улицы). Если выйдет к нему "декорированная" бабушка-качок — пенсию он даст ей также, как и не качку, тк она для него всего лишь некий субъект/абстракция, главное чтобы возраст и ФИО сошлись.

Соответственно это никак не похожие паттерны, один поведенческий, другой структурный... Они применяются всегда в любой этап разработки. Я в самом начале могу сделать декоратор обычной бабушки в виде поющей бабушки, а почтальона или внука в виде стратегии написать потом. А могу наоборот — сначала научить возить бабушек на трамвае (через стратегию), а бабушек с костылями (декоратор) добавить позже...

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

find ./folder/ -name "*.log" -size +10M -mtime -2

Никак (ну, скобки фигурные не нужны).
Что вам в ней не нравится?

Её можно только усложнить, потому что стрелочных функций и forEach в NodeList не было в старых браузерах.

Да

ООП это именно методология проектирования программ. Он был создан и развивается именно для этого - чтобы упростить разработку крупных проектов.

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

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

если это все же одно приложение, запускайте его и смотрите)

Для Chrome есть плагин disable-HTML. Можно удобно отключать JS, CSS, Images, Cookies, Popups.