Martin Fowler shares his views on event sourcing. Martin is Chief Scientist at Thoughtworks, Opinion Leader and Author of many Development books. Martin concentrates on designing enterprise software - looking at what makes a good design and what practices are needed to come up with good design. He's been a pioneer of various topics around object-oriented technology and agile methods, and written several books including "Refactoring", "UML Distilled", "Patterns of Enterprise Application Architecture", and "NoSQL Distilled". Martins also writes at martinfowler.com. For more on YOW! Conference, visit http://www.yowconference.com.au

Comments

1. my right ear enjoyed this video
2. I would have thought that not just programmers, but every single person in that building had used an Event Sourced system. I mean, everyone has a bank account, right?
3. Looking forward to his book on event-sourcing
4. @martinfowlercom Any hints regarding "identifiers"? Could you list any techniques or tricks that I can google for to study the problem more deeply? Any good authors that have already covered the problem?
   
   You have only mentioned them on the video at https://youtu.be/aweV9FLTZkU?t=1568 without any other details. I have tried to search your page but failed to find anything about this particular problem. This is very interesting problem in case you are looking for a new candidate for a topic of your next lecture or blog post. Thank you very much in advance for any help, any directions! :)
   
   I have posted a question on stack too http://stackoverflow.com/questions/41417777/how-to-generate-identities-when-source-of-truth-is-apache-kafka
5. @Martin_Fowler, I totally enjoy watching your talks and refer my peers to your bliki, but honestly that dog will not hunt!
   
   I'm not comfortable at all with ES or CQRS. First of all, what successful archetypes exist that we can model our applications on? You are totally keyed into the landscape, our top men have your ear, yet you have no example to cite!
   
   Getting more nitpicky though, how do you handle change to events, data, semantics and keep your history? Do you expect my event processing code just accrete for all the historical meanings/versions of my events, or do I have to migrate my events in the log to the latest versions? This is a huge problem! Also, I know that asynchrony is off the table but all of the (failed) projects I've seen that have tried ES or CQRS ultimately the architect astronaut wants to do the magical multiuser system where events flow in to the central server, are synchronized and updates flow back out to all the clients. Sounds all very magical and fabulous, but how DO you actually write your UI's such that you're not INCREDIBLY chatty between the server and client since every little interaction with the model has to become event-ified and then processed centrally? This goes beyond frameworks, we need a whole new programming language/protocol/browser to implement such a system.
   
   Quite honestly, the handwaving I've seen architects do over ES and CQRS is outrageous. Let's not be abstract here, millions of bucks are being thrown into the burning dumpster fire called CQRS-ES right now! Raw text works great as a data model because a) its schema, raw character streams, don't ever change and b) you can reason semi reliably when you want to diff and merge. Give me ANY semantic meaning to your data, like when you have a schema that has more than zero properties in it, and all our hopes and dreams of ES become clear as mud. If I ever have the perfect up-front design for a system that you KNOW will never need to change in the future, then ES is the architecture for me - which is to say never, Martin. Never ever ever.
   
   Finally, anywhere I find there's an architecture that requires me to do lots of data reshaping is an automatic fail - that's where all my lousiest bugs live. I don't think ES is that guilty of excess reshaping by your description, but CQRS CERTAINLY is.
6. Um, removing events? It's better to add compensating event. Event Sourcing promotes book-of-record approach, so nothing should be lost.
7. The event should be called ""address changed" not "change address". "change address" is a command. Events are things that already have happened, not what is happening now or what will happen in the future. Therefore, "address changed" is the proper name for the event.
8. wow. No mention of Greg Young. How does this guy sleep at night?