Всем привет, изучаю ddd и возник такой вопрос по ивентам.

Допустим есть 2 контекста: user, role (Контексты здесь только для примера они не имеют значения). Создаем пользователя и создается событие UserWasCreated выбрасываем это событие где нибудь в очередь. Далее в другом контексте role слушаем событие UserWasCreated из контекста user и добавляем роль к этому пользователю. И выходит что контекст role имеет прямую зависимость из контекста user. Разве так это должно быть? Другим решением вижу принимать в аргументах не само событие а только интерфейс, но тогда придется для каждого обработчика руками дописывать какое событие он обрабатывает где нибудь в конфигурации.

роль и пользовтаель у тебя в разных областях? и не могут иметь прямой зависимости?

Я же написал: контексты не играют роли, первое что придумал, вопрос именно о событиях

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

событие это часть контракта, на него можно ссылаться, оборачивать интерфейсом не нужно

Что подразумевается под контекстом? - bounded context ?

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

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

Лучше рассмотреть события без привязки к ddd. Цель событий - убрать связанность между компонентами. Например есть интернет магазин. Есть сервис в котором реализована логика создания заказа - после создания заказ находится в статусе - "обрабатывается". Создание нового заказа должно инициировать оповещение клиента по почте, запрос на резерв товара у конкретного поставщика, информирование смежной системы отвечающей за сбор данных о пользователях (информация для маркетинга ) и т.д. Ключевое слово здесь - "и .т.д" - т.е. компонентов которые реагируют на создание заказа может быть переменное количество. Вариант дергать каждый компонент из сервиса заказов - трудоемкое решение - появится новый компонент который должен реагировать на создание заказа - и нужно вносить правки в сервис заказов. Альтернатива - бросать событие. Сервис/компонент который бросает событие - не знает кто его будет обрабатывать. Сервисы которые реагируют на событие - знают о событие, но не имеют связи с компонентом который его бросил. Они знают о имени события и знают как на него подписаться. Т.е. обработчик знает как минимум имя события, а сообщение с информацией о событие содержит всю необходимую информацию для его обработки. При этом лучше думать о будущем и понимать что со временем тот кто бросает событие и тот кто его обрабатывает - могут оказаться не в рамках одного приложения, а разнесенными по разным микросервисам. Поэтому имена событий завязывать на классы - очень спорное решение, так как через год-два - может получить ситуацию что событие бросает сервис на php, а обрабатывает сервис на nodejs Нужно продумать и зафиксировать протокол описывающий сообщения которые бросаются событием. Данные сообщения события могут включать: имя события, версию протокола описывающего сообщения для этого события, уникальный идентификатор события (uuid - по нему удобно отслеживать и логировать обработку события), идентификатор системы отправившей событие, а дальше уже непосредсвенно данные самого события - например информация о созданном заказе.

> сообщение с информацией о событие содержит всю необходимую информацию для его обработки. Опасный момент - это может быть экспоуз стейта. Ну то есть если ты шаришь данные через ивент - ты всё равно их шаришь, лучше про это всегда помнить мне кажется этот момент важнее, чем завязывание типа сообщения на класс

если для обработки события нужна информация о состояние системы которая событие породила , то как технически можно избежать раскрытие состояния ?

возможно информация была записана не туда. Это же отделение данных от поведения. Если в А кидаешь событие, в Б слушаешь и нужна инфа из А, то почему у тебя инфа в А, а не в Б? На вот этот вопрос есть смысл пытаться ответить