implementing CQRS - rebus-org/Rebus GitHub Wiki

Often people turn to service busses when they want to implement CQRS, because there's probably messaging involved. Here's a thing to consider :)

CQRS does not imply messaging. You can implement CQRS and have everything work in the same unit of work, i.e. the generation of events, denormalization, etc. There, I said it.

This has the benefit that the eventually consistent nature of your read model can be overcome if the underlying data store allows it. The downside is that it hampers your application's scalability, which might or might not be the reason you chose CQRS for your application.

If you do want to use messaging, I suggest you take a much more lean approach and build directly off of a simple queue API yourself. There's three reasons why I'm saying this:

• you won't need Rebus' advanced ESB stuff, like routing, pub/sub messaging, polymorphic dispatch, retries etc. etc.
• you'll benefit from the much simpler and leaner solution that you'll get, because you don't have to pull the weight of a framework
• you'll most likely appreciate having built your lightsaber yourself - because it's simpler, because it will do only what you told it to do, and because you'll understand much better how it behaves, and because you can tweak it to your will

I suggest you read everything that Greg Young (Greg's blog) and Rinat Abdullin (Rinat's blog) say, and study everything that they do. They're cool, and what they do is genuinely interesting.

If you are interested in using CQRS and event sourcing in your application architecture, and you are not interested in building your own specialized framework for these things, I recommend you take a look at Cirqus - it's lean, mean CQRS and event sourcing machine that we have built at d60 for a bunch of client projects, and it's actually pretty sweet :)