OrangeLoop.Sagas 1.0.9

View full documentation and examples on github.

Summary

Often, our business processes are spread across multiple services and repositories. When a customer completes an order, for example, we need to update the status of the payment and the order in the database. This simple scenario could involve our PaymentsRepository and our OrdersRepository, and must fail or succeed together. If an exception occurs while updating the order status in the database, we would need to rollback any changes we made to the payment status as well.

In this example, we assume our business process executes in the same process (e.g. Web Request), and that the operations which must all succeed or fail together involve the database. The traditional way to handle this is to wrap our queries in an IDbTransaction, and rollback the transaction if there is an exception. The challenge with using the IDbTransaction directly is that our Order related query and our Payment related query must be grouped together. This doesn't work when using the Repository Pattern, and injecting repositories into our services.

The Unit of Work pattern creates an abstraction of an IDbTransaction, and allows us to define a "Unit of Work" in our Services, rather than in our Repositories.

What about cross-domain business processes? If we have an Orders microservice, and a Payments microservice, we must make a call to each in order to update the Order and Payment statuses. The queries for each service are executing in separate processes, and using an IDbTransaction is no longer an option. Sagas to the rescue. A Saga defines a set of steps that must all succeed or fail together, and allows us to explicitly define the rollback process for each step.