Domain-Driven Design Europe
1 HN recommender · recommended in 3 months, 2016–2026
48:04 · 190K views · Apr 11, 2016
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.
HN commenters cite it in event sourcing threads for Young's views on when to use it, including advice against cross-application event sourcing.
4 comments from Hacker News
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] this video
> 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 systems are using to manage the nature of async, evented development that others aren't. If you mean "event sourcing" then the application of event-sourced data is neither an application architecture nor appropriate for all areas of your application[1,2]. If you were trying to apply event-sourcing in this way its not surprising you ran into problems with it. > Until then, my main advice is to make sure you have solved your system with a naive solution before you move on. It is important to really know and understand the problem domain you are applying ES to. Having a strategy to upgrade streams to new versions of your domain model is a good idea if you're applying ES to a business without a well-understood domain. However, it is very, very difficult to back into an ES implementation from a
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 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.
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