DDD, CQRS, EDA, ES, Clean, Layer, Hexagonal in one application

[@vandy]

Вы вынесли конфигурацию каждого Context в папку Resources/Config, а почему не в Presentation или Infrastructure?

Конфиги - это же часть фремворка, в своих проектах, всё что связано с феймворокм, я выношу в слой Presentation (как бы Порты взаимодействия).
Но в целом, это можно отнести и к Инфраструктуре.

[@Perf2k2]

Это можно вообще никуда не выносить, а класть в корневую папку контекста/модуля или проекта, т.к. ни к коду, ни к какому-то конкретному слою не относятся. И это не всегда часть фреймворка, взять хотя бы те же .env файлы.

[@dykyi_roman]

И да и нет. Для удобства и навигации роут сервис или темплейт лучше искать в том домене которому он пренадлежить а не строить структуру папок в конфиге.

[@dykyi_roman]

да все верно. думаю это не суть важно. никто не говорит что слоев может быть только 4; Решил отделить, но можно положить и в инфраструктуру

[@thomasmorgan]

В статье подаётся, что Domain должен быть полностью независимым слоем.

И в то же время, в примере OrderContext\DomainModel\ValueObject\OrderId от доктрины зависит.

[@dykyi_roman]

#[ORM\Embeddable] - тут согласин некоторые вещи сделаны просто для удобства и простоты использования

[@thomasmorgan]

Рекомендую перед прочтением ознакомиться с примером (например, загляните в OrderContext\DomainModel\Entity\Order).

Скорей всего, далее отпадёт желание тратить время на подобную статью.

[@jakobz]

Я такую структуру папок называю «джунской». Вроде все разложено по типам объектов, порядочек. По факту - все со всем повязано, а если что-то надо в одной фиче поправить - надо пол проекта перелопатить. И все завязано на все в мясо.

[@dykyi_roman]

В команде у нас на основном проекте такая структура + порядка 10-ти микросервисов тоже такая структура; Нет проблеем с фичами и костылей тоже нету.

[@Perf2k2]

В целом неплохо, но...

use Doctrine и use Symfony в домене - жирнейший маркер того, что что-то пошло не так. Жестко привязывать домен к инфраструктуре и фреймворку - это несерьезно. Генерировать uuid можно через доменный интерфейс с реализацией в инфраструктуре. Мэппинг полей агрегата лучше перенести непосредственно в реализацию репозитория.

Shared - это наверное имеется ввиду SharedKernel? Лучше так и назвать. Слушатели событий должны быть в App слое - именно через него связываются контексты.

Вообще, главное преимущество такого подхода раскрывается при наличии в компании множества сервисов - при переходе из команды в команду, разработчик уже точно знает что и где искать (разумеется, со скидкой на частные случаи). Но и в одном проекте с большим количество разрабов, попадая в незнакомый компонент системы, уже проще.

[@dykyi_roman]

Спасибо за замечания.