надо было назвать laravel within ddd, тогда книга окупилась бы еще на стадии написания

если у тебя есть вопрос как же лучше структурировать большие приложения однозначно да (мне очень помогла книга как последний толчок)

у нас в проекте несколько раз пробовали разбить, но потом возвращались назад к стандартной структуре, некорректно разбили на микросервисы (отдельные проекты юзали одну бд) но надо было разные домены и трудно было понять как фигачить

и после этой книги появился фундамент для переделок в самом проекте и увидел много шибок в предыдущих попытках

по сути книга о том как строить больше среднего приложения используя ddd, но не выбрасывать крутые фишки самого фреймворка

Вообщем для меня оказалось ооочень в тему

😁

Проекты с высокой откпзоустойчивостью

я кстати на выходе видел про него и с мыслю ну crud не оч актуально для меня забросил
было бы в названии ddd да и еще от spaite я б сразу взял

ну опять же.. вот у них на сайте https://laravel-beyond-crud.com/ видос есть

Я их блог читал, собственно старую серию статей. Понравился подход, что они описывают как двигаться в сторону ddd, используя ларавельные инструменты, а не заменяя их чем-то другим

и там Domain.../fromStoreRequest

который ларовский

и получается уже связка с фреймворком..

но ddd же не про код ☹️

Ну как тебе сказать

И про код в том числе

Про то что доменная область должна быть максимально прозрачно представлена в коде

Код не в первую очередь

хотя идея hexagona это чтоб приложуха работала сама по себе. а на уровне фрейма подавать ей данные.. а не пихать внутрь домена from laravel requests

Где? просто в учебном проекте в домене нет связи с Request

это же убивает всю идею ddd

а это? https://c2n.me/49p6EPN

Obviously, mixing application-specific code within the domain isn't the best of ideas. However, it does have my preference. There's two reasons for that.

First of all: we already established that DTOs are the entry point for data into the codebase. As soon as we're working with data from the outside, we want to convert it to a DTO. We need to do this mapping somewhere, so we might as well do it within the class that it's meant for.

Secondly, and this is the more important reason; I prefer this approach because one of PHP's own limitations: it doesn't support named parameters.