Я вижу использование EventStore делает ненужным имея шину сообщений < надреза > ... это правильно?
Да, использование магазина событий может сделать сообщение автобусом ненужным. Хранилище событий - это постоянная очередь, где вы можете либо напрямую просматривать события, либо в случае GES вы также можете подписаться на события по мере их возникновения. Помимо GES, в других магазинах событий вы можете прибегнуть к опросу базы данных, чтобы получать новые сообщения из процесса из базы данных. (Периодически отправлять запрос на «все сообщения с X».)
Одним из основных отличий между шиной сообщений и хранилищем событий является то, что подписки будут «тянуть» вместо «нажимать». Шина сообщений «нажимает», где она решает, что вы видели и что вам еще нужно. Магазины событий, которые я видел, используют модель «тянуть» (из-за неработоспособности), где вы отслеживаете свой контрольный пункт. Для этого есть небольшая учетная запись (периодически сохраняющая вашу контрольную точку), но также есть много возможностей, как вы увидите ниже.
Примечание: GES имеет модель push, но для сценариев производителя/потребителя, не доставляя одно и то же сообщение нескольким конечным точкам.
Другое отличие состоит в том, что вы не можете обычно сообщать о шине событий для отправки вам всех сообщений, начиная с X. Даже если у этого есть эта функция, в зависимости от того, как давно X был, у этого могут больше не быть эти сообщения. Поэтому, если вы обнаружите ошибку в коде, вам, возможно, придется обратиться к ETL из одной системы в другую, чтобы исправить ее. Ошибки всегда происходят, поэтому в итоге у вас есть два разных процесса распространения данных: один на основе событий для счастливого пути и один на основе ETL для исправления данных.
Но с хранилищем событий вы можете использовать тот же процесс для счастливых путей и исправлений данных. Все события все еще существуют (по умолчанию, если не настроено иначе), и с помощью модели pull вы контролируете, какие сообщения вы хотите видеть. Так что, учитывая ту же ошибку, вы можете исправить код, затем затушить затронутую модель чтения, установить контрольную точку в ноль, и она будет восстанавливаться с нуля при перезапуске. Не нужно также разрабатывать процесс ETL. (Проблема с Ops: если ваш магазин событий большой, перестройка может занять некоторое время, но вы можете создать первоначальную перестройку рядом со старой моделью и просто поменять ее в окне обслуживания.)
Дополнительная информация/опыт работы с этим можно найти here.
Автобус по-прежнему имеет смысл в других сценариях ... например, когда имеют значение только последние сообщения. Или когда есть слишком много сообщений, чтобы их можно было сохранить.
Будет ли иметь преимущество в использовании шины в верхней части экрана EventStore?
Я бы так не подумал. Топология, которая может иметь смысл для этого случая, заключается в том, чтобы некоторый код подписался на хранилище событий и опубликовал новые сообщения на шине для обновления многих слушателей (например, для масштабирования чтения).Однако этот сценарий будет лучше рассмотрен с использованием специфических функций GES. А именно, HTTP API с использованием AtomPub и кеширования прокси. Поскольку события неизменны, после того, как они видны один раз, их можно бесконечно кэшировать на каждом уровне. Это должно избегать необходимости попадания в хранилище событий, за исключением того, что впервые опубликовано сообщение. Это все еще позволяет клиенту сохранить контроль над собственной подпиской.
изменен тег из магазина событий (NES) для получения события-события (GES) - если вы имеете в виду http://geteventstore.com. Также я бы посоветовал вам немного рассказать о бизнес-функции вашей системы как целое и/или подумать о переходе в списки рассылки ddd-cqrs-es или eventstore –
У этого вопроса нет ответа, кроме «сравнить возможности, предоставляемые GES, и любую служебную шину, которую вы рассматриваете». Как упоминает @RubenBartelink, вы должны подробно описать свои бизнес-функции. – tomliversidge
@dotnetguy: Большое спасибо за исправление грамматики. –