This pattern is crazy, or I'm an idiot - Learning Domain-Driven Design by Vlad K [36:31-41:34]

things that we'd like to just have this idea that any system could talk to any other system if they care about the consumption of events that are coming out of some other piece. And then all of a sudden, the interface becomes, can you read from Kafka? Do you understand which feeds and stuff that you're pulling from? And so we're actually working on some design documents right now. And again, reading books like this is really fun because I'm like, oh, yeah, we need to think about the trade-offs. We need to think about we get into chapter 10, which is design heuristics. Right. And I actually, I'm 10 and 11 got me going. This was a lot of fun. Specifically, he talks about these decision trees of doing simple and complex thinking through I think one of the things he was talking about was business logic patterns. Do I need to know does the history really matter? Right. If you're in a highly regulated industry, for instance, the history might just matter for regulatory reasons. You want to make sure that no one off you skates decisions or something. You can imagine that quite naturally, CQRS or event sourcing becomes really important because I'm like, you know what? Auditors are going to come in. They're going to want to know why we made these trades on the stock market or or a bank and, you know, account balances have to be like super locked down. These patterns just sort of naturally emerge in these like highly regulated fields or where you need correctness. But yeah, again, like I also, I also love he, you know, just thinking about these domains that you're in, ports and adapters. Right. We've talked about this in the past where naturally I'm a big fan of inversion of control. I'm a big fan of these. In, inversion of control isn't ports and adapters, but ports and adapters uses inversion of control if you really think about it where you want to explain the ports and adapters pattern for. Yeah, yeah. Actually, I'm going to pull this up so that I'm not like doing something really goofy. And because a lot of times you'll hear people compare ports and adapters versus layered architecture and layered architecture is one that I think people are, that's like the presentation layer, the application in domain, and then there's this data layer. Right. Like that's sort of what we think of with a lot of like more traditional web apps and stuff. Right. Like I have this UI layer and I have like the business logic and then I have data underneath. Um, ports and adapters is this idea that you have these like, you have these areas of responsibility that you can, I'm trying to, I'm trying to see if I can find the, the image here. All, so the business logic source sits in the middle and then everything that it's like coupled to you is try, you try to extract, it abstract these away. So, you know, you basically have this ability to hot swap the data part, the swap, hot swap, telemetry, hot swap, these other components that are going to be in place. And it's all kind of like sitting around this like central this central piece here. And I'm trying to, it's so funny because like I, I use this pattern in various ways. But I've never been like a DDD maximalist on this. But I'm like anytime I read about the hexagonal architecture, I'm like, oh, I kind of like, I kind of like naturally drift into this anyway. And I'm just trying to find a good. Yeah. So like the idea of like ports and adapters is that I have my application, maybe in the adapters layer, I might have like a rest controller. Right. This is how I get into my like external application. I have a message queue adapter. Right. And again, if anybody who does dependency injection or inversion of control, this seems really natural. It's like I, I, my business logic doesn't have any knowledge of the implementation of how I talk to the queuing service. All it knows is that there's this hook to get into something that is a queuing service. It just so happens that my adapter goes to rabbit MQ. Right. Or it just so happens that I have a fake on my local dev machine. It's like rabbit MQ enough so that my business logic functions, right? Right. Right. And then you get this like really, they call it hexagonal, but there's actually only like four areas. It's kind of weird. The top in the bottom don't have anything on them. But um, that's hexagonal with four sides. Yes, hexagonal is like two inactive sides, right? But you know, so you'll have these like communication adapters. This might be like an email or SMS like you'll see these kind of things. You have data storage adapter. But the idea is that the business logic stands on its own. It's just right. Right. Right.