new | show | ask | jobs Github

mexicocitinluez 2 hours ago

> or a third team starts depending on your event stream as an integration API.

> vents stop being an internal persistence detail and become a public contract.

You can't blame event sourcing for people not doing it correctly, though.

The events aren't a public contract and shouldn't be treated as such. Treating them that way will result in issues.

> Used as a generic CRUD replacement it’s a complexity bomb with a 12-18 month fuse.

This is true, but all you're really saying it "Use the right tool for the right job".

▲

simonw an hour ago | parent | next [-]

> You can't blame event sourcing for people not doing it correctly, though.

You really can. If there's a technology or approach which the majority of people apply incorrectly that's a problem with that technology or approach.

▲

anthonylevine an hour ago | parent [-]

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 29 minutes ago | parent [-]

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 6 minutes ago \| parent [-]
		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.

▲

zknill 2 hours ago | parent | prev [-]

> You can't blame event sourcing for people not doing it correctly, though.

Perhaps not, but you can criticise articles like this that suggest that CQRS will solve many problems for you, without touching on _any_ of its difficulties or downsides, or the mistakes that many people end up making when implementing these systems.

	▲	anthonylevine an hour ago \| parent [-]
		CQRS is simply splitting your read and write models. That's it. It's not complicated or complex.