Skip to content
Hallway
0:00 / 0:00

#cqrs#eventsourcing#ddd

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

Domain-Driven Design Europe

37K subscribers • 3 videos on Hallway

YouTube
  • Recommended by 1 person: 1 on Hacker News.
  • Presented by Greg Young

Intermediate. Assumes working knowledge.

190K views10 years ago1 recommendation

Software designDistributed systemsSoftware architectureDomain-driven designEvent-driven systems and messaging

Greg Young reflects on ten years of Domain-Driven Design, CQRS, and Event Sourcing, explaining where these patterns apply and how to keep them simple.

Domain-Driven Design Europe 2016 - Brussels, January 26-29, 2016 - Organised by Aardling (aardling.eu/) dddeurope.com newsletter.dddeurope.com/ be.linkedin.com/company/domain-driven-design-europe bsky.app/profile/dddeu.bsky.social mastodon.social/@dddeu@m.aardling.social Gregory Young coined the term “CQRS” (Command Query Responsibility Segregation) and it was instantly picked up by the community who have elaborated upon it ever since. Greg is an independent consultant and serial entrepreneur. He has 15+ years of varied experience in computer science from embedded operating systems to business systems and he brings a pragmatic and often times unusual viewpoint to discussions. He’s a frequent contributor to InfoQ, speaker/trainer at Skills Matter and also a well-known speaker at international conferences. Greg also writes about CQRS, DDD and other hot topics on codebetter.com.

Why it's here

1 person recommends this

What people say. Engineers recommend this talk for its pragmatic insights on when to use event sourcing and why to avoid cross-application event sourcing.

karmajunkieon Hacker News • Recommends

On “Why Are People into Event Sourcing?”

…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 link to this video…
View on Hacker News

u/ragharin r/scala • Mentions

On “CQRS and EventSourcing framework for scala”

Some people would say that there is no need for such thing as Scala already has mattern matching and foldLeft. After a bit of thinking I have to agree: what do you use? Dooby, Slick, Cassandra? What is your event format? Custom case classes, protobuff? Once you remove all specific use cases, there is not much common part left. Just use whatever event/message format you want to use, foldLeft with pattern matching over it, and the only thing left for "framework" would be ensuring that operations are idempotent and you save the offset of last parsed event... which you could have easily achive with whatever DB you want and possibly sth like Kafka if you don't want to store serialized events…
3View on Reddit

karmajunkieon Hacker News • Mentions

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…
View on Hacker News

fetbaffeon Hacker News • Mentions

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 link to this video
View on Hacker News

austinthecoderon Hacker News • Mentions

On “My Workplace Disallows APIs”

…nt 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: link to 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 many people. Scale isn…
View on Hacker News