Как упоминают авторы других ответов, очень важно разделять задачу на части со сфокусированными зонами ответственности. Важно держать под контролем их взаимопроникновение, определять, кто от кого должен зависеть, а кто нет. И каким образом всё это можно согласовать с необходимыми характеристиками разрабатываемой системы. Иначе говоря, древний принцип "Разделяй и властвуй" и его IT-интерпретация "Single Responsibility Principle" - наше всё.
В частности, решая задачу, вписывающуюся в область применения DDD, мы должны выделить ядро, которое моделирует определённый ограниченный контекст. Вероятнее всего, также мы должны подумать о разделении обработки команд и запросов. Потому что команды означают изменение состояния предметной области, всякие валидации, транзакции, консистентность и прочее. Запросы же означают иное представление данных, эффективный доступ на чтение, инвалидацию кешей и т.д., и т.п.
Так от чего же должно зависеть DDD-ядро? Должно ли оно зависеть от конкретной реализации БД или ORM? От того, какие таблицы присутствуют в Вашей реляционной СУБД?
Или от протокола HTTP? Или, допустим, от конкретной файловой системы? Эти вопросы являются скорее риторическими. Поиск ответов на эти вопросы, а также подхода к тестированию DDD-ядра привели к описанию Hexagonal Architecture (известной также под именем Ports And Adapters). Очень советую узнать подробности и поискать, как Вы могли бы сделать такое доступными Вам средствами PHP.
Пара других наводящих вопросов: должна ли работа с HTTP как-либо быть связана с взаимодействием с БД? Какой из компонентов системы должен знать параметры подключения к БД? Должны ли совпадать жизненные циклы ответа на HTTP-запрос и агрегатов в DDD-ядре? Должен ли HTTP-фреймворк диктовать Вам организацию DDD-ядра? Должен ли ORM-фреймворк диктовать Вам организацию DDD-ядра? А кто всё-таки должен?
Буду ждать Ваших комментариев.
