“The magic for a developer is doing something cool that no one else can understand” (myself few minutes ago).
The first step into this maze of cool messaging terms and tools left me with the feeling that most of them are not really relevant. After years of studying and practising, all these messaging and service oriented concepts melted with DDD and CQRS are making a lot of sense.
In this post I’d like to take out of my personal repository something that helped me in that journey.
Some time ago I read a very interesting blog post by Pablo Castilla https://pablocastilla.wordpress.com/2014/09/22/cqrs-with-event-sourcing-using-nservicebus-event-store-elastic-search-angularjs-and-asp-net-mvc/
I started studying it and I found it simple and complex enough to be taken as base template for my DDD + CQRS + Bus projects. Unfortunately after a while the trial version of NServiceBus expired on my home PC and then I decided to change the bus infrastructure from NServiceBus/MSMQ to EasynetQ/RabbitMq. Everything else is the same as in the original blog by Pablo except that I have updated all projects and libraries to the latest versions.
The solution’s work flow…
When you switch from a Bus generic framework like NServiceBus to a Bus Specific tool like EasynetQ a lot of configuration settings disappear.
For example you don’t need any more EndPoint config classes implementing those curious interfaces like IWantCustomInitialization
If you decide to adopt a Broker based solution you don’t have to waste hours and set every aspect of all little nice features that NServiceBus provides using xml config files or its fluent configuration. Instead you can immediately start to be productive and without paying much attention to configuration, you can start coding your app features and you publish and subscribe messages. Pay attention to some of the bad side effects of message patterns and take care of problematic scenarios if you have to. RabbitMq is a mature and solid infrastructure piece of software and it offers many solutions. EasynetQ is a little easy to use tool that offer a quick and clean Publish Subscribe mechanism.
Another consideration on NServiceBus here is that using Event Store you can rely on a feature built in it that allows you to manage long running processes. In this way you don’t need one of the nice features that NServiceBus provides called SAGA http://docs.particular.net/nservicebus/sagas/
Instead of using a Saga with NSB that finally is a class that stores everything happening around a process in a single storage like SqlServer with Event Store, is like defining an Aggregate that contains a stream of events and define projections running continuously and that allows you to react when something happens.
Said that, NServiceBus is an elegant library which is full of message features that can solve a lot of distributed architecture problems.
This is the code: https://github.com/riccardone/CQRS-NServiceBus-EventStore-ElasticSearch
References:
EasyNetQ
http://easynetq.com/
RabbitMQ
https://www.rabbitmq.com/
Eyyyy! Thanks for your comment about my work! You made my day.
I will take a look at your code.
Currently I am investigating in another direction. Without dtc+msmq+relational database I prefer a more aggressive approach using akka.net. Look at persistent actors, I think they fit better with the cqrs+ event sourcing. And also it scales really well with akka clustering. I am preparing a post about it.
This people have a good tutorial.
https://petabridge.com/bootcamp/
But NServiceBus is great in some scenarios, specially with msmq.
Hi Pablo,
I know Akka.net I did a proof of concept time ago and I like it. I look forward for your post and I will probably end up using it as the base for my next post 🙂
For what I have understood Akka .net is a library that you can use to build a group of loosely coupled message handlers to compose a kind of distributed pipeline/filters. You can use it to improve performance but it doesn’t provide graphical monitoring tools, a proper persistence feature to handle disaster scenarios. Lastly for production ready solutions I’m not sure if they provide a proper commercial support.
Anyway, I’m also considering using a “private” Event Store node behind each business component and use it like the way that NServiceBus communicate between separate EndPoints with msmq.
Is like… I found good theories but now there are too many tools and combinations to implement those principles!
What I like about Akka is that you can choose between different levels of consistency: at least one delivery actor, persistence actor, reentrant actor… And different routing strategies (scalability). I will try to create a concept mixing Akka persistence and Akka clustering, let’s see what I can get 🙂
I am with you about tools! At actor level we have Akka and Orleans! Too much tools and too little time to test them! 🙂
Maybe you know it, regarding event store there is a nservicebus transport based on it, you can look at it to get ideas 🙂
https://github.com/SzymonPobiega/NServiceBus.EventStore