dmitriy

DI-контейнер это один из основных инструментов который должен быть в вашем приложении. Одно из правил SOLID это инверсия зависимостей, которая решается внедрением DI-контейнера с Автовайрингом для удобства.
Уже много лет использую https://container.thephpleague.com/ и работа с зависимостями перестала был проблемой.
Теперь по вашей задаче:
У вас есть контроллер HomeController который должен иметь две зависимости, например UserRepository и Pagination.
Какие зависимости должен иметь контроллер через абстракцию ? UserRepository потому что репозиторий это как правило класс который реализует слой хранения данных, который в свою очередь может меняться так как относится к слою инфраструктуры, поэтому у вас есть UserRepositoryInterface. Но вот к чему относится Pagination ? - к слою представления где у вас и находится контроллер, по сути использовать абстракции для него нет смысла, также как и для Response и Request и тд.
Поэтому ваш код будет выглядеть так:

class HomeCotroller{

   public function __construct(protected Request $request, protected UserRepositoryInterface $userRepository)

  }
  public function index(): Response { 

    $params = $this->request->getAll()
    //тут логика получения переменных

    $pagination = new Pagination($param1, $param2);
    $pagiationHtml = $pagitation->render();

    //тут логика построения html через шаблонизатор

    return new Response($html);
 }

По поводу конфига с настройками: в DI контейнере есть возможность использовать singlitone объекты , создаете адаптер подключения к базе MysqlAdapter который в конструкторе берет настройки из вашего .env файла и создает соединение 1 раз. И дальше можете адаптер использовать его через инъекцию в ваши репозитории.

Request и Response на входе? для чего?

public function update(array $args): Response {
    $payload = $this->request->getParsedBody() ?? [];

  if(!isset($args['id'])){
     return $this->buildNotFoundResponce();
  }

    // validate $payload HERE

    // find user, method return DTO object or throw exception
    $user = $this->userManager->getUserById((int)$args['id']);

    $this->userManager->updateUser($user, $payload['name'], $payload['location']);

    return $this->buildNotContentResponce();
}

Паттерн стратегия

Свою писать можно, но это долго и муторно, но зато интересно. В любом случае вы будите базироваться на уже готовых библиотеках которые себя хорошо зарекомендовали, а также многие фреймворки их используют: fast route, league container, league fractal, twig, monolog, symfony debug, symfony request, symfony console и ORM.
В основном, я по крайней мере обращаю внимание при работе с фреймворком это ORM. Так вот ни в одном нет нормальной ORM, более менее нормальная это doctrine orm, но она сложна. Мой выбор это Propel2 ORM.
Я свою CMS начинал писать на основе этого репо https://github.com/mmeyer724/Frameworkless

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

есть смысл если Вы используете генерацию документации

проверьте xdebug.remote_host

а если так
error_log = "/var/www/logs/php-fpm.log"

- openserver for Windows
- docker for linux
- phpStorm
- dbForgeStudio
- git + SourceTree Attlasian

как мне очень трудозатратно, нужно разделение фронт и бек, или хороший фулстек программист.
как правило если у вас SAAS сервис и требуется клиентоориентированный интерфейс то 90% индивидуальная админка + rest.
если же cms которая теражируется клиентам, должна иметь возможность кастомизироваться то подойдет многостроничник на bootsrap, с twig и фреймворком.

ваше направление и мысли полностью совпадают с моими, поэтому дополню то что уже писал k2lhu
DDD это больше про агрегаты и контекст, может вам нужна гексогональная архитектура и все что связанно с clean architecture. Принцип простой, ваша бизнес логика не должна зависеть от деталей реализации, попробуйте написать код без фраймворка например сохранение , отображение простых сущностей, пользователей. У вас будет репозитории не работающие с базой а просто Mock-репозитоиии, но реализующие интерфейсы. Так у вас появится Domain layer и очень тонкий Infrastructure Layer. Далее попробуйте реализовать бизнес логику и сценариции для работы с вашими сущностями, например регистрация пользователя, у вас появится Application Layer. Далее вам нужно организовать контроллеры или модули который будут отображать элементы интерфейса, вы создадите контролеры, вьюхи, модули(виджеты) и тд. например форма регистрации пользователя, так у вас появиться Presentation Layer. Далее вы переведете на динамику ваши репозитории, адаптеры и реализуете сохранение ваших пользователей в базу с помощью Activerecord или DataMapper. Так появиться Infrastructure Layer.
Плюсы, бизнес логика не зависит от фраймворка, на каждом этапе слоя вы можете подключать фраймворк на уровне как минимум в Infrastructure Layer, Presentation Layer. При смене фраймворка будите менять только их.
Тесты можно внедрять без проблем особенно на уровне домена и бизнес логики.

Золотые слова дядюшки Боба:

Когда вы пишите приложение на фраймворке для заказчика вы гарантируете разработку приложения и его поддержку в течении жизненного цикла, но какую гарантию дает вам разработчик фраймворка?

в луковой используется расслоение с минимум на три слоя:
Domain - ваши Entity, RepositoryInterface, Service
Application - бизнес логика приложения
Infrastructure - реализация контрактов, драйверов,Repository

Допустим есть необходимость коннектиться к стороннему api сервиса для обработки каких-то данных

то-что вы описали это инфраструктура, где храните и как ваше дело, конфиги могут быть в ini файле могут быть в бд.

я тебе скажу одно, можешь даже на чистом php писать

второй более норм, но есть моменты:
1. это репозиторий, класс который сохраняет сущности в хранилище
поэтому
BookRepository
2. create update сделать приватными и можно заменить на save

public function save(Model $model): void{
   if($model->getId()>0){
      $this->update($model);
   }
   else{
     $this->create($model);
   }
}

3. public function initDatabase(PDO $db) - это контруктор
public function __construct(PDO $db)
4. public function get(Book $book) - что это? public function findById($id): ?Book - более правильно
5. public function getAll() - правильных ход, но если 1млн записей, все вытащите? нужна критерия выборки и коллекция на выходе а не массив
public function getAll(Criteria $criteria): BookCollection

п.с вообще то если ООП то у вас Book должна быть богатой моделью предметной области в данном случае это Rich Model где поведение модели размазано по слоям

JavaScript мне нужен какой-то плагин

нужно отталкиваться от цели которую преследуете, Например, если на JavaScript мне нужен какой-то плагин - не аргумент, все таки не забывайте php - серверный язык а пример вы берете практики из клиентского ЯП.