но не получается ли тут, что отправитель знает о получателях? В том смысле, что при изменении получателей надо будет изменять код отправителей?

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

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

каким образом?

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

Черная магия, офк. У тебя на исходящие сообщения точно такой же роутинг, как и на входящие. Можно кидать в разные транспорты, разным получателям. Да хоть во все транспорты сразу для 1 сообщения, и в девнулл для другого

Степу потыкай палочкой, расскажет) он был основным заказчиком роутинга)

Но это делается на этапе конфигурации все. В рантайме ты маршруты доставки изменить не можешь

Черевато

Точнее как... Технически а рамках 1 транспорта можно и в рантайме наебать систему, но эт надо немного захотеть

инфраструктура знает о получателях, отправитель ничего не знает

ну вот мне еще это предстоит... пока просто такой вот базовый функционал без которого ну никак

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

Всем привет! Такой вопрос интересный, наверное, слишком простой, но хочу уточнить как лучше правильно сделать.

Есть система некоммерческих организаций. В данной системе есть члены. Членами могут быть физ лица, юридические лица и общественные объединения (какой-то коллектив). Из-за этих типов есть расхождение в полях. Например, у физ лиц есть дата рождения, у юр лиц нет. У юр лиц есть огрн у физ нет. И т д

Вопрос простой: нужно ли разделять эти типы на разные сущности или это все Member?

Наверное мою систему можно сравнить с какой-то CRM где есть клиенты.

да

На самом деле и так и сяк может быть. Именно по этому подобные вопросы бесполезны.

Сущности не нужны избавьтесь от них
https://udidahan.com/2012/03/05/dont-try-to-model-the-real-world-it-doesnt-exist/

Проще узкоспециализировать приложение

Для одних котлеты, для других мухи, третьим ещё что то

Понял) В принципе зависит от контекста)

Моделируйте membership. Это Members, а в сущностях ЮрЛицо или ФизЛицо есть ID member-а.