This pattern is crazy, or I'm an idiot - Learning Domain-Driven Design by Vlad K [23:51-28:56]

But if I do want a company that's using this pattern, right? Like, at least, I'll, you know, it won't seem crazy to me. And you know, who knows? Maybe we will get to a point where I'm like, we're finding like, jeezily is like, we're, as we've grown, we're all having a really hard time agreeing on like what the definitive state of the, the model is in our system. Uh, what do we do? And like, well, that's where the event source domain model comes in, like just admit the events and let people reassemble, uh, them themselves and they can, you know, act on the event at any point in time, which like, it's kind of like that's neat conceptually. It's like time travel. It is, uh, in this data warehouse project that I'm working on, um, this data lake really is what it is, is, um, we're really pedantic about a temporal model and data lineage, mainly because we're making business decisions on this data. And we need, and we're even building, you know, AI models and things on top of it. And I need reproducibility. I need to say, like a lot of times, we'll get new data in, that's corrections to like public data that comes in or even private data that we purchase. And I need to be able to go back in time and say, why did we make a business decision? Oh, actually, it's because this public data source had not been corrected on this quarterly basis. And we would want reproducibility where I should be able to run the model as of what I thought the truth was at some point in time. And you have to build it in a very deliberate way to do that. And maybe you're right. Maybe this, when you kind of have these awakenings of like, what does that actually mean to do this? You do kind of feel a little bit of galaxy brain stuff because you're like, oh, I can rewind time. Like I have, I have access to, because you know, a lot of times you're mutating state. And we see this even just in regular programming, why we like functional patterns over imperative patterns, right? Is that I need, when I start reasoning about complex systems, reproducibility becomes really important. And so in a functional pattern, if my constraint is that all inputs wire into outputs, and I can think through the chain, and there's not magical state transitions happening in secret external function calls, I can compose really complex things. And the same thing applies to these distributed systems. It's like, if we can agree on this pattern of reproducibility, even if I have no control over all the events that are being in there, I can audit the event stream. I can audit what's going on and digging it. And so, yeah, now it's super, super cool. And I guess this kind of naturally transitions into the next chapter, which is the communication patterns. Yes, yes. We, we covered a pattern actually posted on my work Slack because we used this at work. The outbox pattern for event driven architecture, which is this idea that, and you know, this is actually one, I discovered this via, I think I was using Chatchee BT at the time, because I was really concerned with this idea of like, okay, so let's say, like, you know, we'll use in Cleveland as an example, right? Like I book a session with like one of our experts, right? And, but then I need to send an email for that session. I need to send the email reminder to the code, or maybe a text reminder, or anything like that, right? Like, that has to happen. And that's going to, we know that's going to happen in like an event driven way. So, like, what do we do? And then like, this is a great example because it's notification, but there are some events where basically you say like, this event, this action is not complete, unless the associated downstream effects from the event also happens. So my, okay, so what do we do there? Or like, or you can have the other scenario where it's like, okay, well, what if the, what if persisting this to the database fails? Well, then we accidentally emit the event too. And that's what they recommend is the outbox pattern, which is this idea. Like, instead of just publishing the event like straight to your event stream to your, you know, SQS or Kafka or Kinesis, instead what you do is you have a table in your database called the outbox. And what you're writing to that is the shape of the event. And then you have some sort of like CDC process monitoring that table. It proposes two ways. You can do the push versus pull, right, which is like, you have the CDC process, which is monitoring that outbox table or maybe you just have some sort of wrong, long-running polling consumer, which is just consuming from the outbox. And then, as you consume from that outbox, then you're publishing the events. And when I proposed this at work, people were like, why would we do that? Like, this doesn't make sense. And the reason why you want to do that is because that way you are, when you're just right to the outbox, you can bundle it in the same transaction as the actual thing you cared about happening, right? And so, you know, if you're trying