Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Are People into Event Sourcing?

adaptechsolutions.net

Post reply on HN
Print view View original

61–70 of 90 posts

Re: Why Are People into Event Sourcing?

#61

Post by biot »

taeric wrote: post #34
biot wrote: post #26

Earlier quoted context omitted.

Combine this with the actor model (using Akka or similar) gives you guaranteed "one message at a time" processing and you don't have to deal with locks.

I question any amount of guarantees around "one message" anything. There might be this guarantee per actor, but you have no such guarantee per system. And, assuming a real system, this will be a problem. So, you get to pick, "at most once" or "at least once." And then you need to build your system to act accordingly.

Correct. Message delivery strategy is separate from message processing once delivered. If you choose at-least-once delivery, you'll need to handle possible duplicates regardless of whether or not you can process a duplicate message in a lock-free manner.

Re: Why Are People into Event Sourcing?

#62

Post by taeric »

karmajunkie wrote: post #45
taeric wrote: post #3

As someone that has fallen for the "event sourcing" promise before, the article does a decent job explaining the promise. Not sure if it will be the next article, but the actual task of delivering on this work is where things break. Hard. The vast majority of the things you will ever program are pretty much guaranteed from one statement to the next. Hard boundaries, where things can fail, are often decently understoo…

> Moving everything to be an event completely throws this out the window. This is either an antipattern or unrelated to event-sourcing depending on how you read it. "Event sourced" means that state within a transaction boundary is built ONLY through events which are regarded as persistent and immutable; evented is the term I'll use for state which is built when events happen, when those events may or may not be recor…

Unfortunately, you lost me in that first paragraph. I think you left off a set of quotes on the first use of "evented."

Regardless, I meant the idea of moving everything to a communication of events between subsystems. To be fair, the sibling read me correctly and stated that if you just ignore the distributed nature of events, then things aren't that hard.

However, it is easy to follow the lure of "I'll go ahead and make this work for the distributed case" from the beginning. This is for two reasons. First, why not? :) Second, it is seen as something that would be very hard to add in later.

So, I can't disagree that it is an anti-pattern or unrelated. However... I would be surprised if the next version of this article didn't go over the distributed nature. Indeed, it already covers how this more correctly mirrors the distributed nature of the organization.

Re: Why Are People into Event Sourcing?

#63

Post by taeric »

rreppel wrote: post #41
taeric wrote: post #31

Earlier quoted context omitted.

This seems solid advice. I guess my main questions are: * If you are in-memory and in-process, why bother with the events in the first place? (Simpler put, why not go with the simpler process based solutions?) * If you are not testing distributed, how do you know you will be able to distribute? In particular, there is a very large chance that you will have the same difficulty in replacing an in-memory/process solutio…

I don't really do eventsourcing for technical reasons. To me it's about creating an environment for project delivery where teams can succeed because they own more of their stack, from an org chart & organizational perspective. As far as code is concerned, I see that as coming down to managing coupling & cohesion in such a way that the various pieces can be designed, built, supported, deployed and enhanced by the same…

I think the problem is best seen by considering the statement "You don't care who subscribes to your events." This is great when you are literally doing something only on one end of the event creation barrier. This makes sense when creating something takes a lot of effort.

However, for many many shops, this is an abstraction they will never get to. They care intimately about who will subscribe to the events they publish, because they are planning on doing something as the primary subscriber.

Re: Why Are People into Event Sourcing?

#64

Post by Terr_ »

taeric wrote: post #3

As someone that has fallen for the "event sourcing" promise before, the article does a decent job explaining the promise. Not sure if it will be the next article, but the actual task of delivering on this work is where things break. Hard. The vast majority of the things you will ever program are pretty much guaranteed from one statement to the next. Hard boundaries, where things can fail, are often decently understoo…

I'd suggest people start with CQRS+Events before going to CQRS+EventSourcing.

In the first case, you keep however you were loading/saving your entities, and modify them to emit events as they mutate. Then you can play with sending those events to external systems, or using them to drive read-models for queries, etc.

In the second case, you go further, and "dogfood" those events so that they are the authoritative record of what the entity is at a given point in time.

Re: Why Are People into Event Sourcing?

#65

Post by Terr_ »

dragonwriter wrote: post #54
karmajunkie wrote: post #49

Earlier quoted context omitted.

> Imagine tooling that allowed an event stream to be used to create state for testing modules, crudlike helpers to allow crud-familiar developers to think that way at first, and workflows based on snapshots, rewind, etc. i know where you're going with this, and i honestly believe its a terrible idea (not to be discouraging or rude—just experienced.) if your event streams contain mostly CRUD (possibly ANY) then you're…

> if your event streams contain mostly CRUD (possibly ANY) then you're most likely applying it incorrectly. Its not just a version history of your data. The event type itself is data, which provides context and semantics over and above the notion of writes and deletes. Right. A good way to think about this is that as with rows in an RDBMS, events in an ES system are facts, and just as tables in an RDBMS define a cate…

