dmitriy

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

1. схема нормальная, работаем сейчас по аналогичной
2. докер в любом случае поможет использовать одно окружение для все разработчиков, CI для проекта

второй более норм, но есть моменты:
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 - серверный язык а пример вы берете практики из клиентского ЯП.

два варианта:
1. Статически. Запускаем скрипт который в бд формирует цены и хранит конечную.
2. Динамически. Есть базовая цена и расчет конечной на лету.
3. Совмещение 1 и 2

по структуре
товар - ценовая позиция

Основные минусы:
- В результате, между классом и его клиентом существует формальный или неформальный «контракт», который выражается в виде предусловий (требований к клиенту) и постусловий (гарантий выполнения работы). Однако если класс принимает экземпляр сервис локатора, или, хуже того, использует глобальный локатор, то этот контракт, а точнее требования, которые нужно выполнить клиенту класса, становятся неясными
- Когда наш класс использует сервис локатор, то стабильность класса становится неопределенной. Наш класс, теоретически, может использовать что угодно, поэтому изменение любого класса (или интерфейса) в нашем проекте может затронуть произвольное количество классов и модулей
- Самое страшное в Сервис Локаторе то, что он дает видимость хорошего дизайна. У нас никто не знает о конкретных классах, все завязаны на интерфейсы, все «нормально» тестируется и «расширяется». Но когда вы попробуете использовать ваш код в другом контексте или когда кто-то попробует использовать его повторно, вы с ужасом поймете, что у вас есть дикая «логическая» связанность, о которой вы и не подозревали
- Для меня ясность и понятность интерфейса класса важнее количества параметров конструктора. Я не исключаю, что бывают случаи, когда сервис локатор является наименьшим злом, но я бы в любом случае постарался свести его использования к минимуму.

я делал через вариант {par1: false, par2: true}

Я конечно могу через запрос всем добавить другой объект со свойством par3 и новый функционал будет добавлен

- не обязательно обновлять, если при получении нет свойства например view_modal у объекта значит просто он считается не просмотренный, при просмотре и подтверждении занесите свойство view_modal=true

закладвайте буфер на спринт в кол-ве n часов на форс-мажор

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

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

из приемуществ: тестируемый код , маштабируемость в будущем.

Иногда логика отображания может быть очень сложной, и вроде бы все просто есть контроллер, есть шаблон, есть данные. Подходов для решения может быть много, я бы выбрал следующий:
1. Контроллер принимает запрос от пользозователя и обращается к сервису для получения контента
2. Сервис контента, формирует контент но при этом проверяет права доступа, авторизиван не авторизован, дата,время, группа пользователя если атворизован, его пол и все что угодно. Отдает обратно контент согласно условиям.
3. Контроллер получив контент передает в шаблон.

если координально отличаются ветки например master и develop
то создать два сайта master.site.loc и develop.site.loc
и вести разработку паралельно

1. Клиент выбирает битрикс с выгодой для бизнеса
2. Вы выбираете Laravel с выгодой для себя

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

$validation = new Validation($this->request->post());
if(!$validation->validate()){
   //var_dump($validation->getErrors());
    return 'error';
}

про Helper молчу, вообще непонятно что делает

хороший подход, использую очень давно, делается просто, я использую из твига такой вызов

{{ module('Local.Slider',{speed:400}) }}

или из php
<?=module('Local.Slider',['speed'=>400]')?>

Структура
Local/Modules/Slider/Slider.php
Local/Modules/Slider/tpl/default.twig

тут нет модели. так как модель хранится чуть выше уровнем в пакете Local