When we talk about implementing an event-sourced system, we hear from the experts in the subject that Event Sourcing, in essence, is an easy concept. You don't need a framework, they say. Or do you? When building a production-grade system, I personally always ended up building something that could be used as a set of building blocks. Sometimes, it gets the "framework" in its name. Working at Event Store as a Dev Advocate, I often engage in conversations with our customers, and I observe the same pattern. We also have some decent (and not-so) OSS projects on GitHub. After a while, I decided to consolidate my own experience in the field, and build yet another "Event Sourcing framework" for .NET. During this talk, I want to share my motivation for doing that, as well as my experience building it, and some feedback from people using it in production.
Decoding Paradoxes: Why are many good ideas in Software Delivery counter-intuitive
How does deploying more frequently improve quality? How does slack time in a team improve reliability? Why should we do it more often if it hurts? These are counter-intuitive concepts that don't make sense at first, and you'll be met with a bewildered stare...