Вышеупомянутый сценарий будет применяться к любым библиотекам источников событий, поэтому есть ли какой-либо код инфраструктуры поверх этого, который я могу использовать, или мне нужно использовать собственный?
Понятие механизма Проекции, привязанного к событиям, безусловно, широко распространено. К сожалению, существует множество способов сделать это в зависимости от вашего стека, требований к производительности и масштабируемости, а также многих других факторов.
В результате я не знаю о коммодитизированном объекте такого рода.
Магазин GetEventStore имеет встроенную возможность проецирования, которая выглядит чрезвычайно мощной и избавляет от необходимости создавать все это вне стола. До его существования я бы сказал, что не следует даже думать о том, чтобы игнорировать SRPness JOES.
Вы почти ничего не сказали о своем реальном стеке, кроме как упомянули Azure.
Как с помощью служебной шины Windows связать порядковые номера в моем хранилище событий с порядковыми номерами в служебной шине?
Вы можете использовать идентификатор потока + порядковый номер фиксации MessageId (и использовать его, чтобы гарантировать удаление дубликатов шиной). Вы, вероятно, также включите свойства в метаданные сообщения.
Каков наилучший способ обнаружения и обработки уже полученных событий безопасным способом (защита от сбоев обработчиков сообщений)?
Если вы используете Azure и рассматриваете ServiceBus, то темы можно использовать для обеспечения хотя бы однократной доставки (и вы будете использовать средство сеансов). Посмотрите двухчасовое подробное видео по подписке ClemensV плюс несколько других эпизодов, иначе вы потратите столько же времени на ошибки)
Чтобы ограничить широковещательный трафик, если ContextC запрашивает повторы из ContextA и ContextB, есть ли способ, чтобы эти сообщения воспроизведения были отправлены только в ContextC? Или мне не стоит об этом беспокоиться?
Mu. Вы начали спрашивать, была ли эта идея хорошей, но теперь, кажется, усвоили предположение, что это правильный путь.
Во-первых, эта инфраструктура - огромное колесо, которое нужно изобретать. Думали ли вы, что просто создать тему для каждой BC и попросить кого-нибудь, кому нужно слушать, слушать?
Ключевым моментом здесь является то, что вам нужно иметь в виду тот факт, что только потому, что вы можете думать о случаях, когда BC должны потреблять события друг друга, этот центральный волшебный автобус, который повсюду, доставит все повсюду.
РЕДАКТИРОВАТЬ: ответы на ваши отредактированные версии вопросов 2+
Как в Windows Service Bus 1.0 объединить порядковые номера в моем хранилище событий с порядковыми номерами в служебной шине?
В вашем хранилище событий нет порядкового номера. У него есть порядковый номер фиксации для каждого агрегата. Обычно вы используете сессионную тему и подписку. Затем вам нужно выбрать, хотите ли вы глобальное упорядочение (использовать один идентификатор сеанса) или агрегированное упорядочение (использовать идентификатор потока в качестве идентификатора сеанса).
Как только события относятся к теме, они получают MessageSequenceNumber, и подписка (при наличии сеанса) доставляет (фактически подписчик их получает) их последовательно.
Каков наилучший способ обнаружения и обработки уже полученных событий безопасным способом (защита от сбоев обработчиков сообщений)?
Это встроено в служебную шину (или в любой механизм очередей). Вы не отмечаете сообщение как завершенное, пока оно не будет успешно обработано. Любой сбой приводит к прекращению использования (что возвращает его в очередь на повторную обработку).
Абонент, который делает перерыв, отключается от сети или выполняет резервное копирование, естественно, рассматривается в Теме.
person
Ruben Bartelink
schedule
16.03.2013
