Это можно вообще никуда не выносить, а класть в корневую папку контекста/модуля или проекта, т.к. ни к коду, ни к какому-то конкретному слою не относятся. И это не всегда часть фреймворка, взять хотя бы те же .env файлы.
use Doctrine и use Symfony в домене - жирнейший маркер того, что что-то пошло не так. Жестко привязывать домен к инфраструктуре и фреймворку - это несерьезно. Генерировать uuid можно через доменный интерфейс с реализацией в инфраструктуре. Мэппинг полей агрегата лучше перенести непосредственно в реализацию репозитория.
Shared - это наверное имеется ввиду SharedKernel? Лучше так и назвать. Слушатели событий должны быть в App слое - именно через него связываются контексты.
Вообще, главное преимущество такого подхода раскрывается при наличии в компании множества сервисов - при переходе из команды в команду, разработчик уже точно знает что и где искать (разумеется, со скидкой на частные случаи). Но и в одном проекте с большим количество разрабов, попадая в незнакомый компонент системы, уже проще.
Сегодня с обеда бился, не мог понять в чем причина — при api запросе не видит токена из basic auth, а он оказывается только в PHP_AUTH_USER его ищет. Полез на гитхаб в сорцы смотреть, может исправили уже, и вижу буквально только что 2.0.13 релизнулся:
Это можно вообще никуда не выносить, а класть в корневую папку контекста/модуля или проекта, т.к. ни к коду, ни к какому-то конкретному слою не относятся. И это не всегда часть фреймворка, взять хотя бы те же
.envфайлы.В целом неплохо, но...
use Doctrineиuse Symfonyв домене - жирнейший маркер того, что что-то пошло не так. Жестко привязывать домен к инфраструктуре и фреймворку - это несерьезно. Генерировать uuid можно через доменный интерфейс с реализацией в инфраструктуре. Мэппинг полей агрегата лучше перенести непосредственно в реализацию репозитория.Shared - это наверное имеется ввиду SharedKernel? Лучше так и назвать. Слушатели событий должны быть в App слое - именно через него связываются контексты.
Вообще, главное преимущество такого подхода раскрывается при наличии в компании множества сервисов - при переходе из команды в команду, разработчик уже точно знает что и где искать (разумеется, со скидкой на частные случаи). Но и в одном проекте с большим количество разрабов, попадая в незнакомый компонент системы, уже проще.
Молодцы, спасибо за фреймворк)