Несколько хранилищ распределенных событий для управления данными, работающие вместе

Question

Я играю с CQRS/event sourcing в течение нескольких месяцев. В настоящее время у меня возникают проблемы с другим экспериментом, который я стараюсь и надеюсь, что кто-то может помочь, объяснить или даже намекнуть на другой подход, чем на поиск источников.

Я хочу создать распределенное приложение, в котором каждый пользователь имеет управление своими данными. Поэтому моя идея заключается в том, что каждый пользователь имеет свой собственный хранилище событий, в то время как другие пользователи могут иметь (условный) доступ к нему.

Когда пользователь A выполняет некоторую команду, это может означать несколько хранилищ событий. Два примера:

1) Удаление общей задачи из списка задач, организованных как хранилище событий A и B

2) Добавление ссылки на комментарий сохраняется в событии магазина А на пост сохраняется в магазине события B.

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

Answer 1

Не знаете, в чем цель вашего решения, но если вы хотите, чтобы одна система реагировала на события из другой системы, после того, как события будут сохранены в магазине, подписка (например, догоняющая подписка, предоставляемая EventStore Грега Янга) публикует это на шине сообщений с использованием pub-sub, и все заинтересованные стороны могут справиться с этим событием.

Однако это будет неправильно, если они просто «сохранят» это событие в своих магазинах. На самом деле у них должен быть обработчик событий, который будет вызывать команду внутри локальной службы, и эта команда может (или не может) привести к локальному событию, если все условия выполнены. Только то, что происходит внутри границ, под местным контролем, должно быть сохранено в местном магазине.