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

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

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

А можно на конкретном примере?

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

А можно подробнее - что является инфой о том, что произошло, а что выходит за эти рамки и является экспоузом стейта?

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

это у Уди в курсе есть. Можно шарить данные, которые никогда не меняются. Например идентификаторы никогда не меняются

То есть имя события + id - это как бы должен быть достаточный набор данных, чтоб все заинтересованные стороны смогли отреагировать?

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

То есть это по идее ведёт в увеличению количества событий, но уменьшению if-ов в слушателях. Если есть воображаемый товар, который может быть где-то там скрыт или открыт, то вместо одного события ProductVisibilityChanged, появляется два события ProductHidded и ProductOpened, но слушатели сами решают какое их них им нужно и не пишут у себя условий - открыт товар к продаже или закрыт. Правильно я понял?

приложение моделирует процессы реального мира. если процессы поставлены криво - то это повлечет и кривую реализацию. Например:
я на кассе оплачиваю покупку в магазине, сначала заказ должен быть сформирован - кассир пробивает все позиции, а потом спрашивает как я будут оплачивать.
* Фактически сначала создается заказ, потом происходит процесс попытки оплаты - сам процесс попытки  оплаты также можно отразить в виде объекта предметной области.
* Процесс попытки оплатить - имеет свой идентификатор, имеет id заказа, и имеет свой тип(оплата налом, банковской картой, по qr коду и т.д.).
* В такой ситуации будет событие -
 создание заказа(и там не будет ничего про способ оплаты),
и будет событие инициации процесса попытки оплатить (попыток может быть несколько, например на карте не было денег, попробовал другой картой)

Если процесс в реальном мире поставлен так что кассир меня сначала спросит про способ оплаты, а потом начнет пробивать позиции в заказе - то да, придется отражать это в приложение. Т.е. заказ будет содержать в себе данные о способе оплаты - и это породит много веселого, например если заказ был создан с типом оплаты - "наличка", налички не хватило, клиент начал платить картой. Что должно меняться и в какой последовательности - для меня имхо это ад и содомия.

Вариант когда в реальности процесс поставлен корректно, но у разработчика не хватило компетенции отразить это в коде - это отдельный случай.

ХЗ, я не готов утверждать. Может быть нужно будет кидать и 1 ивент, но тот кто его слушает уже в курсе (или в итоге будет в курсе) оно хидден или опенед и сам уже решит что делать

Но получается, что в одном дженерик событии мы экспоузим стейт, разве нет?
Хотя с другой стороны - стейт экспоузится в виде имени события

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

А что я оплачиваю? Т.е. вот есть факт оплаты, но за что именно были получены деньги?

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

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

выбор способа оплаты и оплата - не одно и то же. Выбрать способ оплаты можно и до начала покупок вообще при регистрации даже какой-нибудь

так выбор способа оплаты - к чему будет относится?