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

on virtual machines that are ephemeral. So you basically, you do a little bit of upfront work, but your entire dev environment gets spun up with TMAX and a bunch of other kind of cool things. And you can give it a set of tasks and it kind of like keeps the scope within when it's allowed to do so super locked down. And you can give it agentic stuff to go off and do on its own, but you still have full control and you can be the sort of like, you know, human and the loop part as needed. And I've been actually falling in love with it. So it's funny. Like I'm dusting off my old dot files and I'm even building my own skills repository because I want to make it super easy for me to like spin up a virtual machine from scratch and just have a productive work environment for climb. Which again makes all kinds of things nice. And yeah, I think we're going to continue to explore these areas. And this actually gets us into our final chapter for this, which is evolving design decisions. So I loved this section because I end up having this conversation a lot, which is, you know, software is always a moving target for how the business logic works. Part of that is because you discover the actual needs of the business as you're building. And so therefore, you're like, oh, I thought this was the app context, but actually should be divided this way. Some of it is that the business needs themselves change, right? That a new competitor comes to the market. Some new idea is out new customer expectations, um, enter the conversation. And therefore you realize the decisions you've made in the past are not serving you anymore. Right? You need to make some modification. And this chapter's awesome because it talks about migration paths or, um, you know, what happens when an organization grows. And now you have to split teams up or, you know, like, there's always like really kind of juicy hard things to think about. Where you're like, oh, yeah. This is actually three app contexts. Or we thought this were two separate ones was actually one app context. It's now we have this like tightly coupled two app contexts. And yeah, I, I thought this chapter was my favorite so far, actually. Yeah, no, it's a great chapter. Um, and again, like, I think there's a lot of overlap with this and software architecture, the hard part. Yeah. Um, and yeah, like, I think that's fun. That's, I think that's fun about like, I wonder if the culture's changing a bit. Like we used to really reward job hopping. And I feel like I'm seeing a little more in the water these days that like now we want people at their companies a little longer. We want people to kind of live with the decisions they make. Um, yeah, I don't know if that'll be true. And it's also like, this is an insane industry where like if you meet someone who's been at a job for five years, you're like, whoa, like you're like the old man on the mountain. Right. And so we might just be moving from somewhere where like three or 10 years is pass a four year 10 years is what we actually want. Um, and yeah, we got to wrap up. Um, yeah, before we do though, I think the one last little concept from chapter 11, I remember at the beginning of the last episode, you were kind of like we were talking about difference between core and generic and supporting. And I loved that this chapter sort of said, Hey, not only is there a difference between core generic and supporting subdomains, but you could transition, you might transition from one to the other, right? You might have self-hosted something and you decide you just, the off the shelf tool, so amazing now, right? You should transition to some generic implementation or vice versa. Like I even brought up an example. I think it was from generic to core where Amazon, right? Yeah, they talk about Amazon Web Services and they go, you know what? Instead of us buying off the shelf stack and rack servers, what if we built an entire business unit around this new idea of API first infrastructures code sort of driven infrastructure and made an entire core business out of something that was, you know, before that, it was just a commodity thing. It's like, oh, I'm going to go talk to Dell or some OEM and buy some stuff and purpose build it for Amazon.com. But no, they kind of, and so I liked that they kind of walked to like, how does something go from generic to core, core to supporting or supporting to generic? And yeah, just yeah, I like that idea too, because you're right, like something that's really critical now might not be in the future or, you know, yeah, might become a commodity. Something that you weren't that interested in might become really, really important, right? To your business. So again, all about judgment and, you know, how these things evolve. As far as hot takes go, I mean, to me, you know, you've swayed me, Nathan. I thought the event sourcing model seemed insane. And the more I think about it, I'm like, you know what? They're crazy ideas. And I could see this being like incredibly valuable one day. So I petty the poor junior engineer who winds up on that team and is like, this is how software is built, because they're going to teach me anything like this in school. But good stuff. What are you, Nathan?