This pattern is crazy, or I'm an idiot - Learning Domain-Driven Design by Vlad K [43:00-48:00]

I really like this. I've actually been doing this. I've been working on like a personal project and have been like, like, I need to in production, it's a personal product, there's no real production, it, the back and forth all happens over email. Right. But locally, like I need to simulate, you know, doing emails. But I don't want to actually set up like some sort of real email system locally. And so I created basically two different like email transport systems. One is like the actual one. And then the other one is it uses like local storage just in the browser to like simulate emails, getting sent back and forth. Right. And I really, really like that pattern because like, I like keeping the decisions like just in one place, you're just like, hey, if the environment is dev, then use this, you know, interface. And if not, then use the real interface. This was where I was like earning my keep with Claude, because like Claude, initially when I said like, yeah, I want to, you know, I need like some sort of like local storage mechanism to simulate emails. Like, oh, great. And then started like 17 if statements throughout the application. And we're all like, if, you know, we're in dev do this and or else do that. And I told them like, no, no, no, we should do like like a dependency inversion principle here and and, you know, almost like the strategy pattern. So I really like this. I think it's a good pattern. Oh, it's great. So I did something. I did something that I think was really helpful. So I've been, I've been going to bespoke software in Claude, you know, just turns into craziness. But for bookoverfluid.io, it's been sort of my little lab for trying out all kinds of stuff. And I now have a bunch of administrative tasks that live through a, a command line tool called, it's called bactyl, which is blockoverflow control. And bactyl actually, this is a weird thing. And I didn't know how it felt about it at first and actually kind of love it now. All the services on our website are actually like service modules. And I can use this exact, so if we do things through the administrative portal and panel, it uses the same exact libraries as I can use from my command line tool. So they're completely shared libraries where I've abstracted away tasks, whether it happens through back end of a website, like I'm updating books through a graphical interface, or I'm batching a bunch of stuff with this command line tool because I use like these little tomel configs and I can do a bunch of cool stuff like add a episode to the queue and push all the other episodes back and just like a bunch of administrative things. And I've built a skill around it. But part of this I also wanted to build an audit log because I'm like, if I'm going to like clawed, handle some administrative tasks that really run an audit log to tell me everything that's happened. Well, the cool thing is, now we have an audit log on the website. So if I do any administrative tasks on the website, I get the same thing in the business objects entirely the same. It doesn't care if it's running in command line tool context or it's running as a backend service because the service modules themselves are web server agnostic, right. I can run it in the command line tool context or I can run it there. And so what do I have when it's a command line tool? Oh, I'll have a wrapper that has like flags and arguments that get passed in or maybe it parses a tomel file that has a bunch of structured data. But all of that's abstracted away in adapters. So the service itself, you know, it doesn't know anything about tomel. It just knows that some adapter took some tomel puts in structured data. The service itself handles it. And if it's a web interface, it's probably came from a web form, right. It's a web form that again turns the data into the shape that I expect it to be. That's an adapter. This is like sort of like web form adapter piece. And so yeah, this is like it ended up being super productive. It makes it super easy to test. It makes it super flexible. I have a single code base for my administrative tasks from the command line and the web graphical interface. And it's been a delight to like extend. I've been able to add all kinds of little features with confidence because I have excellent test coverage. I understand like I can go back and read the code and go, oh, this is this like these cool service modules that I have in place where the business logic is just like super clear. And I've abstracted away all the different formalities around like, how does it get in out of the database? How does, you know, if I post operation from the web service versus using Tommel from the command line. And I don't know, it's I again, I was kind of looking at this and you're like, oh, this is because I have like really nice, I have a nice like hexagonal architecture here. I love the ongoing evolution of the book overflow website. It's one, the website is much better than it used to be when it was just