Right^2: Good events are facts that occur at a higher level of abstraction, trying to capture more of the "why" behind what goes on. It's not about describing the effect on data, but the business-decision itself. (Which, when reapplied to a set of rules, will do the actual data-change.)

Re: Why Are People into Event Sourcing?

#66

Post by [deleted] »

EdSharkey wrote: post #59

Here's the term I wish was unfashionable with the kids: reshaping. Did you spot all those command-to-query-to-event-to-log-to-storage data type conversions in those pretty diagrams? That's a whole bunch of needless reshaping of data as it flows through the system. For each one of those data transformations to be successful, there has to be accurate communications between people and bug free code written in the data c…

[deleted]

Re: Why Are People into Event Sourcing?

#67

Post by Terr_ »

porker wrote: post #52
karmajunkie wrote: post #49

Earlier quoted context omitted.

> Imagine tooling that allowed an event stream to be used to create state for testing modules, crudlike helpers to allow crud-familiar developers to think that way at first, and workflows based on snapshots, rewind, etc. i know where you're going with this, and i honestly believe its a terrible idea (not to be discouraging or rude—just experienced.) if your event streams contain mostly CRUD (possibly ANY) then you're…

> if your event streams contain mostly CRUD (possibly ANY) then you're most likely applying it incorrectly. Its not just a version history of your data. Thanks for that. I'd made that mistake: I have a system which now needs to become distributed (a copy of it goes offline for a couple of weeks, and has to merge back into the main datastore) and keep a history of changes. It's currently CRUD backed by MySQL, and I'd…

There's nothing wrong with having a system that uses immutable events to represent data, IMO it's mainly a terminology issue: "Event Sourcing" often implies you're recording rather abstract, high-level events that try to capture something about a particular domain. As opposed to, say, a straight diff between two data-dumps.

Re: Why Are People into Event Sourcing?

#68

Post by karmajunkie »

grandalf wrote: post #57
karmajunkie wrote: post #49

Earlier quoted context omitted.

> Imagine tooling that allowed an event stream to be used to create state for testing modules, crudlike helpers to allow crud-familiar developers to think that way at first, and workflows based on snapshots, rewind, etc. i know where you're going with this, and i honestly believe its a terrible idea (not to be discouraging or rude—just experienced.) if your event streams contain mostly CRUD (possibly ANY) then you're…

I was thinking of making CRUD a specific event type that had meaning only in the context of changes to an instance of some schema. Of course, the most interesting events will not be CRUD oriented, but does this mean it's a mistake to include them at all, particularly if interacting with other systems that do use a CRUD metaphor for interaction and state must be synchronized?

> particularly if interacting with other systems that do use a CRUD metaphor for interaction and state must be synchronized?

This is also an antipattern, btw—events between bounded contexts should be somewhat limited, and well-defined behaviors when doing so. What you're doing with a scheme like that, sharing CRUD events between external services or systems, breaks all kinds of conceptual and logical encapsulation (in addition to the aforementioned CRUD thing.)

Re: Why Are People into Event Sourcing?

#69

Post by rreppel »

EdSharkey wrote: post #59

Here's the term I wish was unfashionable with the kids: reshaping. Did you spot all those command-to-query-to-event-to-log-to-storage data type conversions in those pretty diagrams? That's a whole bunch of needless reshaping of data as it flows through the system. For each one of those data transformations to be successful, there has to be accurate communications between people and bug free code written in the data c…

Open sourced ones? The largest example I'm aware of is https://github.com/MicrosoftArchive/cqrs-journey. There's a pretty extensive write-up of their experiences too. https://msdn.microsoft.com/en-us/library/jj554200.aspx

Re: Why Are People into Event Sourcing?

#70

Post by haimez »

blowski wrote: post #55
btown wrote: post #4

Event sourcing isn't nearly as common knowledge among new programmers as the CRUD-one-row-per-entity pattern, and it really should be. I liken it to introducing version control for your data; when immutable updates are your canonical source, no matter how much the system behind them changes, or the business requirements change, and no matter how many teams are deriving different things from them in parallel, they can…

The CRUD one-row-per-pattern is common because it's enough for most projects. It works well with ORMs so you can build quickly and securely. And most of the time, performance isn't an issue and having a history of an entity is unnecessary. I'm worried that event sourcing is going to become this year's over-applied design pattern with libraries in every language for every database with blog posts that recommend it be…

Could happen, but I think event sourcing (and CQRS generally) carries enough implementation overhead in the amount of code required that it's less likely to be adopted in situations where it isn't appropriate.

That isn't to say it won't happen, but I think it's more likely that teams would miss an opportunity to leverage it than leverage it inappropriately.

Post reply on HN