Error handling of event aggregator with rollback

Question

I learn a lot of the general ways that developers develop / archive a domain-driven application (still trying to understand the concept as a whole). Some of the examples I saw included using events through an event aggregator. I liked the concept, because it really supports different elements / domains of the application.

I have a problem: how do you roll back an operation in case of an error?

For instance:

Let's say I have an order application that should save the order in the database, as well as save a copy of the order in pdf format for CMS. The application fires the event created by the new order, and the pdf service that subscribes to this event saves the PDF file. Meanwhile, when making an order change to the database, an exception is thrown. The problem is that the pdf was saved, but they did not match the database record.

Do I have to cache previously processed events and fire a new error event that looks at the cache for undo operations? Use something like a command template for this?

Or ... an event aggregator is not a good example for this.

Edit

I am starting to think that perhaps events should be used for less "critical" elements, such as emailing and logging.

My initial thought was to limit dependencies using an event aggregator pattern.

Answer 1

You want the event to be committed in the same transaction as the operation in your database.

In this particular scenario, you can click on an event in the queue that ends with your transaction, so that the event will never disappear if the aggregate is not saved. This will make PDF creation consistent; if the creation of the PDF fails, you can fix this problem and automatically restart it.

Perhaps you can get more inspiration in one of my previous posts on possible consistent domain events with RavenDB and IronMQ .

Answer 2

Processing of an event before its actual (perfect) action is performed only if the event handler is involved in the transaction. Make an event handler transaction (for example, by storing a PDF in a database) or publish and process events after the transaction.