As an interesting comparison, some people see the Redux/Flux pattern as a front-end parallel to event sourcing.
[0]: https://github.com/reactjs/redux/issues/891#issuecomment-158...
Why Are People into Event Sourcing?
71–80 of 90 posts
Re: Why Are People into Event Sourcing?
#72How strange, just today I've heard the Event Sourcing name and thought I don't know what it is. (Turns out it is this old idea I knew under various different names). And at the same day I hear about Event Sourcing on HN. What's the buzz?
Re: Why Are People into Event Sourcing?
#73Here'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…
Does postgres count?
Re: Why Are People into Event Sourcing?
#74Earlier quoted context omitted.
Yup, agree, this is the problem of having a legacy monolith RDBMS that needs to be rewritten and split apart. It's tempting to throw every new fancy technology at the problem when that is suddenly an option, but it's better to focus on the goal of splitting it apart only. If you have split it out, and it's now simple to convert to ES CQRS, then you are probably in a situation where you don't need to do that, as it wo…
> It's tempting to throw every new fancy technology at the problem when that is suddenly an option, but it's better to focus on the goal of splitting it apart only. Splitting it apart involves: (1) Dividing the data and functionality into a legacy component and a new-implementation component, (2) Making changes to the DB and application code for the legacy component, (3) Implementing the new-implementation component.…
"The hard part [...] is done in the analysis phase..." smells like big design up front that is usually more likely to fail than not, especially so for complex systems.
Re: Why Are People into Event Sourcing?
#75Earlier quoted context omitted.
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.
You must be young and/or an optimist. Crappy managers care more about buzzwords and less about appropriate solutions.
Re: Why Are People into Event Sourcing?
#76Event 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…
> 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.
If by "works well", you mean it works until someone asks for historical data - then IT guy has to say w/ a straight face "we lost it". This is unacceptable considering the value of data and the strategic leverage it can have today.
Considering immutable facts tables are the most stable data model; companies often have to re-invent it (poorly) on top of relational at some point; that storage is often not a problem; and that having clean historical data is crucial for data science; there are increasingly fewer excuses to not adopt a sane data model from day one.
I agree partially w.r.t. to tooling - few implementations aid adopting this pattern, but I believe the value of historical data, over time, overcomes not being able to slap some quick Rail CRUD together and then being stuck at local minima.
Re: Why Are People into Event Sourcing?
#77Earlier quoted context omitted.
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…
> 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. If by "works well", you mean it works until someone asks for historical data - then IT guy has to say w/ a straight face "we lost it". This is unacceptable considering the value of data and the strategic leverage it can have today. Considering immutable facts tables are the mo…
>If by "works well", you mean it works until someone asks for historical data - then IT guy has to say w/ a straight face "we lost it". This is unacceptable
You'd be surprised.
For tons of projects it's totally acceptable, has worked for years, nobody paying to implement them cares about historical data and their leverage. In fact the majority of web apps is like this.
I always find it strange when people use "unacceptable" with wild abandon, like they're generals receiving some demand of unconditional surrender.
Re: Why Are People into Event Sourcing?
#78Earlier quoted context omitted.
> 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. If by "works well", you mean it works until someone asks for historical data - then IT guy has to say w/ a straight face "we lost it". This is unacceptable considering the value of data and the strategic leverage it can have today. Considering immutable facts tables are the mo…
> If by "works well", you mean it works until someone asks for historical data - then IT guy has to say w/ a straight face "we lost it". This is unacceptable You'd be surprised. For tons of projects it's totally acceptable, has worked for years, nobody paying to implement them cares about historical data and their leverage. In fact the majority of web apps is like this. I always find it strange when people use "unacc…
I've probably implemented 300 CRUD projects, and I've never had a single angry person complaining about lack of access to historical data.
* I keep hourly backups of mysqldumps which can be restored in the case of catastrophic mistakes.
* I explain that this kind of data collection would be out of scope, and require significantly more budget.
Just because it's technically possible, it doesn't mean you need to do it. YAGNI.
Re: Why Are People into Event Sourcing?
#79Earlier quoted context omitted.
> 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…
> I think you left off a set of quotes on the first use of "evented."
Indeed, sorry I lost you there.
> Regardless, I meant the idea of moving everything to a communication of events between subsystems.
Unless the persisted events are the primary representation of data, this describes "evented" (or message-based) rather than ES.
> 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
So it seems like what we're actually saying here is "Distributed systems are hard to build reliably"—which wouldn't seem to be a surprising result on HN, and certainly a sentiment I'd agree with.
I've moved to using Elixir and Erlang primarily because processes/actors have such a natural fit for this kind of data that I get really grumpy when I have to work in something else now. There is also a long history of distributed systems within the BEAM ecosystem so there is a legacy of design meant to deal with the inherently unreliable nature of building distributed.
Re: Why Are People into Event Sourcing?
#80Earlier quoted context omitted.
ISTM event sourcing actually avoids many locking problems, since it's essentially "write-only". Of course every event write should be atomic, but that seems easier than making updates atomic?
When a certain set of events occurs (the files arrive etc) I want to kick off one and only one batch processor task. This is accomplished with a transaction and a write lock in an sql database, but when trying to use event sourcing it ends up requiring a 2 step "intent to run" event before running or some out of band synchronization.
This isn't something I would handle with event sourcing. Using ES throughout an application is an antipattern.
For something like this my batch processor is implemented as you're probably used to—files get a CRUD model associated with them, schedule a background job to handle it, let locking get handled there. Once inside the batch processor you can use the same domain services and commands that you'd use from your application layer and commit events on a command basis, or on something like a row in the file (which may generate several commands and dozens of events depending on your model), or on a file level (all or nothing.)
The thing I see people do frequently (and sadly, have done myself on occasion!) that makes their lives harder is trying to shoehorn everything into ES without doing the design work to establish a domain, its boundaries, and what events make sense within it.