Mistakes we made adopting event sourcing and how we recovered

Re:Mistakes we made adopting event sourcing and how we recov... by codebeaker on Tuesday July 02, 2019 @02:59AM (#20332819)

> Sorry to be so negative about this topic but I've worked on several of these projects at a decent scale and it's been the biggest disaster of my professional life. The idea may be viable but tooling is so bad that you're almost surely making a huge mistake implementing these patterns in production code.

Quite, which is why I'm both writing a book, and developing tooling to help with this problem. ES/CQRS is a nice pattern that you can explain to someone on the back of an envelope in 5 minutes, but the devil really is in the details.

[ Parent | on HN ]

Re:Mistakes we made adopting event sourcing and how we recov... by nullwasamistake on Wednesday July 03, 2019 @02:24AM (#20342080)

I agree it's a nice pattern. What you really need though is a "database in code". A library that handles all the projections, event stream, and especially replays and upgrading event versions automatically.

I'm hopeful that one day it will be a common and useful pattern but it desperately needs language integration to help with the details. That's why right now I can just say stay the hell away. Looking forward to advances in the space to make it viable in production

[ Parent | on HN ]

Re:Mistakes we made adopting event sourcing and how we recov... by pyrale on Wednesday July 03, 2019 @03:36AM (#20342379)

It seems like you have problems with the language here. Using pg and a language with ADTs, we have no trouble doing everything ourselves.

[ Parent | on HN ]

Re:Mistakes we made adopting event sourcing and how we recov... by equasar on Tuesday July 02, 2019 @04:03AM (#20333122)

Any preview?

[ Parent | on HN ]