Ооо сколько разработчиков грезят о DDD и ни одного интерпрайс проекта с DDD я не встречал за последние лет 10 разработки, онион архитектура это максимум. Потому что именно богатая доменная модель, как по мне, это и есть основное ограничение методологии. В больших проектах методы моделей, изменяющие их состояние, могут быть настолько большими и сложными, что должны выносится в отдельные классы. Одинственное, что можно сделать это повыносить в отдельные валью обжекты такою логику и декомпозировать сущность, НО: 1. Встает технический вопрос персиста и накладки чтения таких сущностей 2. Модели могут разойтись с реальным бизнесом, что нарушает Ubiquitous Language
Да конечно, инвариантная модель - это круто и секьюрно и сам реализовывал в небольших проетах (да красибо), но к сожалению в больших проектах, сущности с таким подходом просто превратятся в мусорку (а декомпозировать по-нормальному или нельзя или будет много всего неявного). Я уже молчу, что DDD - это непростая методология, что ограничивает маштабирорвание продукта в контексте маштабного найма разрабов.
Во-первых, нужно уже переходить на современный пхп, убрать горы типов в аннотациях и заменить всё на тайпхинты. Во-вторых, ловятся все ексепшены и конвертятся в 4xx, т.е. пятисотые не предвидятся и в лог они не попадут. Не стриктовые сравнения типа if (!post) {… } или if (!request) {… .}, советую воспользоваться phpstan со стрикт правилами. В контроллере навалено всё, и обработка реквеста, и логика работы с ентити, а если нам нужно будет тоже самое сделать через cli например, получим дублирование.
Советую посмотреть этот пример
Вообще я бы различал монорепозиторий и монолитный код. Последний — это впервую очередь сильно связанный код и кучей проблем из-за этого. Модульный код, представленный в докладе или код разбитый по контекстам с жесткими границами — это фактичеси те же (микро)сервисы, но только имеющие общую бд (может еще некоторые инфраструктурные штуки). Разбить и вынести на микросервисы такое приложение можно легко. Зато нам не нужны распределенные транзакции, у нас есть легкий дебаг приложения, легко резворачивать и доставлять код. Монорепозиторий с модульным подходом, как по мне, это идеальный старт любого приложения, а микросервизная архитектура это логическая эволюция, но главное чтоб возникла потребность в этом и не было микро-сервисы ради микросервисов, так как накладные расходы будут намного выше.
Кстати кому интересно недавно опубликовал пример приложения на DDD/SQRS на симфони
Ооо сколько разработчиков грезят о DDD и ни одного интерпрайс проекта с DDD я не встречал за последние лет 10 разработки, онион архитектура это максимум. Потому что именно богатая доменная модель, как по мне, это и есть основное ограничение методологии. В больших проектах методы моделей, изменяющие их состояние, могут быть настолько большими и сложными, что должны выносится в отдельные классы. Одинственное, что можно сделать это повыносить в отдельные валью обжекты такою логику и декомпозировать сущность, НО:
1. Встает технический вопрос персиста и накладки чтения таких сущностей
2. Модели могут разойтись с реальным бизнесом, что нарушает Ubiquitous Language
Да конечно, инвариантная модель - это круто и секьюрно и сам реализовывал в небольших проетах (да красибо), но к сожалению в больших проектах, сущности с таким подходом просто превратятся в мусорку (а декомпозировать по-нормальному или нельзя или будет много всего неявного). Я уже молчу, что DDD - это непростая методология, что ограничивает маштабирорвание продукта в контексте маштабного найма разрабов.
Советую посмотреть этот пример
Кстати кому интересно недавно опубликовал пример приложения на DDD/SQRS на симфони