Category: Patterns

Event Stream as a Message Queue

Derek Comartin 3 Comments

I was recently having a discussion around a system being built using Microsoft Azure.  Some concepts being discussed for this system where CQRS, Event Sourcing and Message Queue.

The diagram below is fairly typical when discussing CQRS and Event Sourcing.

Message Queue

One of the first things that stood out to me was the use of the Message Queue and Azure Service Bus.

For this blog post, I want to focus on the Service bus, which is used for publish-subscribe pattern.  The domain will emit events that are stored to the event stream and then will be published to the Service Bus.  Subscribers, such as Projections or other Bounded Contexts will process these events.

Forgotten Option

There is nothing wrong with using a service bus to publish domain events.

However, one option which is seemingly always forgotten to developers that are new to CQRS and Event Sourcing:

Your event stream can be used as a message queue

Other bounded contexts or projections can query/poll your event storage to retrieve new events that have been persisted.

At regular intervals, the event consumer could poll your event storage requesting any number of new events based on the last event it processed.

The consumer would be required to keep track of the last event it processed in order.  This provides some benefits as it may not be a process that is required to be continuously running.

You may be thinking: Polling? Really?

If you rolled your own event storage, I could understand how this might be problematic and would likely be easier to use a service bus.  Or you may want your event consumers to process the event as soon as possible.  Your implementation of how to handle this is dependant on how you are currently storing your events.

But the point still remains: Your event stream is a message queue.

As always, context is king.  Requirements and many other factors will play into how you want to handle messaging.

It is another option that may fit a scenario that you run into.

Event Store

Event Store

If you are just thinking about getting into Event Sourcing, I would highly recommend looking at Event Store by Greg Young as your event storage.

Event Store supports multiple types of Subscriptions including Persistent Subscriptions for the Competing Consumers messaging pattern.

Handling Async Await Exceptions

Derek Comartin Leave a comment

Async Await Exceptions

Async/Await

There’s a ton of information about async await support in .NET 4.5.  I don’t want to go over all the best practices and gotchas in this post, but I did want to point out one common trend I’ve seen lately, which is handling async await exceptions.

Await or forget about it

Any async method that returns a Task or Task<T>, you should always await the result.

If you do not await, any exceptions that occur in the calling method will be swallowed.  Essentially you are turning the method call into a fire and forget.

Async Await Exceptions Example

Below is a simple example that demonstrates two behaviors of calling await on an async.  

To run the example, just copy and paste in a new console application.  If you run with the debugger, you should notice the following:

  1. MethodCallWithoutAwait will be called, however no exception will be raised in the debugger because await is not called.
  2. MethodCallWithAwait will be called and the exception will be raised in the debugger because await is called.

Async Lambdas

There be dragons!  Next post I’ll explore of using async lambdas and how you need to pay close attention in order to avoid creating a void lambda.

Mediator Pattern using MediatR and Unity

Derek Comartin 7 Comments

MediatRIn a couple previous posts I’ve discussed using Query Objects instead of Repositories and the Mediator pattern.  I find creating query objects being used with the command pattern much cleaner than polluting repositories with a ton of query methods.

The concept is nothing new as many people already use the command pattern in the context of executing commands/behavior following CQRS.   However, there is nothing wrong with using the same patterns for the query side.

I’ve been using my own home grown solution of the mediator pattern in a few different projects but had nothing really formalized.  I was thinking about creating a simple library until I stumbled upon MediatR created by Jimmy Bogard.

It is incredibly simple and only has one dependency, CommonServiceLocator.

The Github repo has a good set of docs and some examples with different dependency injection containers.

Unity RegisterType

I did notice the Unity example didn’t quiet work as described in the example.

The Mediator class takes a ServiceLocatorProvider in its constructor which was not being resolved properly by Unity.

In order to get it functioning correctly, I defined an injection factory and created the Mediator and passed in the UnityServiceLocator.

My complete Unity configuration which is also using MediatR to publish events from NEventStore:

MediatR v2.0

Although v1 has a dependency on CommonServiceLocator, it appears that v2.0 will not have any external dependencies.

MediatR