Бенджамин совершенно прав относительно цели поиска событий.
Мой ответ нацелен на добавление некоторых дополнительных деталей.
Первый:
Читать модели и проекции не должны представлять совокупное состояние.
Прогнозы - это способ для систем, основанных на событиях, построить модель чтения для CQRS. В сущности, CQRS постулирует, что модели записи и чтения обычно служат различным целям, и поэтому имеет смысл использовать другую модель для стороны чтения.
Поэтому вы часто встречаете несколько проекций, строящих разные узконаправленные модели, ориентированные на конкретные c нуждается в запросах.
Секунда:
Под "решением проблем согласованности" вы, вероятно, подразумеваете, что в системах с источником событий каждый переход состояния представляется как событие (или несколько событий). Следовательно, запись всегда транзакционная. База данных, которую вы выбираете в качестве хранилища событий, должна поддерживать (может использовать некоторую библиотеку или дополнительный инструмент) подписку в реальном времени, которая позволит вам получать новые события в вашей проекции, в порядке . Для новых прогнозов он начнет читать с самого начала и в конечном итоге появится в режиме реального времени. Подписки обычно должны сохранять текущую позицию обработки в глобальном потоке событий, поэтому, когда проекция перезапускается, она начинает получать события из точки, которая ей известна в последний раз.
Делая это, вы гарантируете, что каждый переход состояния в модели записи будет отражен в модели чтения. Это, вероятно, то, что вы имеете в виду в своем первоначальном вопросе.
В-третьих:
Теперь все вышеперечисленное подразумевает, что вы не можете использовать шину сообщений (только) для доставки события к прогнозам. Брокеры не дают никаких гарантий заказа и могут доставить одно сообщение более одного раза. Кроме того, брокеры сообщений не хранят историю, поэтому вы не можете строить новые прогнозы по желанию.
Однако это не означает, что вы вообще не можете использовать брокеров. Некоторые проекции не требуют упорядочения и являются идемпотентными. Но канал для событий, публикуемых через брокера sh, имеет ту же подписку, поэтому вы получаете гарантированную доставку и при необходимости можете читать прошедшие события.
Четвертый:
CQRS не подразумевает отдельные базы данных. Иногда использование CQRS просто означает, что вы используете некоторый уровень персистентности для своих доменных объектов, поэтому вы читаете и пишете агрегаты. Но для запросов, вы просто запрашиваете по желанию, что вы хотите. Представление базы данных является техническим примером CQRS.
Почти здесь:
Проекции не должны иметь почти никакой логики c, это правда. Главное здесь - обеспечить идемпотентность, если это возможно, поэтому в прогнозах обычно не следует использовать операции для вычисления новых значений на основе старых значений и информации о событиях.
Но прогнозы будут знать о вашем домене. Все в вашей системе должно знать о вашем домене.
И последнее:
Вы можете определенно использовать разные базы данных для записи и чтения моделей, не обращаясь к Event Sourcing. Вам просто нужно выбрать базу данных, которая поддерживает ленту изменений. SQL Сервер, Postgres, CosmosDb и другие базы данных имеют такую функциональность.
PS Я бы посоветовал потратить некоторое время на изучение этих концепций. Я могу указать на хранилище книг, оно имеет примеры CQRS и Event Sourcing: https://github.com/PacktPublishing/Hands-On-Domain-Driven-Design-with-.NET-Core