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

jobs, we're still writing. So we're, we're near the end here. But anyhow, but part of what we did was an event driven architecture because we had a lot of kind of like side effect stuff like sending emails or updating records in the CRM or notifications, things like that. So we went, did that an event driven way. And so I'd like, we've run into places where like, oh, we had a bug in the way we processed these events. So that's fine. That's just ship the new consumer. And then we'll just go back and, and drive the events again. We use AWS Kinesis for our, we looked at it was like, Kinesis is great. I've used, I used it for a large scale distributed web crawler with land does and a bunch of stuff. But Kinesis is awesome. And it's, it gives you a lot of what you would want from Kafka without having to become a Kafka expert. That, that's what we looked at. We were like, okay, like setting up like SQS is not enough, right? Like we needed something a little more than like SQS. And we were looking at like having to spin up like new SQS cues every time we wanted like a new, you know, consumer stream. We don't like that. And then we, so we're like, okay, well, Kafka is the other option. We're like, that seems overkill for what we're trying to do right now. So Kinesis was like a good middle ground option between the two. We'll see how that treats us in a year or two. Um, and yeah, so I like event driven stuff. It's been working out really well for us. And yeah, maybe that's like event sourced, uh, you know, I mean, what does he want to, I just, the event sourced domain model. Maybe that is like just the natural extension of event driven architecture. And you may get there. I also love that he brought up something that I think is also true. Sometimes we'll overload the term event sourcing where what folks really need is, is a CQRS, which is the command query responsibility segregation. Are you familiar with this term? And not what he talked about it, but I think rocking. It's kind of what you guys are doing already, right, which is this idea of this clear separation between something that writes in something that reads from. Right. Okay. Right. And so there's this idea that I write to it with maybe some contract of how I should have the shape of the data, but that the reader is actually the interpreter of those events. And those are sort of decoupled. Okay. And the reason is because my reader may evolve over time, right. And he the kind of cool thing he talks about here is that like, you get these sort of, um, you get these sort of like these evolutionary patterns start to emerge because the business changes, or you realize that there's competitive advantage to bringing something in house. And so with CQRS is, it's really important that like you have a right model, you know, you can think of a lot like how an API is created and, you know, how you might want to take care of like not making breaking changes to it and things like this. And then the read model is just any reader is kind of up to the interpretation itself, right. And this is what gives you that decoupling is sure. Maybe you have a standard and you say, Hey, here's the schema we have and everyone should try to approach reading it like this. But if a team wants to come up with some radically new idea or only cares about a certain type of event that's being written, um, it's really up to you, right. And uh, that pattern is really powerful, even if you're not doing strict event sourcing. Right. And I think that that's sort of the, and I will say he does a really good job of giving trade-offs. Um, yes, he really did. He wasn't like, this is the one true way of building software because I was kind of like holding my breath a little bit because like I do actually love some of the art, the patterns that he gets into because he talks about layered architecture, ports and adapters, which again, people who love or hate DDD, I think ports and adapters are one of those that I, I hear about a lot or they call like the hexagonal, um, hexagonal architecture, CQRS. Um, and he talks about how like these are, there's trade-offs to each one of them, right. And maybe your business models itself best with a later layered architecture, maybe ports and adapters is a better fit or maybe you want to have the CQRS, um, for these things. And I thought that this, I think it's chapter eight that really got into this. It was, it was enjoyable. I, this was a kind of thing where I'm like, I would go back and reference this again. Uh, if I was kind of tingled up somewhere. And not to me is just one of the value of like being well read or listening to this podcast is like, just understand, like you just get exposed to these ideas, right. And like, you know, we're doing event-driven architecture, but like, I, you know, say what you will about like event source domain model, right? Like, I don't think it's a very intuitive pattern at all, which is not to say that it's wrong, right? Like a lot of the best parts of software are not necessarily intuitive. Um, and so again, I don't know if I'll ever pick this up in my life. I don't know if I will ever as, you know, a lead decide like, this is the pattern we're going to use.