The Reactive Monolith – How to Move from CRUD to Event Sourcing • Hacker News Board

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#21

Post by wrwatson » Thu, Sep 30, 2021, 4:09 AM UTC

nuclearnice1 wrote: post #6

0xFACEFEED wrote: post #4

I feel bad for anyone who got sucked into event sourcing for general purpose applications. Like... I'm burning a candle for you right now. The event stream stuff makes sense in some specialized use cases (LMAX?) but for general purpose stuff? Oof, no. EDIT: Also, don't hate me folks, but any article that references Fowler should be looked at with just a little bit of suspicion. Not hating the guy but he's blown quite…

What makes event sourcing poor for general purpose stuff?

The first rule of data modelling is that you should model only what you care about. A good model allows you to store and retrieve what you need to meet your requirements.

Maybe you care about all the events that have ever happened on your incredible journey to reach a list of the customers you have today.

Or maybe it would be sufficient to have been mutating a customers table all along. If that is sufficient, then it would be faster and more straightforward to have done so.

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#22

Post by square_usual » Thu, Sep 30, 2021, 4:10 AM UTC

88913527 wrote: post #8

Spartan-S63 wrote: post #7

Earlier quoted context omitted.

Not OP, but the number of variants in the events makes the cardinality of the state of the system extremely large. Probably too large to be able to reason about fully. It makes weird bugs in the event schema likely impossible to debug should they occur.

This is exactly why 2-way data binding fell out of favor in modern UI development. Describing the problem as "the cardinality of the state of the system extremely large" is a succinct way of putting it. The non-linear increase in possible state quickly makes testing an uphill battle. And it's over when you can't have a comprehensive testing strategy, forget about it.

2-way bindings are still alive and well in the big "next gen" web frameworks, Vue and Svelte.

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#23

Post by KingOfCoders » Thu, Sep 30, 2021, 4:18 AM UTC

As a proponent of Radical Simplicity, I'm always sceptical about event sourcing.

There are some benefits (I found it useful to replay events for example), but where I have seen it at work it makes things much more complex, the understanding of the system and the development of new features takes much longer.

This already starts with a command framework instead of method calls.

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#24

Post by [deleted] » Thu, Sep 30, 2021, 4:43 AM UTC

0xFACEFEED wrote: post #4

I feel bad for anyone who got sucked into event sourcing for general purpose applications. Like... I'm burning a candle for you right now. The event stream stuff makes sense in some specialized use cases (LMAX?) but for general purpose stuff? Oof, no. EDIT: Also, don't hate me folks, but any article that references Fowler should be looked at with just a little bit of suspicion. Not hating the guy but he's blown quite…

[deleted]

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#25

Post by arpa » Thu, Sep 30, 2021, 4:43 AM UTC

The loop will close as we once again will realise that even though domain is king of software, it is too different a beast from what the enlightened among us (not me) call "Infrastructure", the serf that actually grows the crop. Now of course, you can make the serf bend over backwards to serve the king, and use forks to work the land, because that's how kings roll; but is it really the best way to work the land?

If you want proper engineering, you should do proper engineering, instead of being a business analyst documenting the domain in code. But that is, like, only my opinion, man.

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#26

Post by holoduke » Thu, Sep 30, 2021, 4:45 AM UTC

nuclearnice1 wrote: post #6

0xFACEFEED wrote: post #4

I feel bad for anyone who got sucked into event sourcing for general purpose applications. Like... I'm burning a candle for you right now. The event stream stuff makes sense in some specialized use cases (LMAX?) but for general purpose stuff? Oof, no. EDIT: Also, don't hate me folks, but any article that references Fowler should be looked at with just a little bit of suspicion. Not hating the guy but he's blown quite…

What makes event sourcing poor for general purpose stuff?

Extra layer of complexity. More development time. More tech dependencies. Don't use it when not needed.

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#27

Post by mbesto » Thu, Sep 30, 2021, 4:49 AM UTC

I've done a few Tech DDs on companies who have very CRUD-like operations and oddly chose to CQRS. Mind you, these are software companies doing about $3~$10M in revenue after 10 or so years (i.e. not rapid growth, but still valuable).

Honestly, my big question is...why? I can find thousands (millions?) of CRUD and MVC developers in pretty much any major language, but how many developers can I find to write CQRS based code?

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#28

Post by copperx » Thu, Sep 30, 2021, 4:50 AM UTC

0xFACEFEED wrote: post #4

I feel bad for anyone who got sucked into event sourcing for general purpose applications. Like... I'm burning a candle for you right now. The event stream stuff makes sense in some specialized use cases (LMAX?) but for general purpose stuff? Oof, no. EDIT: Also, don't hate me folks, but any article that references Fowler should be looked at with just a little bit of suspicion. Not hating the guy but he's blown quite…

> any article that references Fowler should be looked at with just a little bit of suspicion. Not hating the guy but he's blown quite a bit of hot air in his time.

I've just started reading some Fowler stuff. What hot air are you referring to? I would like to keep that in mind.

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#29

Post by holoduke » Thu, Sep 30, 2021, 4:51 AM UTC

I would like to see answers to the question: why move from Crud to event sourcing. Because I have seen at least 5 moderate projects trying to integrate ES. They all failed in the sense that either people didn't understand the code anymore, huge integration times, performance issues and even complete project cancellation because of all people walking away

Re: The Reactive Monolith – How to Move from CRUD to Event Sourcing

#30

Post by ff2323t223t » Thu, Sep 30, 2021, 4:57 AM UTC

I would recommend to rename "Event Sourcing" to "Evil Sourcing". You guy don't even know how many companies went bankrupt just because they tried to introduce this evil technology that makes your app 100x more complex.