Источник событий и CQRS не предназначены для разделения служб.
Основная цель, достигаемая с помощью CQRS, заключается в повышении производительности службы, поскольку для записи можно использовать другой тип персистентности (команда). и для операций чтения (запроса).
Благодаря этому вы можете использовать высокопроизводительную постоянную запись типа, такую как журнал событий, для хранения всех событий, происходящих в службе, и использовать реляционную модель, например, для операций чтения, где вы храните информация так, как вам нужно для ваших запросов.
Способ достижения согласованности между двумя моделями обычно заключается в использовании событий, генерируемых моделью команд, которые используются запросом для обновления модели чтения. Недостатком этого подхода является возможная согласованность, потому что обновление модели чтения не происходит сразу.
С cqrs тесно связан источник событий, который утверждает, что все модификации в модели должны храниться как события в магазин событий. Таким образом, у вас есть история c всех действий, выполненных в приложении. Преимущество этого состоит в том, что у вас есть история c всех изменений для целей аудита, и что запись выполняется чрезвычайно быстро. Недостатком является то, что если вы хотите получить текущее состояние, вам нужно воспроизвести все события с самого начала.
Чтобы решить эту проблему, вы используете cqrs, чтобы получить фактическое состояние для выполнения запросов