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

and tackle complex architectural challenges in Northern Israel with his wife and an almost unreasonable number of cats. Book introduction. We've got building software is harder than ever. As a developer, you not only have to chase ever changing technological trends, but also need to understand the business domains behind the software. This practical book provides you with a set of core patterns, principles and practices for analyzing business domains, understanding business strategy and most importantly, aligning software design with its business needs. So we read through chapter 11 this week, we're about two-thirds of the way through the book and we'll finish out the book next week, but Nathan, what are your thoughts on what we've read so far? First of all, if we get Vlad on to do an interview, I really need to know, I need to quantify what an almost reasonable number of cats is. Yes, yes. That's like the audience must find out, what is that number? Yeah. He had a joke about like one is one or two or three, that's a good number of cats, like 32, that's a crazy number of cats, but that is inverse with teeth, where 32 is a good number of teeth. One or two or three, that's crazy. Yeah. I think so. I mean, we have a cat, so I'm a fan of cats, but more than two seems crazy to me. I can't imagine. I can't imagine, like two cats, that's like a full house of cats to me, if you have three or more, I think that that would be an unreasonable number of cats. Yeah, I think we have zero pets, so I don't know, I'm too much tits, that's what I have. I think that we all have zero pets one day. I think this is going to be the last cat for a while, great cat, we love her, but it does make traveling and things like that more crowded. Yeah, yeah, that's been my hang up with it for a while. Well, I am. As far as Vlad and his cats go, if we just got to Vlad and his cats, that's what it is. Yeah, all my thoughts on this book though, I like that, so we're getting into the nuts and bolts of things like this is sort of the transitioning from one part of the book to the other. And so we're start off sort of in this sort of tactical, DDD design stuff, and then we get into the last two chapters we cover are in the applying phase of like, how do we apply these patterns that we've been talking about so far? The applying part's been so much fun. I think we'll probably spend a decent amount of our time on this episode on chapters 10 and 11, at least if I have my way, that's when we'll spend time, but I was thinking about this because we just, you know, not that long ago read software architecture of the hard parts, which came out in 2021, and this book also came out in 2021, and you can see some overlaps in thinking, right? There's actually, there's really some, now that I'm like thinking about these two books together, 2021, good year for software architecture, thinking about stuff. Yeah, it's, I don't know, this book kind of had a similar thing where, I feel like we've read books like this in the past where the first third or so is spent just talking about like the principles. And I read those, and I'm like, well, that makes sense. This is great. Like I really agree with these principles. Then we get in some of the application and some things just jump out of me like, this is crazy. Like I never would have considered doing this, and I don't know if this is any better. There's one pattern in particular I want to talk about kind of up top, which seems nuts to me, but like maybe there's a really good reason for it. And I struggle with this sometimes when I'm like, is it just that the software I write is a lot simpler than other businesses and what they need, or is this just like kind of like a galaxy brain way of thinking about software? I don't know. So we'll talk about it. And you the listeners can chime in. Yeah, I guess like the galaxy brain take to me was the event sourced domain model. And before we describe it, Nathan, did this seem like galaxy brain to you or were you just like, I've seen this before? So I will tell you, for the uninitiated thinking about event sourcing, there's, I think there's a time in your life as a software engineer before you saw event sourcing and after. And I'm not saying you have to choose to use event sourcing afterwards. But when you realize that like, you'll see this pattern and then you're like, oh, this is why Kafka exists and realize that there's like the whole, the whole like asynchronous communication patterns where not only do we have pubs, not only do we have cues, but we actually have this thing where we can go back and like any producer announces to an