This pattern is crazy, or I'm an idiot - Learning Domain-Driven Design by Vlad K [13:43-18:47]

I'm trying to do this without bringing up blockchain because blockchains are actually you can think of it as an event sourcing model because you can read entire ledger history to reconstruct the current state of, you know, what everyone's wallet, the values of tokens that you have in it, you can go back to the beginning of the ledger of the event log and replay the entire thing and all of us can agree that the ledger says the same thing, right? As long as the interpreter of those things are in the same. And so do I keep it in memory or do I actually store it in a Postgres database? It's up to me. Like, you know, if I have a ticketing service and a ticketing service, consumes from the event stream, right, event sourcing pattern. And then when you ask the ticketing service with the source of treatise, I should have a verifiable reconciliation between the two, meaning this, I should, if I blew away the ticketing service and I could go back and play the event sourcing feed from day one, let's say, I should be able to reconstruct that exact state that's there. It's completely reconstructable. Most events sourcing patterns do have a lifetime. So like, you're not going to keep all events sourced records back to antiquity. You maybe will keep seven days or 30 days depending on what you need. And so you probably will have some point in time that you've kept like your epoch for whatever a reproducible window is. And then I can go back and replay for some period of time. And the reason I bring this up is, let's say you find a bug in your code or a bug in something that was emitted and erroneously in the event sourcing log, I don't go back and change that in the log. What I do is, and these are called like temporal patterns, I actually put that record back in with the correction, and I append it to the very end. And so when I reproduce it, I can go back through. It's kind of like if you have a, you're in a copy that does like really strict schema migrations, right, right. A good schema migration pattern is that I, all events, all changes to the events, all changes to the schema should be in this reproducible order. I probably keep some state that says what's the what's the point up to where I've done schema migrations and it picks up where I left off, right. Or if I sort of a new infrastructure, I literally will replay the entire schema migration history. Very similar idea. And what's cool about this though is that let's say we have a new service that cares about ticketing events, ticketing activities, right. A ticket did this, a ticket did that, right. We're announcing these things on the event sourcing model. I can just start, I can make a new consumer and start replaying events from the earliest place that's available. And so doing stuff without having to coordinate with anybody else, right. And again, these should feel somewhat familiar. You're like, oh, I can do some of that with pubs up. I can do some of that with cues, right. But you kind of get, you get both of these things and you get this like really nice features where I don't have to worry about, oh, but I drain the Q in that, that, you know, that that that item in the Q's gone, it's not going to find it. And so it's kind of, it does, it changes your, your thinking where we can move quickly as a very large organization. I have this like nice audit history of what's going on. And yeah, I didn't, I never thought about event sourcing in the realm of DDD, but it's like a perfect fit, right. It's a perfect fit for all of these ideas of how we should break up and think about the structure of our application because once you can lean on the event store and projections as patterns, you end up having a lot more certainty in troubleshooting, for instance, right. We find about a section of this really complicated microservices that are in place. Okay, but we still have an event sourcing pattern. I can go back and say like, tick by tick. Who agree? What's going on? Where are these things? I could, I could even take a chunk of this. You could imagine a diagnostic environment. You could take the whole event sourcing feed and feed it into an alternate implementation to reconstruct and see what, what's the application doing under the under some deep scrutiny and stuff, right. Yeah. Yeah. And I really do like that about, yeah, and maybe, maybe, I don't know, maybe it just is the natural evolution because I like that about a bit in different architecture. We, we anyone who knows whose fault is podcast knows that we are in the middle of the big migration at work. You know, I'm not going to say in the middle, we are near the end of a big migration at work. Right. We are just, we actually just finished today the, we basically broke down every page on the website and like we have to point them from the old GraphQL service to the new rest service. And so we've transitioned all the pages, which means all the end points are created. There's like, a few, there's like some web book stuff and like a few kind of like scheduled