Greg Young — A Decade of DDD, CQRS, Event Sourcing
Why Hacker News recommends it
HN commenters cite it in event sourcing threads for Young's views on when to use it, including advice against cross-application event sourcing.
What it is
Greg Young, who coined CQRS, looks back on a decade of domain-driven design, CQRS and event sourcing at DDD Europe 2016. He discusses where event sourcing applies and how simple its core can be.
Recommended by 1 HN commenters across 1 different months, 2016 to 2026.
What Hacker News said
Recommends karmajunkie · 2016-10 · on “Why Are People into Event Sourcing?”
See the presentation by Greg Young I linked to in another comment. One thing he talks about towards the end is the application for occasionally connected clients, which is one I'm looking to tackle myself in the next several months. ES may very well serve your needs, but I'd take a step back from the CRUD model and really think about the domain model. Something I do a lot of times when I'm looking at moving away from CRUD in an app is creating a bunch of domain-based command classes, which take over the persistence job, and move the app layer towards talking only to those commands. Still CRUD under the covers, but now there's an abstraction layer above it, and as you get a better delineation
Cites karmajunkie · 2016-10 · on “Why Are People into Event Sourcing?”
> Moving everything to be an event completely throws this out the window. This is either an antipattern or unrelated to event-sourcing depending on how you read it. "Event sourced" means that state within a transaction boundary is built ONLY through events which are regarded as persistent and immutable; evented is the term I'll use for state which is built when events happen, when those events may or may not be recorded, and may happen before or after state is changed and are independent of the state change. If you meant "evented" then I would say that there are lots of message-based systems that aren't failing hard, and a lot that are, which says to me that there are patterns some of those
Cites fetbaffe · 2019-02 · on “Event Sourcing is Hard”
It is worrying that a central figure to Event Sourcing & CQRS like Greg Young reduces the "framework" to a function, a pattern match & a left fold. Linked in the article [this video]
Cites austinthecoder · 2026-01 · on “My Workplace Disallows APIs”
I'm familiar with event sourcing. From what I understand, it's useful within bounded context/domain/app. I.e., from the outside you'd never know an app is event sourced (it's an implementation detail). Event sourcing is fantastic. My concern is with cross-app event sourcing: N copies of data/events across N apps. Greg Young strongly advises against this in this video: [this video] I have no idea how this came about. I think it's mainly driven by one engineer. I don't think it's related to any issues related to APIs in the past, in fact I'm not sure they've ever had APIs. There are numerous issues that have come up due to the nature of this system. These are mostly internal apps not used by that m