Параметры хранилища для запросов к моделям чтения

Question

Когда я использую CQRS и Event Sourcing - мне интересно, какие у меня есть варианты для агностического опроса моих моделей чтения, если они создаются удаленным обработчиком событий, а не внутри моего проекта презентации.

Я использую NServiceBus для отправки команд и публикации событий, и я настроил проект приложения для прослушивания событий и построения моделей чтения в RavenDB.

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

Первоначально я думал об использовании запроса / ответа NServiceBus, но различные вещи, которые я читал, были против этого.

Есть ли варианты для этого?

Редактировать из комментариев

Я занимаюсь созданием моделей чтения в ravendb, используя отдельный запущенный процесс для прослушивания событий и сохранения результатов.
Единственные варианты, которые я нашел для получения результатов этих построенных моделей, - это подключение моего объекта презентации (веб-API) к ravendb. Это то, чего я пытаюсь избежать.

Зачем?

Хорошо, если я хочу увеличить количество экземпляров моего веб-API до 20, чтобы сбалансировать запросы, каждый экземпляр должен был бы подключиться к ravendb - в дополнение ко многим процессам построения моделей чтения, которые я уже подключил. Создание Равендб узкое место.

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

Об этом подходе я прочитал 2 статьи:

Этот говорит, что не делай этого http://andreasohlund.net/2010/04/22/messaging-shouldnt-be-used-for-queries/

Этот говорит, что пойти на это http://www.udidahan.com/2007/11/10/asynchronous-high-performance-login-for-web-farms/

Answer 1

Если вы все делаете правильно, вы выбираете модель чтения, которая чрезвычайно хорошо ориентирована на задачу чтения, которая у вас есть под рукой. Если вы не думаете, что собираетесь поменять его, просто используйте продукт напрямую! Идите против простого интерфейса SQL (например, jdbc, ado.net) для реляционной модели чтения. Используйте Cypher для графической модели. Используйте собственный API для хранилища значений ключей. Не добавляйте еще одну абстракцию; это большая часть разделения чтения и записи в первую очередь.