Вы не можете, но не должны этого делать.Может быть, есть несколько очень сложных методов, использующих распределенные транзакции, но они не масштабируемы.Вы не можете атомарно хранить и публиковать события, потому что вы пишете в две разные персистенции с разными транзакционными границами.Вы можете иметь синхронный монолит CQRS, но только если вы используете одну и ту же технологию для сохранения событий и постоянства readmodels.
В CQRS приложение разделено на стороны записи / команды и чтения / запроса (это длинное видео может помочь).Вы пытаетесь объединить две части в одну, понижение, если хотите.Вместо этого вы должны рассматривать их отдельно, с разными моделями (см. Проектирование на основе домена ).
Сторона записи не должна зависеть от результата со стороны чтения.Это означает, что после того, как хранилище событий сохранит события, будет выполнена запись.Кроме того, сторона «Запись» должна содержать все данные, необходимые для выполнения своей работы, - генерацию событий на основе бизнес-правил.
Если у вас есть разные технологии в части «Запись и чтение», тогда ваша «Чтение»сторона должна быть отделена от стороны записи , то есть она должна выполняться в отдельном потоке / процессе.
Один из способов сделать это - создать поток / процесс, который прослушивает добавление к событиюхранить, извлекать новые события, а затем публиковать их в сетке событий.Если этот процесс завершается неудачно или перезапускается, он должен возобновиться с того места, где остановился.Я не знаю, поддерживает ли CosmosDB это, но MongoDB (также база данных документов) имеет rslog, что вы можете tail получить новые события за несколько миллисекунд.