So, you've heard about this event sourcing thing and you're eager to try it? Looks great, gives you events history, auditing, read models you can build for given use case and rebuild at any time and so on. It has it's pros indeed (a lot), it also has some cons (well, there is no silver bullet), but there are things that you can only learn and truly understand when you hit the problem and experience it for real. How it all works and how it fits in the real world systems? There are few gems and tricks in all this event sourcing world that I learned over time that I'd like to show you. What to watch for when choosing that architecture, what to avoid and how to do certain things in an event-sourced way for successful long running project. I hope this talk will either save you from making few of the mistakes I did (or was close to doing so) or at least shed some more light on event sourcing in practical aspect.
MICHAŁ OSTRUSZKA
Seasoned software engineer, solution architect of production-running systems across various domains. Working remotely for 10+ years now, experienced in building distributed, event-driven, and event-sourced solutions. 10+ years long track of record writing Scala commercially, with prior solid Java/JVM background and knowledge of other languages and platforms (e.g. node.js). A keen advocate of practical functional programming approach, Domain Driven Design, domain modelling and event-based architectures
