Undo/Redo using Eventsourcing

[bneumann]

Hi there,

we are using Eventuous for quite a while now and it works like a charm. Now the customer came up with the idea to add Undo and Redo. We solved it partially by implementing our own derivate of the EsdbEventStore with access to the stream's Metadata and set a custom attribute where the last position is. So when we retrieve our aggregate it only reads up to that position (e.g. 2x undo -> end of stream-2).
That works quite well also incombination with truncation when the user wants to add something new.
But we can't wrap our head around the projections. Because they are base on catch up subscriptions. Is there a built in way to somehow resubscribe selective aggregates?

Maybe our approach is wrong, wouldn't rule that out, so if you have something clever in mind let me know ;)

Cheers

[alexeyzimarev]

Normally, event-sourced model focus on a particular business domain. It's not frequent that an actual business has an "Undo" operation. For example, how can you undo making a hotel reservation? You'd actually need to cancel it instead. A reservation cancellation is represented by an explicit command, which emits an explicit event, and it is not unconditional. Like, if the reservation is non-refundable, you would need to get some sort of confirmation as there will be no refund.

I am pretty sceptical about implementing such a functionality "in tech" like you did, to be honest. Maybe, an example of the actual use case would make things a bit clearer.

[bneumann]

You are correct. To give a bit of context: We are developing a tool that lets users easily create a Model to describe hardware and feature behavior. Like a DSL of sorts. It is mainly based on decision tables and custom data types that reflect our domain.
Now, the reason we chose EventSourcing was the ledger of events we get for free. Since we are a medical company, having a record for things is always good. The tool itself is not classified as medical software, but at a certain point in development we freeze the model, and you can't edit it anymore (and the history + immutability is a requirement in a regulatory sense).
BUT while in development, it can happen that the user made a mistake and wants to undo something.
To be honest, I simply took the requirement and thought about a technical solution. But now that you mention it, we already have a lot of commands and events that reflect the "undo" logic.

For instance, we can add an entry to a table. We can also remove it. We can set the conditions of the table and delete them. So like your cancelation example we should not model it technically but according to the domain.

My biggest fear is that we might end up implementing a lot of commands that are unnecessary just to fulfill some undo which is not really relevant, but again that is something I can bring up with our domain experts.

Thanks, Alexey, for the thought food ;)

[alexeyzimarev]

It's true that you might need compensating commands for those actions you want to allow to undo. But, the effort there might not be huge, as you know quite well what can be done. Also, you might already suspect that not everything can be "undone", and not everything that can be undone limitlessly with regards of time. For example, actions that trigger reactions in other systems can hardly be undone just by rolling one event back. A typical example would be that you can "undo" a package despatch until it's loaded on the delivery lorry. Once it's loaded, there's no simple "undo" :) I always prefer to think about at least some stuff that can go wrong. For example, I would prefer not to allow rolling back actions that produced events, which I know are being converted to integration events and consumed somewhere downstream. Simply because I don't even know who consume them, and what they do.