CQRS has several internal patterns and objects types like Commands, CommandHandlers, Events, EventHandlers, and a few others. In the following diagram I show a basic diagram positioning those topics:

I am not going to explain CQRS philosophy here, as you can read about it in many posts from Greg Young, Udi Dahan, Martin Fowler, etc.

The only thing I want to highlight before going further is that CQRS is not a top-level architecture. On the other hand, it should be used only for certain scenarios/contexts, certain areas within a complex application: Only for selected BOUNDED-CONTEXTS (in DDD lingo).

The point is that this kind of pattern or approach provides (as a consequence) very high scalable applications; therefore, it fits great in Cloud-Computing platforms, like Windows Azure.

In this post I only want to focus about what Windows Azure technologies we could use for the CQRS Buses.

First of all, all the communications based on the CQRS Buses are asynchronous. The Bus could be implemented in many different ways. For a Proof of concept and having a single server, it could even be an In-Memory Bus. But, if we have a real and scalable system, we’d need a Bus implementation placed on a global position, accessible from any Front-End and Back-End server.

We put/send COMMANDS into the Bus from the Presentation Layer (if using a server UI, like ASP.NET MVC. If the UI is remote, like HTML5, Silverlight, WPF, etc., then, we’d probably have a Web-Service Layer in between, like WCF or REST Web-API). But, the important point here is that COMMANDS will be taken from a single point (COMMAND-HANDLER) and they will be processed only once (like process ‘RegisterAttendee’ COMMAND). It is something we order to our system, so it is an imperative verb.

In any case, for handling COMMANDS, we’d need any asynchronous system that will allow to process messages, and each message will be taken and processed just once. A Message-Queue system would be nice for this purpose. Talking about Windows Azure technologies, we could use Windows Azure Storage Queues, based on the Put message and Peek message functions.

On the other hand, EVENTS are generated when a COMMAND is already processed and persisted. It is done & finished, so all events’ names are past tense verbs, like ‘AttendeeRegistered’ EVENT. But, and here comes an important difference, EVENTS can be consumed from many systems in order to propagate changes. They can be processed by the EVENT-HANDLER, but also from other BOUNDED-CONTEXTS and event from external systems. Therefore, we could use a Publish/Subscription approach for this topic. Talking about Windows Azure technologies, we could use Windows Azure Service Bus.

Below is shown a more specific diagram where Windows Azure technologies are highlighted:

It seems clear that in order to have a publish/subscription approach (for EVENTS), we need the Windows Azure Service Bus. Regarding COMMANDS, we could use Windows Azure Storage Queues, but the Service Bus is also a possibility here, too.

A few months ago, before having the Windows Azure SDK 1.5, the Service Bus was not supporting message queues, but now, it supports persistent queues plus a richer set of functionality like integration with WCF communication stack, transactional behavior, a guaranteed first-in-first-out (FIFO) ordered delivery, publish and consume message batches, etc.

Additionally, the Windows Azure Service-Bus price is quite similar to the Windows Azure Storage Queues price.

In the following link you can see a detailed comparison between the Windows Azure Service-Bus and the Windows Azure Storage Queues, taking into account Capabilities, Capacity, Quotas, Management, Operations, Performance and Prices:

http://msdn.microsoft.com/en-us/library/hh767287(VS.103).aspx