How leveraging events can simplify your app

Event sourcing is no silver bullet. But it is a match made in heaven for some domains. I also don't see much mainstream coverage of event sourcing, CQRS and domain driven design.

Thank you so much for taking the time to watch.

Timestamps

0:00 Problem space
0:40 CRUD implementation
1:12 Issues
1:48 Event sourcing
3:02 CQRS
3:34 Aggregate
4:05 Advantages
4:40 Disadvantages
5:08 Exit

[brunojcm]

Love the git analogy, probably the largest event sourcing system currently deployed and people don't even realise it's using the pattern

[theMonkeyMonkey]

Beautifully clear, concise and informative video. Also that last sentence! 😀 Great work

[JohannOldman]

Being an Akira fan is a real privilege 🙏

[mayy]

Great video!

I think, within one system, async projections are usually not needed.
It should be an exception to project your query models async as they are too painful to work with.

What i usually do is within one transaction:
- Fetch events and rebuild my aggregate
- Apply the command: Raise events and messages that will be sent to other processes.
- Save the events, messages, query projection all at once.

It's still performant for small-medium aggregates.
Async projections would be my last resort for solving performance issues.
Versioning the aggregate and caching it is probably the best value for money :)

I find it rather unfortunate to associate event sourcing with eventually consistent CQRS.

[DomskiPlays]

Great video Tom! One thing I think should have been different is the "event" column shown at 2:30. Storing the data this way will make querying really hard, you need to split the event type and the data associated with it into at least two separate columns.

I suppose you know this but having it this other way in the video may confuse people so I fel the need to point that out.

[_modiX]

The problem with the events table is that it's not atomic, because the event column contains more than one information and highly dependent of the type of event you are dealing with. To solve this problem, you would have the necessity to maintain a different table for each type of event with the relevant columns, i.e. phone number whenever having an event that deals with the phone number. It's annoying to maintain, though.

[Mankepanke]

Git isn't event sourced. Subversion was, and it working out badly is one of the reasons Git was created.
Git stores full copies of the state at each commit, and allows you to find the diff between two versions quickly since it only needs to diff two full states, instead of walking along a path and joining diffs.

In this example, that would've been closer to copying the table on each event and then allowing you to recreate the event stream by diffing each table version and working backwards from that diff, except since git use immutable structures with Copy on Write semantics, the things that are unchanged are reused between versions. I dont think there's a good analogy in RDBMSs, but I'm all ears on that one.

[ivanjermakov]

Title is incorrect. Everything you mentioned in the video still use CRUD.
> CRUD and CQRS are completely different things that aren't mutually exclusive. CQRS only means that your write model is separated from your read model. Therefore, both can scale independently of each other. While CQRS is often associated with DDD & EventSourcing these aren't prerequisites of CQRS - copied from some stackoverflow comment.

[tanko.reactions]

every now and then, an event source must contain the current state, not just a diff to the previous state.
otherwise you would have to process the entirety of the history to build the current state, something unfeasible in an enterprise environment.

if after every 5-10 events / processes, one event is generated, which acts as an anchor point, you would not have to go back further than that, you could use that as the starting point to construct the current state.

is this the way its done in this paradigm?

[StarlightInsights_com]

Very good video.

How do you handle GDPR removal of, say, phone number?

[rawallon]

This video was pretty cool, but the title made me start watching with a very skeptical mindset I wish you would just name what it is about, event sourcing

[toheeboyekola]

Does this mean event source just translates "Log every action"

[forthesky]

Very informative video, enjoyed the video
very small personal feedback Voice clarity and tone are good,

just try to speed up your speech a little bit, 1.25 / 1.5 felt clear
due to the slowness of the speech in the first place

[Lemmy]

This is not an alternative to CRUD but is complementary. It's a good idea for specific cases in which you are interested in saving an "history".

[tk_real]

I like the points you make, but the example you give is (imho) horrible. when using an append-only event-list containing user data you're fundamentally breaking privacy laws. What if I remove my phone number from the service? Yeah sure, it won't be used after a deletion-event was added but registering it, verifying it, using it and deleting it will be stored forever. I guess you could add a pruning algorithm to fix this… 🤔

[ibrahimkoz]

The problem at hand is about how to model your data accurately. It's not about event sourcing or any other gimmicks. Data is front and center. You could use state machines in your application code to make invalid state unrepresentable, designing with a good data modelling of your domain.

[will_]

Not this again! Event sourcing is the WORST legacy part of our platform, it sounds good in theory but it's awful in practice