хмм, я всегда интерпретировал события в доменной модели как вариант decoupling уведомлений. т.е. домен сообщает наружу "я поменялся" "я сломался" "я сделал Х", а кто заинтересован - подписывается на формат уведомлений. Это позволяет подписать бесконечное кол-во получателей и неплохо работает в распределенных системах (потому что подписка = очередь сообщений) А делать это в парадигме интерфейса - как ?  Или под декларированным интерфейсом тут что-то другое имеется ввиду ?

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

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

Кмк это брокер должен как-то сигнализировать что "есть сигнал Х", но на него никто не подписан

ну тут зависит от реализации на самом деле - если добавляем в домен зависимости без контроля цикла жизни - они все переживут домен, что повлияет на memory footprint и осложнение понимания системы - что живо что нет, что утекло (ну или надо еще заниматься геморроем с удалением).
Дальше - обход зависимостей - ответственность теперь домена (а оно ему надо ? ), если мы будем домен блокировать - множество зависимостей повлияет на динамические характеристики системы, если решим что блокировать не будем и будем обрабатывать в отдельном треде по сигналу - зачем такой тред внтури домена, вытащим его наружу, будем получать сигнал от домена и обходить зависимости асинхронно. Собственно это и есть - событие от домена с внешним обработчиком.  В целом я не вижу большой драмы использовать интерфейсы, если маленький домен, потребители понятны, и в целом простая система - события ее только усложнят, фигачим монолит и подписываем зависимости, когда система растет - начинаются проблемы роста и вот тут уже было бы неплохо иметь возможность отвязать эти куски от домена, добавить сложные конструкции подписки, фильтрацию событий (не все подписчики хотят получать все подряд, статистика какая-нить интересуется только UserCreated событием  а не UserNameUpdated) ну и вот тут тогда кухня с событиями начинает оправдывать свой overhead по придумыванию событий, дерганию их и все такое...

Ну да, а как реагировать на эту ситуацию?

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

хз, можно просто в сентри залогировать

можно никак

депендс

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

Это на инфраструктурном уровне. А на инженерном? Это какой-то потребитель изменился/удалился, или источник неправильно сгенерил? А если событие редкое, раз в неделю происходит?

ну значит раз в неделю будет ошибка

Для меня loose coupling тут в том, что у слушателей нет зависимости на домен чтобы реализовать его интерфейс. событие это развесистый DTO, его можно в стандартный dictionary или json засунуть, сериализовать и вообще делать что угодно. Ну и не надо городить один пакет со всеми интерфейсами, который где-то на npm\nuget валяется и обновлять его в гамаке и стоя. Все сводится к обмену данными (если в монорепке жить - это менее релевантный ответ, но большинство же пилит в микро и наносервисы для доменов - а там разделяемые либы - боль..

Да, но вместо этого и у слушателей, и у домена появляется зависимость от этого развесистого DTO.

У тебя консумер и сендер в одном репо лежат?

Можно грепать SIGNAL_xxx по проекту в ci и выводить ошибку если только один раз найдено

да, без нее никуда,но она soft dependency,  можно брать любые поля, можно перекинуть кому-то еще - это просто данные о событии, можно ее даже отдать в другой язык\стек. Я не пытаюсь убедить что один подход радикально лучше другого, horses for courses, просто сам бы предпочел обмен данными чем вызов метода по указателю в памяти...

События в DDD играют важную роль и выходят за рамки просторого pubsub и являются частью “домена”. Это не просто механизм для обеспечения  decoupling компонентов.

- Eventstorming - в начале работы над проектом проводится воркшоп где бизнес процесс декомпозируется на domain events, затем определяются domain commands и определяются границы доменов. Проектирование начинается с эвентов и события являются частью доменной модели (и ubiqinous language)

- Eventsourcing + eventually CQRS - в некоторых доменнах нужно фиксировать намерения которые привели к определенному состоянию и здесь без списка событий никуда

- передача domain events за пределы bounded context (обсуждалось выше)

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

https://github.com/eldadru/ksniff вот эта штука ставится плагином и очень хорошо работает. Сразу локально прокидывает трафик в WireShark

А внутри bounded context?