Event Sourcing • Martin Fowler • YOW! 2016

This presentation was recorded at YOW! 2016. #GOTOcon #YOW
yowcon.com
Martin Fowler - Author, Speaker, Consultant & General Loud-mouth on Software Development
ABSTRACT
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. [...]
RECOMMENDED BOOKS
Martin Fowler & Pramod Sadalage • NoSQL Distilled • amzn.to/3ChIpu7
Martin Fowler • Patterns of Enterprise Application Architecture • amzn.to/3lp4sIq
Martin Fowler • Domain-Specific Languages • amzn.to/3nzOIFk
Martin Fowler • UML Distilled • amzn.to/3kahjyA
Martin Fowler • Analysis Patterns • amzn.to/3Emabar
GOTOcon
www.linkedin.com/company/goto-
GOTOConferences
#EventSourcing #CQRS #SoftwareArchitecture #SoftwareDevelopment #Thoughtworks #SoftwareEngineering #Programming #MartinFowler #YOWcon
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
Sign up for updates and specials at gotopia.tech/newsletter
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
kzbin.info

[@OkyCapriatto]

First part of the presentation: oh well, it looks so useful. Last part of the presentation: oh well, it gets a mess.

[@moestietabarnak]

The first thing that pop in my mind at the beginning ... didn't get addressed in the talk. If you can roll back anywhere in the event log ... you SHOULD keep the program code in sync ! If I change something last week to process some event, that event would have been processed differently a month ago ! But then, maybe you want to reprocess that event with the new code..who know?

[@dmytro.pyvovarenko]

that is a trick, he did not mention this, but ideally events or sources of trusted data should be immutable, you do not want easily change something in some event and up an app without any consequences.

[@pierre-jeanmartin5621]

Isn’t it addressed when he mention Event Schema? If you replay an old version of event with newer code you might get odd result if you’re not careful

[@Satook]

They do, but as the event sinks converge/time passes, the old logs are purged. They don’t use the log as the ongoing, permanent source of truth. So you don’t get rewind and you can’t rebuild from event 0 and so on.

[@EricLouisYoung]

I am hooked on event sourcing. I just spent 3 years building a very large system based on ddd + cqrs + event sourcing and honestly I feel like a god. I could never have wrangled all that complexity without such thinking. And what's most amazing is the fact that it's all language/platform agnostic. There's no magic. I could recreate my entire system in any language with zero difficulty. Although, despite the agnosticism, I'm excited about how well this thinking maps to elixir/beam. Honestly, if you're not doing ddd, cqrs, event sourcing and elixir, you are behind in the evolution of our field.

[@JamesSmith-cm7sg]

That's not true at all. DDD, event sourcing and CQRS are just tools in the toolbox. You only use them where it makes sense. The same applies to languages. Elixir is immature compared to other languages and not great for CPU bound processes.

[@alvaromoe]

Don't you think that it's at least contradictory to list language agnosticism as a benefit and immediately throw that out the window by stating that there's only one language worth using?

[@sosoga1977]

What's so particular about Elixir? You just said CRQS/ES is programming language agnostic.

[@none_the_less]

@@sosoga1977Some languages are better suited for certain problems. Erlang and Elixir solve problems within the Telecommunications world quite nicely.

[@sosoga1977]

@@none_the_less Yes, but you're referring to Actor Model right now. The same can be said about Akka. Recent innovations and development in Akka is really nice.

[@mlntdrv]

Well to be fair, git doesn't exactly do ES, it rather does a combination of ES + state. Meaning, each commit contains the whole state. Does it reuse the unchanged files between adjacent commits - most probably, but still - the current state is taken by going to the latest commit, instead of replaying the whole event history.

[@square-pixel]

I thought the same thing having read a bit how git works under the hood; however, I suppose one could argue that git still embodies the spirit of an event sourced system since every change is still precisely captured giving the ability to: serialize every commit into a sequence of patch files that git can be used to rebuild the entire repo; rewind and fast-forward every change; replay the changes from one branch on to another (rebasing); merge smarter (with fewer conflicts) because git can walk the changes on several branches using various algorithms to most effectively put them all together. But yes, the internal representation is not a sequence of diffs, but snapshots of pointers to trees and blobs in a common store.

[@monishbiswas1966]

He missed out that most RDBMSs use a log internally as the source of truth, which aids with replication and resilience.

[@bwfrieds]

amen!

[@thebluecasket]

I found the description of git at the start s bit misleading for people less familiar with git. It's a common misconception that a git commit records changes/events. Every git commit is in fact, in a very real way, a complete snapshot of state of all the files at that point in time (with fancy tricks for compression). Nothing needs to be replayed to reconstruct that state, the latest commit has all the information you need.

[@monishbiswas1966]

Conceptually yes, although I thought internally git could store commits as diffs from the previous one?

[@thebluecasket]

@@monishbiswas1966 I don't think this is the case. It's a fairly common misconception. I used to believe it worked this way because the information that git presents to the user is so often in the form of diffs. But internally git stores a series of complete snapshots of the files in the git directory. Every commit is a complete record of file states, and every time it needs a diff between commits, which it needs very often, it constructs the diff on the fly. Of course, there is some smart trickery needed to make this effective in terms of time and space. I recommend the Pro Git book for more details, it's a good read.