[anthonylevine]

No you can't.

You can blame the endless amount of people that jump in these threads with hot takes about technologies they neither understand or have experience with.

How many event sourced systems have you built? If the answer is 0, I'd have a real hard time understanding how you can even make that judgement.

In fact, half of this thread can't even be bothered to look up the definition of CQRS, so the idea that "Storing facts" is to blame for people abusing it is a bit of a stretch, no?

[simonw]

I've not run an event sourcing system in production myself.

This thread appears to have stories from several people who have though, and have credible criticisms:

https://news.ycombinator.com/item?id=45962656#46014546

https://news.ycombinator.com/item?id=45962656#46013851

https://news.ycombinator.com/item?id=45962656#46014050

What's your response to the common theme that event sourcing systems are difficult to maintain in the face of constantly changing product requirements?

[anthonylevine]

I think having constantly changing product requirements would certainly make it difficult, but that makes all development more difficult.

In fact, I think most complexity I create or encounter is in response to trying to future-proof stuff I know will change.

I'm in healthcare. And it changes CONSTANTLY. Like, enormous, foundation changes yearly. But that doesn't mean there aren't portions of that domain that could benefit from event sourcing (and have long, established patterns like ADT feeds for instance).

One warning I often see supplied with event sourcing is not to base your entire system around it. Just the parts that make sense.

Blood pressure spiking, high temperature, weight loss, etc are all established concepts that could benefit from event sourcing. But that doesn't mean healthcare doesn't change or that it is a static field per se. There are certainly parts of my system that are CRUD and introducing event-sourcing would just make things complicated (like maintaining a list of pharmacies).

I think what's happening is that a lot of hype around the tech + people not understanding when to apply it is responsbile for what we're seeing, not that it's a bad pattern.

[simonw]

Thanks, this is a great comment. Love the observation that event sourcing only makes sense for parts of a system.

Could be that some of the bad experiences we hear about are from people applying it to fields like content management (I've been tempted to try it there) or applying it to whole systems rather than individual parts.

[anthonylevine]

No problem and likewise. Conversations like this are great because they constantly make me re-evaluate what I think/say and often times I'll come out of it with a different opinion.

> Could be that some of the bad experiences we hear about are from people applying it to fields like content management (I've been tempted to try it there) or applying it to whole systems rather than individual parts

Amen. And I think what most people miss is that it's really hard to do for domains you're just learning about. And I don't blame people for feeling frustrated.

[mrkeen]

> What's your response to the common theme that event sourcing systems are difficult to maintain in the face of constantly changing product requirements?

I've been on an ES team at my current job, and switched to a CRUD monolith.

And to be blunt, the CRUD guys just don't know that they're wrong - not their opinion about ES - but that the data itself is wrong. Their system has evaluated 2+2=5, and with no way to see the 2s, what conclusion can they draw other than 5 is the correct state?

I have been slipping some ES back into the codebase. It's inefficient because it's stringy data in an SQL database, but I look forward to support tickets because i don't have to "debug". I just read the events, and have the evidence to back up that the customer is wrong and the system is right.

[anthonylevine]

> It's inefficient because it's stringy data in an SQL database, but I look forward to support tickets because i don't have to "debug". I just read the events, and have the evidence to back up that the customer is wrong and the system is right.

I think one of the draws of ES is that it feels like the ultimate way to store stuff. The ability to pinpoint exact actions in time and then use that data to create different projections is super cool to me.