Делаю небольшой проектик один, и все действия происходят через ивент

листенеры - получилось очень гибко и удобно. Но и бизнес логику там же прописал, хоть и её нужно было вынести в сервисы. Как вы думаете, правьлный ли такой подход к реализации проекта? И еще: где вы обычно храните бизнес логику, в сервисах (и какой неймспейс юзаете)?

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

нет. так как твоя логика завязана на реализацию и нет возможности расширения интерфейса. Т.е. если ты захочешь добавить новый источник данных, например другую платформу - что в таком случае? Но если ты не планируешь масштабировать - то забей и мнения зануд в чате не нужны :)

- ивенты должны быть фактами что бы все было красиво. Пример когда ивент не факт - perFlush ивент в котором можно "поменять" данные транзакции или вообще ее к чертям убить. Бизнес логика которая работает по ивентам должна гарантировать тебе что ивент этот сообщает тебе о состоявшемся факте - транзакция в базе закоммитилась скажем. Но там свои траблы появляются. - архитектура построенная на сообщениях офигительно гибкая и в целом легко изолировать куски. В общем и целом стоит инвестировать время в ресерч message oriented архитектур, всякие там actor model и прочее. Оч гибко, оч много возможностей, оч захочется писать на erlang/elixir (но это не точно). - бизнес логика должна быть привязана к данным. То есть основная доля ложится в сущности, но если мы на полную используем месседжинг (ивенты, команды, все вот это) то как бы границы сущности/сервисы немного размываются (особенно если мы разошлись настолько что у нас вышел event sourcing). Поскольку большинство сначала выделяют стэйт и уже потом дробят на классы исходя из этого, то есть ориентируются не на то что с данными делают и где у нас зависимости а просто группируют проперти по классам - по началу будет выходить херово (жирные сущности например). Ну и в целом это все сложно и надо разбираться в том что и зачем ты делаешь. - правильно или не правильно надо смотреть на то как у нас с общей связанностью системы (переход на ивенты может привести к temporal coupling неявному, когда важно что в каком порядке обрабатывается но все это знание размазано по коду) и насколько больно. Не больно и люди могут разобраться - значит сойдет. Велика вероятность все сломать - значит херня. - гугли про агрегаты и почему они должны быть маленькими, гугли про domain events, гугли про саги.