CODEWITHSUNDEEP
event-sourcing
Archange
Archange

Reputation: 519

EventSourcing fix business logic bugs

I'm making some study of eventsourcing before applying it (or not).

Quick question : When using EventSourcing pattern we can imagine this scenario to handle an event :

We can replay all the events and reconstruct the business object state.

How to handle business logic bugs (business logic algorithm v1 contains a nasty bugs).

I read we can fix the bug and replay the events and then we got the business model in a valid state once again.

But what happens if when fixing the business rule when applying event#1 would have caused the 'futurs' commands to fails ? In other words, the event#2, event#3, event#n was dependend of the state of the domain model after applying event#0. How can we fix the cascading events failure ?

I don't have a specific usecase : but we can imagine an account where balance is currently positive. Applying Event#0 increment the balance but this was a bug, the developer wanted to reduce the balance. Event#1 is a purchase that was valid because of the positive balance at this time.

The developer fixes the bug and replay the events. Event#0 decrease the balance which becomes negative. Event#1 is replayed : what happens ?

Do we need to handle this case with 'compensation' ? how ?

thanks in advance for your comments, external ressources that can be of any help (articles, blogs).

bye

Upvotes: 1

Views: 718

Answers (1)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57259

Minor correction

When using EventSourcing pattern we can imagine this scenario to handle an event

  • command sent
  • command handler receive the previous command, validate it then
  • business model verifies that the command can be satisfied without violating the business invariant, and calculates the ensuing events
  • command handler persist this events and publish them

The command handler (specifically, the anti-corruption layer) is responsible for making sure that the command is well formed. The business model decides if the command is permitted by the business.

The good news: the events are just state changes; all of the rule validation is already done. When you fix the bug in the domain object so that it produces the correct events in response to the command, you aren't changing the way the event is applied.

And you certainly aren't changing the history -- if the ATM gave away $20 that it wasn't supposed to, you can't get the money back by editing the record.

What that means is that deploying the bug fix keeps the problem from getting worse; but it doesn't do anything for the event histories that are incorrect.

Compensating events are the right answer here. Ever have a grocery clerk double scan an item, and have to back one of them out? If you look closely, you'll see all three items

  • +1 candy bar
  • +1 candy bar
  • -1 candy bar

That's the idiom of the compensating event being appended to end of the stream.

So if the error showed first appeared in event #0, and then [event #1 .. event #99] have been played on top of that, the remedy for the error is to publish a compensating event #100.

Notice that this is exactly what book keepers would do. You put the wrong sign on the entry on line #1, add a bunch more entries, realize your mistake, and add a new entry that compensates for the earlier mistake.

More good news: in mature business processes, there are already mitigation procedures in place to handle various contingencies. So you can grab a meeting with your domain experts, and doodle on the whiteboard explaining the problem, and your experts should be able to show you the right way to compensate for it. Everything after that is feature management (does the mitigation need to be automated? Does the system need to do the mitigation automatically, or can it let human experts tell it what mitigation to apply, etc. etc.)

Upvotes: 6

Related Questions