This pattern is crazy, or I'm an idiot - Learning Domain-Driven Design by Vlad K [10:02-13:41]

event sourcing the log that these things are happening and then consumers get to decide where they are in the timeline and it just process from that point in that everything's a pin only when you start having these large scale distributed systems where you really want to have everything right, you really do have to have these patterns like and we're talking about when you're trying to provision and plan for dozens of teams, right, or dozens and or hundreds even sometimes of services, these, these sort of have to happen, right, that they, they, and you'll see the organizations that use these patterns and you can kind of get like event sourced build a bit because as soon as you start seeing this, you're like, oh man, if we had this, I wouldn't have to coordinate this team over here. Like I would just announce what my schema is, have this thing that's up here. Now we just talk about producers and consumers and I don't even have to coordinate anything at this point, right, like it's, it's a really, I like that he spent the time talking about this and I think that also a book like learning DDD is helpful written in 2021 versus going back to the blue book like the Evans book on ID, which is sort of before all these ideas started to emerge. Like you, you look at designing data intensive applications. A lot of these ideas started to get introduced, but now that we're in the 2020s, these patterns aren't these like new and upcoming things. It's like the way that you do these types of systems. Okay, so event sourcing for anyone who is unfamiliar is this idea that you don't store in your database, like the final, like current representation of the object, right? So like, for example, like let's do a ticket tracking system, right? So like a ticket might get updated, you might update the customer's address, you might update their name, you might update the description, you might change the status from pending to assigned or whatever. And in like kind of the simple way of thinking about is like, okay, well, that's a table in your database and as you're making those changes, you're updating them. Then we started talking about like event driven architecture, which I like. We use event driven architecture at work. And the idea there is that like, you know, as you're taking these actions, you're emitting these events like, okay, status updated, address change, things like that. And I really like that from like a decoupled nature because you know, just the separate distributed consumers consume those events as they choose. But where I was like, man, maybe this is like galaxy brain take is he says, like, you shouldn't just have a table that's like, okay, this is the ticket and this is the authoritative record of the ticket. Instead of what you should be doing is consuming all of those events and constructing in memory the right now representation of the ticket based on all of those events, right? And so like, you'll see like, okay, like customer, you know, tickets started out as created and then moved to his pending and then moved to assigned and then moved to complete, right? And so rather than just like reading from the database, like, okay, this was complete, you're like stack all those changes on top of each other. And so like, very quickly, it'll assemble itself, you know, into the representation of the ticket. Like, yeah, I think that that must just be the answer. It's just that like, so I'm at a startup. And so we don't need to worry about this. Yeah, it's, so in a couple of things, because of the way that this works, we actually don't care how you're storing what they, I think he, you know, he uses the term like, I think it's projection is the term he uses. But this is basically like,