открыть бд в phpstorm или table plus)

У phpstorm есть неплохой клиент, подсвечивает внешние ключи и прочее

👍

этож денег платить нужно

У меня есть крякнутый)

асуждаю

Тот же вопрос себе задаю входя в продуктовый или строительный магаз)

Что то а шторм своих денег стоит

;_;

Будут гроши исправимся)

Пг админ самая уродская тулза для визуализации бд

Юзайте встроенный в пхп шторм визуализатор бд. Имхо это самый удобный вариант

Поддерживаю

Я правильно понимаю, что имеется ввиду зависимость от класса события? То есть в шину вы кладете класс события, а не его сериализованные, например, в json данные?

Да, я думал о том что если данные отправлять в json то как тогда другой контекст поймет что это за событие произошло?

а как можно бросить событие и не указать его имя? как слушатель события может подписаться на "неизвестное" событие? - это не про ddd, а про слабую связанность компонентов

Имя класса - чем не имя события?

Тем что более сильная связанность, в том плане что вероятность изменения контракта выше (переименование класса)

Лучше рассмотреть события без привязки к ddd.  Цель событий - убрать связанность между компонентами. Например есть интернет магазин.

Есть сервис в котором реализована логика создания заказа - после создания заказ находится в статусе - "обрабатывается". Создание нового заказа должно инициировать оповещение клиента по почте, запрос на резерв товара у конкретного поставщика, информирование смежной системы отвечающей за сбор данных о пользователях (информация для маркетинга ) и т.д.

Ключевое слово здесь - "и .т.д" - т.е. компонентов которые реагируют на создание заказа может быть переменное количество.
Вариант дергать каждый компонент из сервиса заказов - трудоемкое решение - появится новый компонент который должен реагировать на создание заказа - и нужно вносить правки в сервис заказов.

Альтернатива - бросать событие. Сервис/компонент который бросает событие - не знает кто его будет обрабатывать. Сервисы которые реагируют на событие - знают о событие, но не имеют связи с компонентом который его бросил. Они знают о имени события и знают как на него подписаться.

Т.е. обработчик знает как минимум имя события, а сообщение с информацией о событие содержит всю необходимую информацию для его обработки.

При этом лучше думать о будущем и понимать что со временем тот кто бросает событие и тот кто его обрабатывает - могут оказаться не в рамках одного приложения, а разнесенными по разным микросервисам.
Поэтому имена событий завязывать на  классы - очень спорное решение, так как через год-два - может получить ситуацию что событие бросает сервис на php, а обрабатывает сервис на nodejs
Нужно продумать и зафиксировать протокол описывающий сообщения которые бросаются событием. Данные сообщения события могут включать: имя события, версию протокола описывающего сообщения для этого  события,  уникальный идентификатор события (uuid - по нему удобно отслеживать и логировать обработку события), идентификатор системы отправившей событие, а дальше уже непосредсвенно данные самого события - например информация о созданном заказе.

Также нужно задаваться вопросом нужно ли знать обработчику события о том кто его инициировал? В обработчике события будет условный if - который будет обеспечивать разную логику обработки события в зависимости от того кто его инициировал? Часто (но не обязательно) условный if в обработчике события реализующий разную логику обработки, в зависимости от источника - сигнал что вместо одного события нужно использовать несколько разных событий