Views

When you process a command, the system might change its state - and in an event-sourced system, all state changes are described by appending one or more events to the event stream.

In order to make that state available to be read, we have the concept of "projections", which is a general term for whatever can be derived off of the event stream, or "views" which kind of insinuates that the purpose of this particular projection is to be seen by someone :)

In a system based on the CQRS architectural principles, you will use projections to generate all the read models. Generally, you'll probably create a read model for each shape your data can take, in extreme cases maybe one specialized view per screen in your application.

With Cirqus, you can create views with an "event dispatcher" - an event dispatcher is an implementation of IEventDispatcher whose only purpose in life is to do something with the events.

Cirqus has an event dispatcher implementation, the "view manager event dispatcher", which is capable of dispatching events to one or more views. It will manage its views asynchronously behind the scenes and make sure that each individual view automatically catches up with all events that might not have been processed by that view.

Other kinds of event dispatchers might send events off-site, perhaps into or out of the cloud, or perform various downstream integrations like e.g. send emails, put events on a company's event bus, etc.