Great talk. I'm literally about to build an event sourced banking system. It is so lucky that I found this video. Just wondering how you would deal with those inflight transactions between account closed and account opened especially if these events need some approval processed controlled by human.
Great talk! Keeping streams short could be a huge challenge. I eventually hit the need for snapshots. Imagine you have a User aggregate/stream to manage user personal details, password, etc. And now you add a new magic email link or temporary code generation for authentication which would grow the stream very quickly. What to do then? Even by extracting this to its own stream, it'd still hit the same problem. Rolling out a new stream just to come around these "tech" limitations feel like polluting domain with technical limitations.
Event sourcing newb here, If I want to perform aggregates on my checking account (sum), I have to load *all* the records from the database? Seems extremely inefficient.
All the events for THAT specific stream. That's why it's important to design around those streams..you would have Account-1 stream, Account-2, etc. Each one for a different account. Loading hundreds of events in order to instantiate an aggregate is super quick. Definitely quicker than reading data from different indexed tables in a relational database and joining and filtering results.
I find memes funny in certain contexts, but not that much during presentations. It’s a short talk for professionals on something that should be of interesting and engaging for its own good. What is the point of putting sensational pictures on every other slide?
Thank you for the feedback. Slides, for me, are just illustration for of what I'm saying. I'm trying to keep them engaging, help pass knowledge, and have some fun. Of course, the last part is subjective, so I understand that it may be too much for some people like you, but I hope that's not disturbing. It's not easy to find the right balance, as different people have different needs. I think that just showing diagrams won't be enough engaging, as the content is already dense. I'll think on if I can make the ratio better.
@@event-driven thank you for sharing your knowledge and trying to make engaging presentations. I hope you’ll get enough feedback to decide whether to make any adjustments or not. Respect for being the one in the stage and reading the comments section! ☺️
Amazing talk, and beautifully visualized 👍
Thank you a lot! I'm glad that you noticed the work put into the slides ❤
Thanks to Oskar and DDD Europe for the insightful lecture. There's a useful recommendations.
Thank you Vladyslav, I'm super happy that you liked it! It was important talk for me.
@@event-driven Good luck and thankful audience for every next public talk 🤝🏻
@@vladyslavkarpenko9372 thank you once more ❤
Great video; thanks for this!
Thank you, Valentina! Much appreciated 🙂
Great talk. I'm literally about to build an event sourced banking system. It is so lucky that I found this video. Just wondering how you would deal with those inflight transactions between account closed and account opened especially if these events need some approval processed controlled by human.
How do you know where your "snapshot events" are located?
Great talk!
Keeping streams short could be a huge challenge. I eventually hit the need for snapshots. Imagine you have a User aggregate/stream to manage user personal details, password, etc. And now you add a new magic email link or temporary code generation for authentication which would grow the stream very quickly. What to do then? Even by extracting this to its own stream, it'd still hit the same problem.
Rolling out a new stream just to come around these "tech" limitations feel like polluting domain with technical limitations.
Temporary code generation should be temporary and it is independent from a user aggregate. There are no invariants between user and code generation.
Event sourcing newb here, If I want to perform aggregates on my checking account (sum), I have to load *all* the records from the database? Seems extremely inefficient.
All the events for THAT specific stream. That's why it's important to design around those streams..you would have Account-1 stream, Account-2, etc. Each one for a different account.
Loading hundreds of events in order to instantiate an aggregate is super quick. Definitely quicker than reading data from different indexed tables in a relational database and joining and filtering results.
12:07
Great Job Oskar, great presentation. Although I have to say, in the beginning I was like, what is Ryan Gosling doing giving a talk at DDD??? ;)
haha, thanks! I hope that some people are also telling him, that he looks like me 😅
@@event-driven Most definitely! People are probably seeing him around and yell at him, Hey Oskar! Great talk!
😂😂😂
I find memes funny in certain contexts, but not that much during presentations.
It’s a short talk for professionals on something that should be of interesting and engaging for its own good. What is the point of putting sensational pictures on every other slide?
Nothing wrong with that
I agree it is fine in general, though maybe fewer would be better. Every third slide?
Thank you for the feedback. Slides, for me, are just illustration for of what I'm saying. I'm trying to keep them engaging, help pass knowledge, and have some fun. Of course, the last part is subjective, so I understand that it may be too much for some people like you, but I hope that's not disturbing. It's not easy to find the right balance, as different people have different needs. I think that just showing diagrams won't be enough engaging, as the content is already dense. I'll think on if I can make the ratio better.
@@event-driven thank you for sharing your knowledge and trying to make engaging presentations.
I hope you’ll get enough feedback to decide whether to make any adjustments or not.
Respect for being the one in the stage and reading the comments section! ☺️
@@a0um, thanks; indeed, getting enough feedback can be challenging. Especially constructive criticism that helps to get a better 🙂