Для шаблона поиска событий требуется шина событий.
Шина не требуется для поиска событий, если только вам не нужно уведомлять другие системы / домены об изменении (событии).
Если я хочу запросить текущее состояние этой сущности, мне нужно запросить все события, которые произошли с этой сущностью, и воссоздать ее текущее состояние.
Хорошо, вроде. Вам нужно только , чтобы сделать это, когда вы обрабатываете новую команду, , и вам нужно подтвердить, что применение команды не сделает "сущность" (как вы ее называете) несовместимой. Обратите внимание, что это относится к стороне команды CQRS, а не к стороне запроса.
Для стороны модели запрос / чтение у вас есть много различных опций. Обычно при использовании Event Sourcing используется отдельное хранилище данных, которое поддерживает денормализованную версию события и связанные данные, которые обновляются по мере возникновения событий. Это отдельное хранилище часто В конечном итоге непротиворечиво , что слишком много для go в целях данного ответа. Ваша модель чтения также может быть реляционной базой данных, простым файлом или буквально любым другим способом хранения данных, которые вы можете себе представить. Его данные хранятся в соответствии с моделью записи, получая события по мере их возникновения, через шину, опрашивая базу данных или другими способами.
Также абсолютно верно запрашивать поток событий и процесс (или частично обрабатывать их в реальном времени для построения запроса, но случаи, когда это необходимо, относительно редки.
Вся история событий присутствует в хранилище событий. Почему у меня не может быть микросервиса, который отвечает за сохранение каждого события в базе данных событий (если я хочу записать эти события для дальнейших действий. Что-то вроде kafka), и отдельный микросервис, который обновляет изменения в сущности в обычном базы данных (например, простое обновление документа объекта в mongodb).
Вы можете!
Когда эти микросервисы завершат свою работу, это событие будет удалено из события- store (допустим, я реализую это хранилище событий, используя очередь).
Вы можете сделать это тоже, но тогда вы не будете использовать Event Sourcing. Это больше похоже на «Event Driven Architecture», которая возможна и полностью действительна без использования Event Sourcing, но не предоставляет все те же преимущества. В системе с источником событий хранилище событий является источником правды для данных, а очередь не является допустимым местом для хранения правды, поскольку на самом деле она не предназначена для долгосрочного хранения данных.
Когда вы делаете CQRS, и особенно когда вы делаете Event Sourcing, вам нужно изменить свою ментальную модель того, что означает «текущее состояние». Фактическая истина хранится где-то (хранилище событий, реляционная база данных и т. Д. c.), И когда вы запрашиваете, вы проецируете эту истину в любой необходимый вам формат.
Например, у меня есть база данных пользователи, которые хранят FirstName в одном столбце и LastName в другом. У строки, которая представляет меня, есть «Фил» в столбце «FirstName» и «Sandler» в столбце «LastName». Когда я показываю данные в пользовательском интерфейсе, я отображаю их как «Сандлер, Фил». Почему бы просто не сохранить его в базе данных документов под именем «Sandler, Phil» и покончить с этим? Потому что, нормализуя данные, я точно записал правду и имею возможность проецировать данные по-разному в будущем, если возникнет такая необходимость.
Как и текущее состояние в приведенном выше примере, данные хранятся в двух столбцах или это "Сэндлер, Фил"? В CQRS вы должны думать не об этом с точки зрения текущего состояния, а с точки зрения ваших двух отдельных моделей: правды (сторона записи) и того, как она проецируется (сторона чтения).