GraphQL-enabled event sourcing engine

That talk (which is in written form at http://martin.kleppmann.com/2015/03/04/turning-the-database-... for those who can't watch video) is one of the best I've seen on the subject, and it can really change your way of thinking. Our company has embraced event sourcing wholeheartedly, and it's been gamechanging for us.

One of the key benefits of always being able to re-derive the queryable form of your models from the raw event data, and one that doesn't always come across in tutorials like the OP, is that you aren't just restricted to events that map nicely to "change this specific property in my domain model" or "add a new specific object with these properties." For instance, say you're ingesting emails in a CRM, and you want to say something like "detect the company address from the email signatures, but always make sure that any manually-inputted address overrides that." But then you later change the address-detection algorithm, but want to maintain the manual-override invariant. If that code had been run at email ingestion time in a non-event-sourced paradigm, you'd need to have three-way conflict resolution between old-extraction-algorithm, new-extraction-algorithm, and manual inputs. But with event sourcing, you update the setOfAllEvents -> domainObject function and just push the code, and your data migrates gradually and naturally. And the sky is the limit with how you can combine different types of events.

Everyone loves to talk about source control and continuous integration, and we'd never dream of making the build from code version Y dependent on the build from code version X. But in data management, it's far too easy to use a non-event-sourced approach, and then you introduce those dependencies. And it doesn't have to be that way at all.

Also links the video you linked:

https://github.com/milinda/kappa-architecture.com

http://milinda.pathirage.org/kappa-architecture.com/