Илья Толлю

Вопрос очень важный и сложный. На разбиение проекта на модули могут влиять и процессы в моделируемом бизнесе, и организационная структура команды разработки (см "Закон Конвея"). И если второе можно (потенциально) изменить по потребностям, то первое нужно как минимум выяснить. Возможности внесения изменений в бизнес-процессы ограничены, как правило, но в любом случае нужно понять фактическое состояние предметной области.

В последние годы получила развитие методика Event Storming. На эту тему уже есть много видео и даже книжка [наполовину] (https://leanpub.com/introducing_eventstorming). Ключевая идея в том, чтобы выяснить, что должно произойти до того, как мы попадём в то или иное известное состояние. Методика представляет особенный интерес в контексте микросервисов. Предложение oxidmod также имеет к этому непосредственное отношение.

Но кроме системного уровня, нужно также разбивать на модули отдельные компоненты, чтобы можно было их помещать в голове, тестировать и развивать независимо друг от друга. Здесь Вам поможет Гексагональная архитектура (которая также называется "Порты и адаптеры"). Эта концепция поможет разделить компонент на части, реализующие бизнес-функции и (по отдельности) внешние взаимодействия: с файловой системой, с БД, с HTTP клиентами-сервисами и др.

На ещё более низком уровне советую освоить 1) отделение чистых функций от эффектов и 2) функциональную композицию - это идеи из функционального программирования. Не знаю, как с ФП в PHP, но тут практикующие программисты PHP могут подсказать.

Для работы в таких условиях хорошо подходит Модель Акторов. Её важной частью является понятие супервизирования. Дочерний актор - "рабочий" - реализует рискованную логику. Если он упал - супервизор решает, что делать дальше. Среди стандартных паттернов есть, например, ExponentialBackoff: пауза между попытками возрастает до достижения определённой величины (например, 5 минут) или лимита количества попыток.

Как упоминают авторы других ответов, очень важно разделять задачу на части со сфокусированными зонами ответственности. Важно держать под контролем их взаимопроникновение, определять, кто от кого должен зависеть, а кто нет. И каким образом всё это можно согласовать с необходимыми характеристиками разрабатываемой системы. Иначе говоря, древний принцип "Разделяй и властвуй" и его IT-интерпретация "Single Responsibility Principle" - наше всё.

В частности, решая задачу, вписывающуюся в область применения DDD, мы должны выделить ядро, которое моделирует определённый ограниченный контекст. Вероятнее всего, также мы должны подумать о разделении обработки команд и запросов. Потому что команды означают изменение состояния предметной области, всякие валидации, транзакции, консистентность и прочее. Запросы же означают иное представление данных, эффективный доступ на чтение, инвалидацию кешей и т.д., и т.п.

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

Пара других наводящих вопросов: должна ли работа с HTTP как-либо быть связана с взаимодействием с БД? Какой из компонентов системы должен знать параметры подключения к БД? Должны ли совпадать жизненные циклы ответа на HTTP-запрос и агрегатов в DDD-ядре? Должен ли HTTP-фреймворк диктовать Вам организацию DDD-ядра? Должен ли ORM-фреймворк диктовать Вам организацию DDD-ядра? А кто всё-таки должен?

Буду ждать Ваших комментариев.