dmitriy

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

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

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

Я использую CommandBus и Command для организации бизнес логики, изменения состояния сущностей, в Сервисах если и остаётся то только на получение данных

ganttpro.com

можно начать с книг

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

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

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

перед сотрудничеством заключайте договор/ставьте в известность, что допустимы N попыток корректировки результата работ

% да, требуют значительный но , привлеченный клиент оставляет после привлечения сумму от сопутствующий услуг, например поддержка.
например 10к стоит договор на сотрудничество/разработка/продукт
привлекли 10 клиентов отдали 50% с договора
50к вам 50к продажнику
5к стоит поддержка в месяц клиента
в год 600к с 10 привлеченных клиентов

1. mirro
2. draw.io отличный инструмент
3. https://sparxsystems.com/ для всех кейсов которые вы описали

Если весь процесс разделить на этапы то можно выделить:
1. Анализ и сбор требований
2. Проектирование
3. Разработка
4. Тестирование и ввод в эксплуатацию

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

цели уровня 1 помогут сконцентрироваться на результате, предоставить клиенту ожидаемые результат
цели уровня 2 помогут выделить Варианты использования , роли, это как правило задачи которые отражаются в ТЗ
цели уровня 3 это задачи разработчиков которые могут отражаются в техническом ТЗ или могут формировать спринт

я тебе скажу одно, можешь даже на чистом 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

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

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