News for hackers. Stuff that matters.
Re:Event Sourcing (2017) by inopinatus on Thursday January 02, 2020 @03:03AM (#21933700)
Some of worlds most useful and powerful data structures are the projection of an event log. The tables of a RDBMS, the balanced writes of a SSD, and even the classic: double-entry book-keeping.

Even the data stream of a TCP connection is a projection of events, which is why (and how) we can reconstruct them by replaying captured segments.

So just because there are some lousy executions of a general architecture, doesn’t mean we should recoil from the basic idea.

My takeaway is that successful event-sourced structures are crafted for the domain they represent. I’ve developed a couple for my own work, for very specific aspects of an application, and they work well in context.

If your experience has been that a general-purpose ES framework leads to shitty, hard-to-maintain apps, I’d say that’s evidence for the corollary.

Re:Event Sourcing (2017) by nvarsj on Thursday January 02, 2020 @08:58AM (#21935362)
Just because a tool is powerful doesn’t mean it’s appropriate. There’s a reason most people should just use a DB and not a raw event log. The issue I have with ES proponents is they seem to all pretend there is no additional complexity that comes with it. I think ES is useful but not always and requires weighing the costs and benefits, and we need to be honest about it.
Re:Event Sourcing (2017) by legulere on Sunday January 05, 2020 @12:09AM (#21959764)
You could say the same about e.g. lock free algorithms. If you work on them you are usually just playing with some cool technology instead of solving the business requirements.