Command Processor

The Command Processor is what makes Cirqus work. It contains all the settings and essential components of Cirqus. As you could guess, the command processor processes commands. Like so:

var result = processor.ProcessCommand(new MyCommand(someArguments));
bool success = result.EventsWereEmitted;

Components

Event Store

The event store stores and retrieves the events. Cirqus offers integrations with several kinds of persistence: SQL Server, MongoDB... You can choose where you want to store your events.

See Event store for examples and details.

Logging and profiling

Cirqus has some options that lets you log all of its actions. It also allows you to profile the hydration of Aggregate roots. Take a look at Logging and profiling to learn how to configure them.

Event dispatchers

Events can be dispatched to Views / View managers using an Event dispatcher. They are the recommended way to retrieve data with Cirqus. The event dispatchers can be configured with the fluent configuration API in the Command Processor.

Repository

The fluent configuration API also allows you to configure some settings for the aggregate root Repository.

Command processor options

While the command processor is generally used to configure every component of Cirqus, it also has some configuration options itself. Use the Options() method to supply them.

var processor = CommandProcessor.With().....Options(opt=>
{
    opt.PurgeExistingViews(true);
}).Create();

Purge existing views

If set to true, Cirqus will empty all the existing views and start dispatching all the events stored in the Event store again.

Max retries

When an error occurs while processing a command, Cirqus will retry to process the command. This number defines how much Cirqus should retry to process the command. It's set to 10 by default.

Domain exception types

By default, Cirqus will wrap exceptions thrown while processing a command in a single CommandProcessingException. You can choose to let some types of escalate so that they are not part of the CommandProcessingException and you can catch them without interfering with other exceptions that occur during the processing of a command.

Custom domain event serializer

Cirqus serializes every exception before storing it in the event store. Under the hood, Json.NET by NewtonSoft is used. To modify this behavior, implement IDomainEventSerializer and reference it in the options configuration API.

Add command type name to meta data

If you wish, you can add the name of the executed command to the meta data stored together with the event in the event store.

Command mappings

As you can read in Commands, an ExecutableCommand contains a method that is executed when the command is processed. It's possible to create generic commands from the Command base class, but Cirqus doesn't know what to do with them. To let Cirqus know which action it should take when processing such commands, use command mappings. You just use the Map method like so:

var mappings = new CommandMappings()
    .Map<SomeCommand>((context, command) => {
        context.Load<SomeRoot>(command.SomeRootId).DoStuff();
    })
    .Map<AnotherCommand((context, command) => {
        context.Load<AnotherRoot>(command.AnotherRootId).DoStuff();
    });

The variable above can be put in the Options configuration API.

Domain type mapper

Throughout the application Cirqus converts the names of types to strings and back. To modify this behavior (e.g. if you want to use aliases for certain types), implement the IDomainTypeMapper interface and configure it with the Options configuration API.

Complete configuration example

var processor = CommandProcessor.With()
    .Logging(l => l.UseDebug(Logger.Level.Debug))
    .EventStore(e => e.UseSqlServer("CirqusDemo", "Events"))
    .EventDispatcher(e => e.UseViewManagerEventDispatcher(viewManagers.ToArray()))
    .Options(opt =>
    {
        opt.PurgeExistingViews(true);
        opt.SetMaxRetries(5);
        opt.AddCommandTypeNameToMetadata();
    })
    .Create();