HackerTube.dev

Greg Young — A Decade of DDD, CQRS, Event Sourcing

Domain-Driven Design Europe · 190.2K views · 2016-04-11 · 48:04

Open on YouTube ↗

If playback is restricted in your region, try opening the original video. Use Mark watched to add it to your marked videos.

Overview

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.

On Hacker News

HN commenters cite it in event sourcing threads for Young's views on when to use it, including advice against cross-application event sourcing.

Recommended by 1 HN people across 1 months · HN mentions 2016–2026

Topics

Software architecture & designDatabases & storageDistributed systems
Search by tags
event sourcingcqrsdomain-driven designgreg youngsoftware architecture

What people said

karmajunkie · 2016-10 · Recommendation

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 of boundaries you start to see where the services will fall out of it and what areas might benefit from ES the most. [1] [VIDEO]

Read the original HN comment ↗
austinthecoder · 2026-01 · Reference

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: [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 many people. Scale isn't an issue. I'm advocating for Events + API. With the idea that if you get an event that says "Widget 123 updated", you're free to hit the API to get whatever data you need.

Read the original HN comment ↗
fetbaffe · 2019-02 · Reference

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 [VIDEO]

Read the original HN comment ↗

Sources

Video by Domain-Driven Design Europe, played through YouTube.

Data and selection notes

HN summaries and labels may contain AI errors. HN dates refer to discussions, not video publication.

HN Library: HackerTube export (2026-10-31) and open-index/hacker-news. Upstream summaries and classifications may contain AI errors.

Views, duration and playback status refresh separately from the published catalog. When an update fails, existing data remains visible.

Selection checks
  • SaaS & AI candidates: Topic keywords do not match
  • Editor-approved picks: Editorial review is required

Rule matches identify candidates. They do not guarantee video quality or financial results.

About the library and its sources