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

Any hot takes? I didn't have any hot takes this week. I just couldn't think of anything that was like a zinger. I was, I don't know, I, I, I didn't have any of the criticisms that I had the first week or, you know, sort of like all the things here are like in my wheelhouse. I like to think about software architecture type stuff. And yeah, is that the sign of a great book or is that the sign of a book that maybe didn't try hard enough? Maybe it should have shocked us. Or maybe I didn't try hard enough. Maybe that's the other side. Okay. So as far as what we're going to do differently, me, we talked about this outbox pattern. We have this outbox pattern. We're in this weird situation where like because we're migrating from Mongo to Postgres, we had to treat Mongo as the source of truth. And then we were replicating the Mongo changes to our Postgres instance. We're finally at the point where we can deprecate Mongo collections. And so, but the whole point of the outbox patterns that you can do things in the same transaction. And we actually haven't been doing any of that because we've been writing to Mongo. So as we switched and write to Postgres, I need to bundle those transactions with our currently existing outbox transactions, which are on Postgres because that was a net new concept. So I'm going to get that working. How about you Nathan? So mine, this one sounds so simple. But in the section that he talks about designing for change, this idea that you need to periodically reevaluate your design and say, is this serving as well? I just hadn't thought about being like, oh, I should put that on a schedule. Like, maybe look at this once a quarter and be like, is this serving me? And then sign off on it being like, yes, this is still doing great. Or I'd be like, you know what? I don't think so. I think the stress cracks are going to kick in next quarter with what I know is on the road map, right? And so I think I'm going to try this. I'm going to actually add some events to my calendar to reevaluate some of the design decisions I've made on this data project, you know, in another couple of months. And I like that. Yeah. I think so much of software engineering is just inertia, right? And taking a set back and being like, okay, let's actually think about this. Is this doing what we wanted to do is underrated? Okay, well, that takes us through the week. We will be back next week with the final third of this book. And yeah, you can always find us at, oh, wait, who do we recommend this book to? I did the wrap up. I'd say if you're looking for more sophisticated ways of constructing software, this is for you. Again, that event source domain model was really interesting to me. If you're trying to break out from like just basic crud, like this is a good book, you know, I dipped your towel in the water a bit. Yep, I agree. My recommendation doesn't change from last week, which I said, you know, senior plus engineers and leadership struggling with building alignment on stuff. I also think that this gets into if you're a fan of the ThoughtWorks books, right? If you're a fan of Neil Ford and Mark Richards, this is a nice complement, right? This should be on the shelf right next to the DDA. Fundamental Software Architecture. This book should sit up there too if you're kind of getting into domain driven stuff. Hi, praise. All right, well, you can find us on Twitter, Epic or FlowPod. You can find me on Twitter at Cartamorgan. You can go to bookorho.io, see our website and the schedule. And you can find Nathan has consulting at work at rojorobato.com. We'll see you later, folks. See you.