Cover image for Plug your existing domain models into NServiceBus Sagas

Plug your existing domain models into NServiceBus Sagas

vlerx profile image Mohsen Bazmi Updated on ・2 min read

“An NServiceBus saga is an Aggregate root.” Udi Dahan

“An aggregate can be seen as a state machine/workflow so a very good solution when using NServiceBus is to use sagas to implement aggregates.” Mauro Servienti

Mauro Servienti also states that, if needed, domain events can be published by NServiceBus. There is no need to reinvent the wheel.

This article will explain how to plug an “existing” aggregate into an NServiceBus saga.

But why should one ever do that? Why not use sagas as aggregates instead of adding another layer of indirection?

Because legacies are everywhere. Maybe you aren’t using NServiceBus already and now you want to adopt it. For example, you may have “deferred” some infrastructural decisions while designing your system, and now you’ve come up with adopting NServiceBus to make your system more scalable, or eliminate the maintenance of all the unnecessary home-made implementations, and focus on solving your core business problems instead. Let’s keep it short.

Imagine the following user aggregate:

Now we want to plug it into the following NServiceBus Saga:

So we don’t have to implement the repository to persist the user aggregate. The saga takes care of that for us.

Another benefit is that NServiceBus publishes the domain events which keeps us from maintaining all the unnecessary infrastructure to store the events, pick them up, put them into the queue, notify the listeners, and preserve the transaction consistency.

We need to focus on our core business problems instead of reinventing the wheel.

But what about the order of the events? Does NServiceBus preserve the order of the events? Well, as far as I know, NServiceBus does not have that option. The order of messages matter in some scenarios. Preserving the order is not the responsibility of the messaging infrastructure. We can easily attach a version to each event before publishing them, which can be a subject for another post. Here is a modified version of the previous extension method to show the idea.

You got it. But it’s tricky to plug your domain events into sagas. The complete runnable code sample and the additional classes that help the NServiceBus SagaData class wrap the aggregate can be found on my GitHub. I hope that helps.

Special thanks to Mauro Servienti, solution architect from Particular Software for answering my questions, and for helping me with editing this article.

You can use sagas as your aggregate roots and keep things simpler, but in legacy scenarios, it’s usually not worth it.
You may have “deferred” some infrastructural decisions and now you’ve decided to adopt NServicebus to make your system more scalable.
An NServiceBus Saga can wrap DDD style aggregates so that you can focus on your core business problems.

Focus on your core business problems rather than implementing Infrastructure.

Thank you for reading.

Posted on by:

vlerx profile

Mohsen Bazmi


10 years experienced developer, passionate about software architecture, with background of using multiple languages, methodologies, and technologies.


markdown guide