Using EventStore in a CQRS "architecture" makes unnecessary the use of a message bus?

Question

I'm pretty new to the paradigms and associated architectures such as CQRS. I started a project where I think this type of technology fits. I found it interesting use EventStore in the project, but I read a bit in the documentation and I see that the use of EventStore makes it unnecessary to have a message bus, as the EventStore itself allows the subscription to events - is this correct? Would I have some advantage in implementing a bus on the top of EventStore?

Answer 1

Message bus and event store are two different things that serve two different purposes.

The EventStore (GES) allows subscribing to events by using subscriptions, either client-tracked or server-tracked (competing consumers), plus long polling of ATOM feeds. Events organised into streams and each stream havign its own name, contains events for this stream. As CQRS and EventSourcing usually applied for DDD projects, streams are usually represent aggregates and reading individual streams allow re-creating the aggregate state and reading events from a stream category (aggregate type) is used for projections (building read models). Each subscriber control its own process of reading events and since events are stored, you can read them as many times as you want.

Message bus has nothing to do with saving events. It targets on reliably delivering messages between endpoints. Message bus usually supports broker or federated topology and different patterns like direct send, publish-subscribe and request-response. Once a message consumers ACKs the message, it is removed from the queue and cannot be read again. If you have no subscriber for messages that are getting published, you lose them forever.

Meaning, both are useful patterns but event store is used more for persistence and message bus / broker for durable queues and reliable delivery.

Answer 2

I tend to think of it like this, and this is how we have it set up:

Message Bus: Handling of command and event brokering. This used to communicate between various services and to broadcast events. "Event" in this context is transient. It's just there for subscribers to trigger off of.

EventStore: This is for the storing of actions taken against a domain entity. "Event" in this context is persistent. It exists to replay and gain 'state' for an object.

You can't replay transient messages because they only fire once and then they are consumed. Events in the EventStore are persistent/replayable and are replayed to gain an objects state or to build a projection. One is a broker, the other is a source.

Keep a thick line drawn between the two physically and conceptually.