Coding Blocks - Clean Architecture – The Art of Drawing Lines

Episode Date: February 5, 2018

It's time for another deep dive into Robert C. Martin's Clean Architecture as Allen warns us about driving in front of him, Joe tries to describe a diagram again, and Michael can't understand the survey results.

You're listening to Coding Blocks, episode 74. Subscribe to us and leave us a review on iTunes, Stitcher, and more using your favorite podcast app. And check us out at CodingBlocks.net where you can find show notes, examples, discussion, and more. Send your feedback, questions, and rants to comments at CodingBlocks.net. Follow us on Twitter at CodingBlocks or head to www.CodingBlocks.net and find all our social links there at the top of the page. With that, I'm Alan Underwood. I'm Joe Zach. And I'm Michael Outlaw. Freelancers and small business owners, I feel for you. Tax season is here and there's a good chance that many of you are trying to

dig your way out from underneath a pile of receipts and spreadsheets. Do yourself a huge favor and stop digging. Before you completely disappear under the abyss of paperwork, go and check out FreshBooks cloud accounting software. Not only is it going to save you a ton of time and stress, it might actually change the way you feel about dealing with your taxes. Need to send your accountant a quick summary on the amount of tax you've collected last year? How about pulling together a profit and loss summary? FreshBooks can generate these reports in seconds instead of the hours it would take you to do them manually.

You can even set up FreshBooks to import expenses directly from your bank accounts, which means next time you use your debit card for that meal, tank of gas, or new computer, boom, the purchase is recorded instantly in FreshBooks. And all this and FreshBooks is ridiculously easy to use. It's made especially for people who don't like dealing with numbers and their taxes. Right now, FreshBooks is offering a 30-day unrestricted free trial to our listeners. To claim it, just go to freshbooks.com slash coding and enter coding space blocks in the how did you hear about us section. All right right so this episode we're going to be talking about drawing lines as we continue to dive into the latest series clean

architecture but first all right let's start off a little bit of news uh first off thanks for the reviews we really appreciate it uh from itunes we've got an awesome name here, Unhandled Except Sean. I love that one. Yeah. And on Stitcher, we have Robert B., R. Gomez, and once again, Unhandled Except Sean. Yes. And R. Gomez, thank you very much for the long, heartfelt review. I know that you were a little bit worried about your English, but we'll take it, man.

Very much appreciated. Okay, so now it's my turn. So I have a couple of rants that I've got to get out of my chest. So one is completely not related to anything coding. It's just everyday thing. I drive a truck. If you're going to pull out in front of me while I'm going 65 miles an hour down a road, you better hit the gas pedal. And if you pull out in front of me in a

BMW and you do 20 miles an hour, I really want to run you over. Like I know none of our listeners are those people, right? Like you're not going to pull out in front of somebody and basically be stopped on the road. But please share this with with everybody like the bigger the vehicle you drive the more you want to run people over who do things like that but why are you going so fast through a school zone oh man i did that the other day oh did you get a ticket no um i got a hand shaking at though oh i just i don't know what it. I stopped at a red light. I was actually already in the school zone. I just kind of forgot about him in the green line when I just went like normal speed until I saw the guy in the orange vest.

I was like, hey, you. You better be glad it was just a hand shaking because the ticket and one of those things. Yeah, or hitting a bunch of kids would have been pretty bad too. Yeah, that's never good. Yeah, man. At any rate, rate yeah that's rant number one okay so my blood pressure is slowly going back down now um the other thing man like if we're all coders and so we all face challenges all the time right like i think i even made this analogy on Slack the other day about like you're working on a problem and it feels like you're just pushing that problem along inch by inch. Right.

And you finally look up and you're like, man, I made it a mile down the road somehow. I don't know how I got here because it feels like it's been a struggle every step of the way. that is because when tutorials are written, they almost always feel like they are written with the most simple use case in mind, not the most common use case, but the simplest. And that drives me absolutely crazy. Like this thing that I've been struggling with, I've been trying to work on Kafka and some data things. And there was this one little nuance that has probably cost me a week of nights. Like I'm not even joking. Like it's, it's been a lot of time, man. If there is a little nuance like that, that you figured out and you wrote an article about bold it, highlight it, make it a 90 point font, make it blink. I don't care what you got to do. Call it out.

Like that, that is a pet peeve of mine is when, when there's simplistic use cases that are like, oh, this is so easy to use. But then anybody that really goes to use it, they end up frustrated. Like, man, do everybody a favor. If you're writing blogs or you're doing anything like that, and there's something that really does jump out as not really expected, call it out. Like seriously, call it out somehow, because you will, you will save hours of frustration from other people, even though that you wrote that about that blog post and you wrote it

in there. If it's just sort of in the flow with everything else, then, then I don't know. I feel like it's almost a disservice. So that's, that's my ask of everybody. Hey, you know, that reminds me, I'm assuming, hope I pronounced that right. Sorry. Slight Edgecutter recently wrote a great blog post about a similar problem where he's working with Passport.js, just got stuck for hours, ended up finding out that it was just a simple config change that he ended up having to make. And what he did, though, is he went and wrote a blog post saying,

hey, if you hit this error, do this. And so not only is he leaving a nice little kind of breadcrumb for him to find if he runs into it again, but he's also helping anyone else who might end up Googling and finding out the same error. So that's a great way to kind of combat those kind of problems. Oh, that's a great point. Actually, when I went off on the – I didn't go off.

When I mentioned the thing about you feel like you're just making inches of progress. But the thing that I am terrible about with this, and I'm curious, you guys probably are too, is you fought your way. Like you seriously, like it feels like you just keep hitting walls and you finally make it a mile down the road and you forget what those walls were. You know what I'm saying? You forget exactly what those problems were and you didn't document it along the way because you don't want to stop.

Because as soon as you stop, you feel like progress is lost. You just don't want it. That momentum is hard to pick back up. And I don't know the right solution to that. I'm not that guy that can stop. Because if I do, then I'm just going to walk away from it. And I probably won't look at it again for another month. But if I just keep my head down and I keep going.

But then the problem is at the end of it, I can't go back and say, oh yeah, I hit problems A through Z and here they are, you know? Yeah. Don't you hate when you're like, oh man, I know I ran into this like five months ago. What did I do? And you're like, you're searching your email, you're trying to look at your commits around there. Like what was it exactly? I mean, Outlaw is really good about documenting things like that. But is it because you take the time to stop and make a note of it? Or is it you just remember it? No, it's definitely like I'm taking the notes as I go. Yeah, I should, but I just can't do it.

I mean, Joe, you asked a question today that triggered a memory about, you know, there's this error coming up. What is it? And I was like, man, I, I vaguely remember that. And I got close enough to where you're able to find it, but stuff like that. It's amazing how much time you lose just by not taking note of those little things that trip you up along the way. So. Yeah. But I'm also really bad about, uh, definitely, I would definitely say I'm, I'm, I'm guilty about taking the lazy approach too and just being like i'll remember it for next time and then i never did and then you hit it again and then it's like two hours later you're like oh it was just

so that's why that's why when you see the notes that i do take you're like oh wow that was really good really detailed it's because like yeah those that's like one of the times where i did bother to take the notes as I went along. I'm like, fine, I'll document this so I never have to look at it again, never have to remember it again. I can just go back to this article. Yeah, I don't remember who I was talking to. But then because that was such a to-do, that's why I don't do it that often because it's like, ah, it's such a to-do, man. It's a time.

Yeah, it's a time sink. I don't remember who I was talking with in slack i wish i'd taken notes of that one too but it's like they said you'll find yourself doing it and then all of a sudden three months later you'll be back in that spot and then that second time you're like i'm documenting it this time right like the first time you're trying to get through it the second time you're like okay lesson learned all right i'll do this i think there was like a hanselman um article that or comment or something like that that was similar to this where um a lot of his maybe inspiration for a lot of his blog articles was someone would ask him a question and he's like you know what i could answer

this to you or to myself or whatever or i could just go ahead and write the blog. And then that way it's always available forever for anyone to see. And, you know, then anyone else that asks the question again, they can just go look at that. It's the smart approach. Seriously. So I've been kind of working with a little hybrid.

I just switched to Evernote in 2018. I've been trying to kind of basically keep it to get a distributed note system and kind of like a slash bullet journal. And what that means for me is like, you know, say like my workday starts, I'll have the three or four things that I want to get done. And then whenever I run into a little something, like say I want to mention a ticket or I want to ride a ticket or something, what I'll do is I'll go ahead and add just a line item, like kind of indent underneath that. So I don't have to stop when I'm working on, I can just put a little note that says like, hey, talk-and-so about this and i'll even paste like little things like urls like if i'm

you know you like working on a you know website or something and i keep refreshing the same page just go ahead and paste the url in there in case you come back to it tomorrow and you don't want to have to remember how to get there um it's been really helpful for like commands like sometimes i run a little like command you know um like powershell things or executable type stuff i'll just go ahead and paste the command in there and then it's nice but i'll go like scroll up like oh yeah what was that thing i ran two days ago like now it's not good for long term like you gotta you know like obviously after like nine months or a year or whatever that thing's just going to be unwieldy but um i go ahead and i break the files off uh every month so at least it's a little bit easier to find and then at the

end of the day when i finish the ticket whatever i can kind of um have my little notes and things i want to make sure to mention in those comments yeah i've gotten into the habit too as far as like note taking is concerned of like i i didn't i didn't used to do this but now i'm getting in the habit like anytime i'm taking notes i just go ahead and do it in markdown i just go ahead and do it in markdown and then and then um like i think jay-z and i were on a call recently where like it just conveniently worked out i was like you know what i can just take this whole thing and just make a wiki article out of it and then it's already done that's beautiful because i wrote it as we went i am curious why uh why evernote instead of onenote oh um just because i want to be able to do it on

my phone i mean i'm like i'm sure onenote works on my phone too. I do have office three 65, so I could, there's also Google keep. Yeah. Um, it just, Evernote was the one that I'd heard of from a J over at productivity and tech. So that's what I went with.

Um, every one note, like I did use that a little bit before you could paste pictures and stuff in there really nicely, but I wanted to keep things like simple, like plain text. Um, and I do it in Markdown.

Just like I said, cool. Excellent. So what'd you got up next? Uh, I'm'm gonna be doing a bit of public speaking um you know crossing off some things on my bucket list here so you can catch me at the next uh orlando.net meetup or at orlando code camp coming up i think in april so if you're in the central florida region you should uh come over and say hi check out my talk throw stuff or if like me you've already booked your hotel and flight reservations yes yes that's awesome yeah come heckle me be great i'm not sure that's what you want to think you're doing it wrong

this would be memorable um also uh if you want to win a copy of the book we're talking about again today clean architecture go ahead and just leave a comment on this episode uh be cookingblocks.net slash 70 episode 74 yeah we had some great comments also by the way on episode 73 some like really good ones well thought out yeah so uh if you want to get lost in some some good talk there uh go check out episode 73 show notes as well i thought there were some excellent things on there i'm terrible at replying to them but i do read them and appreciate them yeah sorry i try my best um and also uh we mentioned it on the previous episode. If you are interested in helping the show out as well as yourself, you can head to codingblocks.net slash resources. I've been trying to like for

this book, linking all the episodes to the book that we have. And also if you want to go buy it on Amazon and follow along, you can do that. But again, codingblocks.net slash resources, we're only going to be putting things up there that we truly use and recommend and and you know would would buy or do by ourselves so definitely check that out if you're ever interested in you know furthering what you're doing and that's it yep so let's get into the the meat of the show and talk about drawing lines. And right away, it starts off with a fantastic quote that we should burn into our memory banks forever and ever. Software architecture is the art of drawing lines.

Man, that's so good. It's so true too, because every decision that you're going to make about how you architect some solution you can think about it as how you're drawing lines around things so like in the domain driven design conversation we talked about circles and grouping things like you know uh different part different aggregates over here you know different trying to break up your domain model into different functions, right? That was just a way of drawing lines, right? We were grouping things in like, you know, drawing lassos around functionality in that

example. Yeah. And what they say here is pretty simple. They're there to keep one side from knowing too much about the other, right? And that's important. It's not knowing about the other side, it's knowing too much about it. Like you don't want to know how the internals of it work. You just want to know what it has available to you. Sorry, I was writing over here. So I just wanted to put together like, it seems like every couple of chapters, like they'll come out with a, there'll be like some

sort of statement in the book that's like, software architecture is drawing lines. I wanted to pick up some of those. I actually went through our show notes really quickly here and found various bold statements about architecture. Now we've got a line drawing programmer who is concerned with the intent, operation, deployment, and maintenance of systems. Nice. I like it. And one of the things that I think was key about this whole line drawing thing that they're talking about here is this isn't just done when you start planning the software

or before you ever start writing it. This is done throughout, right? This is an evolving thing. So it's not a one and done thing. It's as we said earlier, right? As you're architecting your software, you're shaping it, which means that you're also drawing those boundaries as you go. And I really liked that because later in the book, they actually come up with a, or actually in the chapter, come up with a couple of tales of kind of column case studies where they talk about what happens when it wasn't the

point of the stories but in both cases I think the architecture was separated from the operation so and one I think the architect kind of came in midway and you know threw out a big blueprint and said this is what we're doing and it wasn't really so much caught up in the day-to-day and ended up kind of building something where the architecture was not in line with the actual business requirements. Right. And that's what this chapter is all about. It's about drawing lines so you can defer those kind of decisions and not make those kind of bad decisions too early. I just thought of something that would be like a perfect visualization for like the software.

Well, normally we talk about like the software development lifecycle, right? But if we were to think about like the software architecture lifecycle, you know those visualizations that you see? I think it's like the life animation or something where it's like the cellular division keeps happening right oh yeah game of life cellular automata yeah i was trying to find an example of it but um like that's the perfect animation or like you know description of the architecture right is this it's okay it's going to start out big but like it's going to continuously evolve you're going to keep drawing new lines new boundaries around uh you know components and modules and things like that and breaking things off but that's gonna that's gonna happen over time you're not gonna try to do all of that at at the start and if you do you're probably gonna fail at it because you're

gonna try and work within those confines artificially a lot of times um hey hey uh if you want to watch a cool video on how to program that sort of thing and uh there's one up on the internet you can find actually on our blog uh we did a little bit live coding in order to make that happen in a browser very cool um and this is just a reminder from earlier the goal of the architect is to minimize the amount of human resources needed to build a system. We talked about that, I think it might have been in the last episode, in that hardware is cheap, you know, processing is relatively cheap, but what's not cheap is the people needed to build the systems. And so you're trying to minimize the amount of overhead

and cognitive load to do this stuff. Yeah, we talked about this a little bit before um the least or last responsible moment something that gets me in trouble with my partner i'm trying to defer decisions until uh you want to you want to hit that sweet spot where you defer them until uh you know the last possible moment where you're not lose anything by that deferral. Um, but you also, uh, don't do it too early, man.

I can't wait until we talk about, about the use case that he talks about where he deferred the decision. We'll be getting to it in a minute. Um, but as we said, like we're not going to go into deep, all the stories in this particular chapter. I mean,

obviously you can get the book and do that. That's one of the things that you'll get when you get these books is some of the stuff that we're just not going to talk about that much. But what Joe alluded to a minute ago was the story of the architecture of this system that was really not even, I think Outlaw, we were talking about it earlier and the architecture sometimes is described as all the technologies and the stacks and the tears and all that. Right. Oh,

you're referring to a, he makes this comment about, you often hear people refer to, um, the, the UI layer and the server side, the app server and the database server is being a three-tiered architecture approach. And he's like, that's not architecture.

Right. That describes nothing about your architecture. Right. And when he goes into this section, one of the stories that he shares was this whole notion to where, you know, this company had an app that was like a desktop app and then they wanted to make it a web app. And so they hired a bunch of developers to come in and those developers were like, okay, here's what we're going to do, right? We're going to have this thing in order to scale out the servers. You know, somebody here might want to do that. We're going to have all these separate tiers within it. And then we're going to have all these microservices and we're

going to have all this and we're going to have all that. Right. And so they, when they built this thing, they built in a ton of overhead and just time for, I mean, think about that. Right. When, when just, when you think about just a typical application that connects to a database, just managing those two layers can be a bit of a pain, right? You have network latency, you have all that stuff. When you start adding in microservices, those services then need to know how to talk to other services

and then those need to be able to communicate on down the way, right? And now you have all these deployments and everything, it gets incredibly complicated, right? They end up only deploying this to a single machine. Right.

Yeah, they were convinced that the whole time even though they had broken out the architecture the way they did they were convinced that it was the right way and it stayed like that for a decade on running on one machine and i remember back down when i was doing confusion like that was a really common way of thinking about things like you know we always talk about n-tier n-tier applications we would have a database object we would have the orm which kind of you know, we always talk about end-tier applications. We would have a database object. We would have the ORM, which kind of, you know, mapped it and basically kind of duplicated, but that was generally generated. Then there was this, like, middle layer.

So now we've got the schema defined in the database. We've got a middle layer, like a data transfer object, a DTO. And then we've got some sort of front-end framework, like call it, you know, at the time I was doing, like, Flex or something, or some sort of, you know framework like call it um you know at the time i was doing like flex or something um or uh some sort of you know angular or whatever and that would have a an object that represented that dto as well and so if you wanted to add a column or add some sort of operation you were doing it in a minimum of three places and that just gets really hairy and annoying and you think about all that kind of chatter that happens across those boundary lines, like every single request, every single change to one of those objects meant was that like a total of six transactions marshalling in and out. That's pretty crazy. But now let's be fair.

We're not saying that that's not necessary in some points and not even saying that that's not a good practice. But we are saying that what you should do is look at the business use case, right? What is needed? These people needed to make a web app. Did it need to be able to scale to a billion users, right? Like my stuff needs to. But it's something to take into account. And don't try and make this thing way more than what it really needs to do.

So that's incredibly important. I remember going to meetups and being like, so what are you working on? And be like, well, I've got Oracle, I've got Java server pages, I've got ColdFusion in the mix, and we've got Flex on top. Like, yeah, but what are you building? Like, well, I haven't decided yet. It's either going to be some sort of hotel app or maybe arcade games. I don't know yet. None of us have ever done that yeah but that was copping that was like the default

like you know we thought we had like a kind of a cookie cutter pattern for doing those sort of things and the people that i talked about and or talked to and the people that were kind of involved in the scene that i was in like that's very much how we thought and talked about it it's like this is the one prescribed way to do things right we confused the the the tools and software as the architecture of what we were going to use or build and let's be fair here we're talking about good architecture in this good architecture should all like i feel like like it's a two way cut here. You should never let something like this get in the way of creating your minimal viable product, right? You should never let this get in the way of making a postponed decision of trying to get to market with something. On the flip side, you should also not let your, because if you're familiar with Angular and C Sharp and SQL Server, then chances are that's probably going to be the stack that you would go to because you're comfortable with it. On the flip side, architecture doesn't care about that.

It cares about how you group those things together. And so that really should be your focus, especially when you're trying to build something that's going to be more maintainable over time. So the term a cargo culting never heard of that. I think it goes back to, I don't know, some, some,

some war where, you know, some larger nation was kind of flying planes and landing it on islands. And the natives at the time kind of confused the activities of like the air traffic control people out there on the runway you know with the actual active landing a plane so they would kind of go out there after the plane would land and try to replicate the same motions to summon the plane so it's just that i think it's a common term and sometimes see in the blogosphere for kind of following rules blindly without really thinking about or not understanding the impact that you're supposed to be having with it.

So going along that lines of the minimal viable product, right, though, that was one of his personal stories where he said that they were writing this piece of software called Fitness. And they thought that they might want to use a database and they were planning on using MySQL. That was kind of what they already had in the back of their minds. Didn't know why they needed it. Didn't know if they were going to need it but they thought they would need a database as we always do for every you know most applications we ever write okay and um but they decided you know what instead of like actually taking the time and the hassle of spinning up my sequel getting all that schema set up or whatever permissions blah blah blah blah let's just defer that decision for now so we will mock that out

with interfaces and we'll create you know mocks for that database and when it gets to the point where we really need it then we'll worry about it kept Kept developing, year goes by, still no database actually in use during the development. Then it gets to the point where like, well, you know, we actually do need more data than what we can put in our mocks. So how about if we, we still don't really want to spin up a database. So that still sounds like a lot of work.

How about we just write this stuff to disk? So we'll make a new mock that will just save some stuff, read and write to a file on disk. They did memory first. Oh, it was memory first. Yeah, they did memory. Yeah. So I skipped ahead. But the point is that they kept deferring that decision until eventually they were like, you know what?

It turns out we don't ever need a real database. And then one of their customers, a client was like, Hey, I actually do want the database anyways. And so you're like, yeah, okay, fine. Sure. Just, you know, here's the interface you have to adhere to. And that client was able to write that database interface in a day and get them up and running. And that's all about, that's what it was all about. So like the idea is like, because the line had already been drawn in the sand about like, Hey, we're not going to introduce this dependency on this database, right? We're going to make a hard line here. And this interface is going to be how we're going to interact with whatever that storage mechanism is. We don't care what it is, but we're going to interact with whatever that storage mechanism is. We don't care what it

is, but we're going to draw a line that it has to go through this interface. Then by the time that they were ready to make a decision about like, okay, fine, let's add in a database. If you really want a database, then it didn't mean it didn't make for a lot of changes throughout the code. It didn't make for any other changes in it. Yeah, I think I'm reading this chapter, I felt really good about myself because I thought, you you know maybe i'm such a productive programmer because there's no way i would make it more than a week in any project any project without a database so i feel like i could do a year's worth of work because obviously i'm doing everything right i mean i've got little crappy 2d roguelikes that use SQLite databases.

So check this out. I want to back up just a little bit because we have listeners of all ranges of experience. And I want to describe a little bit more in detail what we're saying here with the contract thing, with the interface. So when they say that they wrote their app and they just had this interface for the data access, think about something like Git customers. They basically had an interface. We'll call it iGit customers or something, or Git customers could have been the method or whatever for whatever that data access was. But there had to be no implementation. It was literally just an interface. So whatever fulfilled it behind the scenes, they had a class, and we'll call it mock. I forget what they called it.

It was something like mock. Oh, man. What was it? Mock wiki page. Mock wiki page. And so literally, they were able to just plug in that concrete class now to fill in that, you know, get wiki pages call because it didn't matter what was there. We had this iWiki page data access and then get wiki pages was just one of the calls in there. So however you want to fill that thing in, you could do.

And so the reason they were able to keep iterating on that was because everything that was coded was coded to that contract. The interface was our number one episode, I think, IAS for interface. We talked about in that that you're coding to a contract. The contract says you have to have a method called get wiki pages. I don't care how you give it to me, but this is what has to fill it in. Right. And so they started with mock classes. Then they said, okay, well, that's not good enough.

Let's go to in memory classes. All right, fine. Let's plug that in. Okay. Well, that's not cutting it anymore. Let's put it to disk. Oh, somebody wants to do a database. Well, here's all the 10 methods you need to implement in your MySQL database.

You can do it. So I just wanted like, it's easy to say interface, but we mean truly an object-oriented interface, right? That is what we're talking about. You know, just the other day, I was working on a shared database with somebody and I had a JavaScript call going out and fetching data and they were changing the proc on me, right?

So one day it takes two minutes. That's annoying. The next day it's just broken. You know, I don't know if it's my code, their whatever so finally i'm like you know i'm just gonna take a sample result from here i'm gonna kind of pop it in here and i'm coming out the line that does the fetch right a better solution for that would have been to uh insert some sort of um indirection there which would let me kind of configure whether i wanted to be using test data or real data and whether that's at the server layer or the javascript you know I don't know I think maybe

if I had a better setup to begin with I would have more options there but it's just kind of nice to think that you're still solving these problems it's just a matter of like how explicit and how many lines you're temporarily commenting out right the really cool thing though about the way he approached that that example in the story was that by creating that interface first you're kind of creating the interface and you don't you don't know what you need until you decide you learn that you need it and you're like okay fine i'll add this to the interface and so then you add that to the interface and you keep going like that so basically that interface just becomes the minimal amount of stuff that you needed, right? Like I know I'm pretty bad.

I'm probably guilty about like maybe going the wrong way where like I'll create some class, but I want it to be, I want it to adhere to an interface. So I'll create the interface after I've created the class so that the class implements that interface. And I can just, you know, that my, my thinking is like, okay, fine everywhere else. I'll just use the interface instead of the class. So I'm trying to do the right thing, but I definitely didn't start with, oh, I'm going to write the interface first. Right. And you know, the interesting thing is when you do what they did, and this is kind of hard to step out of, especially for like guys like us who have been doing this whole, you

know, server client architecture for years where you almost always have a database at the heart of everything. Stuck in our ways. You kind of are. And when you think like that i mean i would imagine you guys probably go there too you start thinking about okay what's the crud states that we need to create right and so you automatically go there you say okay well i have a new table here okay i need to be able to update create delete read you know and so so your interface at that point you're

already thinking okay well i need to have all those methods. And then there's going to be a get by ID and a search by. And so you go way further than what you may even need to. I can take it a step further, too. Like, it might even be worse than that. Like, you already have this, like, toolbox of things that you know that you've done in the past. You're like, oh, well, I need one of those. Well, I've already written one of those. I know what one of those looks like. I'll just

reuse that thing again. And so you start cobbling together all of these pieces of a puzzle that might have a lot of functionality that you don't need. You don't know. But because you're not maybe like purpose building those interfaces for it, then you bring more baggage along with you and possibly more dependencies. Agreed. And you make it to where you're not drawing good lines around. And so like a good example that comes to mind is if we were to write any kind of application right now, and I was like,

Hey man, I need you to also, I need some good logging on that. Every one of us, you like, hey, man, I need you to also, I need some good logging on that. Every one of us here, we're going to think of log for net, maybe log for J for the Java guys. But that Apache project is by far and away are going to be our go-to, right? We don't think about maybe if we should abstract that and have our own facade around some kind of logging interface

that we could then plug in with whatever logging framework du jour we want to use, right? We just immediately think, oh, I'll bring in this thing. Yeah, it doesn't stick to think that like you're making potentially really like, not terrible,

but you're making bad decisions implicitly, meaning you don't even realize that you're making decisions still after the fact because you're so used to solving problems in the same way that that behavior just becomes implicit you just kind of type without even really realizing what you're doing and just implementing the same kind of bad patterns that you've been doing for years yeah and and let's be honest i mean us three guys, we have a lot of years experience between the three of us programming and we do a lot of things, right.

But reading a story like this, it sort of makes an aha moment go off in your head, right? Like the, they deferred the database decision for over a year. That's incredible. Like, like seriously, like when I read that, it actually made me smile because I was like, wait, what? And then it just made sense because typically like if I'm waiting on you to get something done, I'll mock up the data.

But it's like what Joe said a minute ago. Typically, when you do that, you'll just hard code it in place. And it's not like you're going to draw that line, right? You're not going to put that interface in the middle and say, okay, well, I'm just going to have it flip over to this mock class right now. But then when they get it done, then I'll just have flip over the other one. No, typically, you just uncommon out your code or you delete out that code that you had there, you recreate it. A better way is to put that interface in place, and then have it to where you inject

the code that you want at the time that it's being done and by the way it makes it way more testable right right so one thing that's kind of weird though is um that does kind of um just the idea of taking a year or more on a like a project before you actually launch it that kind of flies in the face and of all the kind of mvp type advice that you get for anything yeah um and so it's kind of weird like to think that yeah you can defer the database and that's really awesome while you're working on it but at the same time if you're living in a more agile world you're trying to get something out you know first month like heck you know uber probably launched in a year right well okay fair point so it was a different time at the time that that application was being

developed versus the way you know we try to get things out as soon as possible today but so let's not get caught on the amount of time that the decision was deferred but just the fact that the decision was deferred and that by deferring that decision for as long as possible it didn't hamper any other technology decisions down the road and actually made it more easily to adopt whatever you know uh underlying architecture they wanted to use for the database um without it impacting the rest of the application man i love that what you said it didn't hamper it but it actually made it easier to plug it in afterwards because they had a well-defined set of things that they know they needed to make that app,

that app run. Right. They had gone through the time. That's why I kind of was getting out with that interface, like going at it from the interface first, like you figure out what you actually need. And then after that point, you're like,

Oh, okay, well these are, I know everything that I need. That's it. Cool. Whatever I got to do to fill in these holes that are here. Right.

You fill in the blanks and we're good. Yep. It's awesome. And I tell you, it changes stuff in the database stinks like renaming tables or renaming columns is really annoying. So, so check it out.

That's actually, that's, that leads perfectly into the last bullet point that we have for this story, which is by deferring that decision on the database, they didn't have to worry about stuff like that. They didn't have to worry about schemas changing. They didn't have to worry about, you know they didn't have to worry about schemas changing they didn't have to worry about um you know latency and it no longer working yeah a proc they didn't have to worry about usernames and passwords changing they didn't have to worry about any of

that garbage that you typically have to worry about when you have another system set up if they wanted to change the schema in terms of what they needed in their app they just said okay well this interface now requires this field, right? And they could defer those decisions about the storage behind the scenes until after further down the road. Just overall, like that story was amazing to me. I loved it. I mean, if you think about it, it makes sense, right?

Like maintaining a database and a database server, that's a full-time job. It is. That's why there are people that have that job. Yep. Yep. It's not not a small task so which lines do you draw and when we got a nice little sense here you draw lines between things that matter and things that don't that's kind of a weird way of saying because

it's not necessarily that one thing matters one thing thing doesn't. Right. It's just that one, the details of one thing doesn't matter to the other. Right. Right. So they bring up that the GUI or the UI doesn't matter to the business rules. So what does that mean? It means that the business rules impact the UI, but the UI should have no impact on the business rules. So if that's the case, you draw a line there. That's the boundary.

That's an easy separating point. That's how it should be. That's how it should be, right? Not typically how it's done. And this one, I love this line right here. And I like that we'll get into it here in a minute. The notion that the database is tied to the business rules is misguided. That one, man, there have been so many arguments over the years

with so many people, and I've probably flipped flop sides on this so many times, but there are people that will be like, hey, the business rules should be in the database, right? And then you'll hear other people say, there's no way the business rules should be in the database. They should And then you'll hear other people say, there's no way the business rules should be in the database. They should be in some sort of middle tier, a business logic layer or something. He definitely makes for a strong argument in this section, whether he intended to or

not, but he definitely makes a strong case for your database is just about storage. Correct. And nothing else. Your business rules should be something else. And if you think about that, especially in a lot of today's architectures and applications and whatnot, where, you know, the whole idea is cloud and the ability to scale, you know, horizontally in order to get the performance and the expectations that you need for your users, right? Then that makes sense that, okay, well, yeah, if I can just throw more compute at it and all my business rules are in the

compute layer, then I can achieve those kinds of goals. But if I start putting, if I start mixing my storage with the business rules, then I'm setting myself up to where I'm going to be, you know. You're stuck. Yeah. And real quick, Joe, I know you're about to say something to again backing up for those that aren't familiar with some of these terms

scaling horizontally means you scale to more computers scaling vertically means you're stuck within the same computer right so yeah you throw more ram at the same computer or you upgrade to a faster ssd in the same computer Or a bigger processor, more cores or whatever. But eventually you tap out on what you can do when you're trying to vertically scale because you're limited by the hardware in a machine. Go ahead, Joe. I was just thinking, I flip-flop on the whole

whether the logic should be in stored procedures from the database or not. And I don't remember the first time we talked about it or the several times since like where i ended up but um every every time i argued for the procs if i ever did i don't even know but if i did or if someone else did they are generally arguing that the database is the core it's the lowest layer where your data lives and your logic grows from there so any changes that you make in those procs happen at the lowest level. And so your business logic is kind of wrapped around this molten core of your application.

What we're saying here is, hey, no, no, no. The database is not the core. That's the problem. The database exists on the outside. It's the outermost layer, just like the GUI, which is hard for me to internalize because it still feels to me like the database is the center maybe just because I'm kind of doing it wrong and thinking about it wrong well when you start to think about the database as being outside then suddenly it makes sense to

not have those procs or that logic anywhere near that database here's another one of the thoughts though that I think that we kind of fall victim of or you know that we're guilty of is that sometimes we'll put these business rule decisions into the data tier because we'll say things like well it's much more efficient for the database to do it than it is for me to take all of those rows of data take it into the compute layer you you know, sort it, whatever, and do whatever calculations, whatever, especially aggregate level, you know, functionality that you got to do on those. So we'll start making, you know, I guess, excuses for ourselves. I think that's what it is. As to like why we should keep things. And so it's, it's that type of thought, right? That type of thinking

to where we're like, okay i can excuse this one and then something else will come along and be like okay well i mean i excuse that first one so i can excuse the second one too right and and one thing leads to another and before you know it you do start finding yourself putting by by mistake by accident you find yourself putting more of your business logic into your database here that you didn't intend to and eventually we're going to get to a diagram in the book that shows kind of like what a clean architecture looks like and sure enough the database is on the outermost layer and when i um i accidentally read the wrong chapters today to prepare but anyway when i was reading about this i was like man this seems it just feels i get argument, but it just doesn't feel like what I'm used to.

And so, I actually went and Googled the onion architecture again. And sure enough, it's got the database on the outside too. But, I mean, if you would ask me in an interview about the onion architecture, I would have been telling you about the database right there at the center because that's how ingrained it is in my kind of muscle memory. So, what outlaw said and and this is the perfect reason why it happens that way think about this right like if let's just take an e-commerce app because it's really easy for us to think about products right it's easy for us to think about attributes on a product here's a perfect example you have you know this this database that has you know 10 000 widgets in it and you want to mark every one of those widgets with the color blue. Typically you'd say update, you know, products set color equal blue. And the reason you do that is because of what you said, the efficiency in, in people's mind, because you're dealing with that storage tier and that storage tier is central to everything else you do, that's where your mind goes.

But you can't really enforce business rules like that. And the other problem with that typically is SQL queries, SQL in and of itself is not a language that lends itself to modularity, right? I mean, we've seen this a lot like you can't you can't extend a query and say hey man so we want to update all these things but enforce the business logic here well it's also very difficult to do it conditionally right right let me just use the results of a store procedure good luck yeah yeah i mean it's it's not made for that it's made for operating on set base um amounts of data if we're talking about relational databases so so what outlaw said was

the reason we do it that way is because oh man if i just want to update every product in there it'll be real easy right it'll do it in place i could say update product set color equal blue done boom every every product in the database is done. But what if when you set it to blue, you also have to, I don't know, set some other attribute on it, right? Unless you wrote that in the proc or unless that crud operation that typically is a dumb crud operation, we'll call it, right? Because it's just going to basically say, update this attribute, unless that thing accounts for some business logic, which may be a bad thing. The other option is what we said is you now have to bring that data into your application, right?

So you have 10,000 products. And this is why typically people don't do it this way, is you have to bring those 10,000 products into your application, spin up objects for them to validate them. So if we're talking about the domain driven design, the whole point there was you have this aggregate so it can ensure the state of that object all the time, right? So now you spun these things up, you spun up 10,000 objects in memory in your application to ensure that you can update it properly just to send it back to the database and that feels inefficient and it probably is from an operation standpoint but from a data consistency and a data um uh what do they call it uh not they had a nice word for it for keeping it all when things were like correct an atomic type change but basically making sure that thing is in the proper state right

you can guarantee it that way if you just write an ad hoc update statements i guarantee you you will make a pro you'll you'll mess up at some point in your career this is one of those things though where like you you can you start to up at some point in your career. This is one of those things that were like, you, you can, you start to make that, that reasoning in your head. Cause you're like,

well, if I do it all in a, in a sort of procedure, I could wrap it in a transaction and then roll the transaction back all together at once inside of that same procedure. If I wanted to, which, okay.

Yeah. I mean, yes, technically you can do that. You could, but that doesn't mean that you couldn't have a transaction in your app layer too which again so you could do multiple sql statements you know if that's what you know if you're assuming you're doing sql uh and then commit the transaction all in your app layer yep you know it doesn't have to be in the proc you know i was thinking about this though from like there was um i don't remember how many episodes back it was

but we got into a conversation and i think it was around that during the um some of the domain driven design discussions and we were talking about like um if you were to take all of the scores of you know test scores of students and you were to try to percentile rank them all that, you know, that that was a reason why a reason why you'd want to do that in the database was because it'd be easier because of, you know, because you're trying to do that aggregate function across all that data, you don't want to return all that data back because you'd have millions of student records and things like that. But now, like reading, having read this, you know, read this you know this section i'm like oh man that was like a horrible thing to have said uh i wish we could go back and edit that out now but we'll leave it there but uh but yeah because

i mean it definitely goes back into the face of exactly what this is what this is kind of describing here right like that that was an example where it was like, okay, well, we'll use this excuse of putting that business logic into the database tier because we find it easier. It's easier. That's really what it boils down to. Now, don't get me wrong. If you transition that to the application layer, it's going to be chattier, right? It's going to be less efficient straight up yeah but can it be more consistent absolutely right you can enforce better business rules there and by the way if you ever need to change uh the the storage of where some of that stuff lives your application now still can work right whereas you know swapping out that that backend stuff may be more difficult.

You have a bunch of cobbled together store products or whatever. So I really, I wanted to hit on all that because there is a, you really have to do make a decision in your mind to say, okay, we know that we're going to take this hit, but it's worth it. You could also make us very specific service, like a color updater service, but it's worth it. You could also make a very specific service like a color updater service, but then that requires a deployment and all sorts of stuff that is really annoying and difficult too. But, but then again, though,

still your service might have the application logic in it as well. Right. So, I mean, if it's part of your business or whatever, you know, regardless, we're just saying there's a really good argument not to use your database for your business layer, right? Yeah. My specific service is definitely cheating. The integrity, I think was the words that we were looking for. That is the word looked up in our show notes. So yeah, the service is definitely cheating. All right. So this is where he actually gets into the lines that I thought were interesting. So what he's got is he's got business rules point to a database interface, right? And then from there, there's database access layer. That's also pointing to a database

interface. Now there's a boundary between the database interface and the database access layer. And then, so the database access is sort of sitting in between the database interface and then the actual database. So it's actually, what's going to go to the database, get the stuff out and then fulfill the contract to the database interface, right? That the business rules can use. Right. It's important to say that that database access is implementing that database interface. Right. Nothing should be directly reaching out to that database access layer if done right. Because basically what happens is, and I think one of you guys said it earlier, is the indirection. It gets injected in. Whatever is supposed to fulfill that contract would be supplied at the time that you're running the application.

And these arrows really confuse me. And there's a couple diagrams that do this. And for some reason, the arrows just point in the directions that I don't expect. So how I finally kind of justified it to myself is thinking about them as knows about lines. So business rules know about the database interface. And the database access knows about both the database interface, which exists in that business library, we'll call it, and the database access component also knows about the database.

And I'm apologizing right now because I know we don't have a great track record for talking about diagrams, but I hope you'll stick with us here. The idea is that, just like we talked about before, we're drawing lines about things that matter and the things that we don't care about. So the business rules care about that database interface,

database access cares about that database interface. The database interface doesn't care about either of those. Right. Things are totally independent. Right. It's also really, I want to, I want to make one point of clarification though,

because the way you were kind of describing it, Alan, it was almost walking this like without saying it, but it seemed like you were heavily implying a dependency injection, you know, kind of tool or framework. But that's not necessarily it doesn't it isn't we're not necessarily saying that something requires dependency injection if you were to i think it was back in like the clean code um conversations but you know if you were to think about like the injection the quote injection could be happening at like a parameter level right so if you were to pass in some parameter to a method um and and it only implemented an interface then you're kind of injecting quote injecting the real thing at runtime with whatever

whichever call to it you know is passing in something that meets that interface's uh implementation right so it doesn't necessarily have to imply um an ioc framework or something yeah because i was thinking about like the one of the examples i was thinking about was like let's say you wrote some dll and um you know if you pass in some interface that matches whatever the name of your database interface is, so IDatabase, and you don't care what gets passed into it, what the underlying thing is that gets passed into your DLL if you're going to make some call to that interface. That's not important to you. It's just that it meets that interface need. Yep. We've talked briefly about injection before, and there's a lot of confusion around it.

We probably should do an episode on it at some point in time. But, yeah, what you're saying is you can inject by passing the parameter in that like some some method requires an iRepository right you pass in the concrete version of that that repository that you want to use that's different than an inversion of control framework like uh like uh Castle Windsor or Ninject or something to where you can actually tell it, hey, anything that uses this I repository interface, swap in, you know, my database repository class. So they do similar things, but they don't have to be some sort of automatic at runtime type thing is what you're saying. Now, if you remember way back when we first started about clean architecture, the first chapter, he kind of did one of the first chapters.

Uncle Bob went through and talked about kind of like a little bit of a history about programming, talking about structured programming and object oriented programming. And if you remember, he actually said like the main benefit of kind of modern traditional languages is the interface because it enables these plugin architectures and it enables dependency inversion in a way that is easier than it's ever been before, easier and more correct than it's ever been before. And so the whole book is really built on that ever since, like dependency injection, dependency inversion principles have come up every single chapter.

Yep. Yeah, and this one was no different so what about io right so he he describes that um when we talk about the input and output of a system that most users and most developers they get confused about what the system is right most most of us when we start to talk about that next application or the application that we're currently working on, we start to think about it as like, well, the UI is what it is. That's the defining thing about how it should work and what it should do. Yeah, and I'm trying to think about what input and output means in this context. Are we talking about keyboard input and output? Are we talking about mouse? Sure, yeah.

Anything. Mouse, keyboard, the UI, the visual representation of it is how we often think about what the system is. If I were to ask you, if we were to like, hey, Joe, I got this great idea for a new iOS app, right? Well, you know, it wouldn't be uncommon that we would just focus on

discussions about like, yeah, so I've got this idea. This is the UI is going to look like this. We'll click here. We'll go over there. Then these things are going to happen. Rainbows are going to fly out. You know, unicorns are going to dance across the screen, right right it'll be all focused on ui but that's not what matters to the system it's it's not if you know it's the business rules that are going to matter yeah the the input so the funny thing is i always i thought about joe's rogue game right no user actually has to interact with that thing right i mean technically, that character could be moved around in bits in a program. You know, you could have something that made it move X amount of squares and run into enemies and do stuff.

You don't have to have inputs and outputs there. Like they're irrelevant. Like the UI could be completely useless because what matters is what happens when that character moves and encounters an enemy and what happens when that enemy attacks and all that kind of stuff. And that's what was really weird. As they said, the UI is basically irrelevant. Don't get me wrong. Are things not as useful without a UI? No, I mean, we're not, we're not trying to go that far, but really the overall intent of the system is what happens at that business layer,

almost always, really. So here's an example of this that came up in one of our recent conversations was, if you think about the UI not mattering, what if you were like, just totally rip out the UI as you know it. Right? What if you could do that? So, go to, go open up a browser, go to google.com and look at Google and do a search on Google.

Now open it up with links and do a search there. Is it, you just swapped out the entire interface and yet it works. Right? The core business functionality is still there you'd have to go to google.com in order to do a search and then they started um there was the

whole like toolbar revolution of like 2003 2005 when they had like the google toolbar or whatever else and just think about all the different ways if you got an android phone you can like say it you can type it you can search it you can you know cortana or whatever will go out and search for you there's so many different ways of of interacting with the same root system like there's not a search engine for each one of those right it's all using the same core system and that's what they say basically if it's programmed to an interface like if there's some sort of contract with whatever that that business layer is or whatever's doing the work the interface doesn't matter you can plug in whatever you want you want to do android um ui you want to do an ios ui let's be careful

the user interface doesn't matter the user interface doesn't matter the interface into the the inputs into that that this section gets a little weird with the use of interface as it relates to previous ones. Yeah, they're very careful to call out GUI in all the places where they talk about interfaces. But yeah, it's pretty interesting if you think about it. Like strip it away. It doesn't matter. However you can get the data into it is what matters. Well, I don't want to say it doesn't matter.

Because just like we said, to the users, it's the most important thing. data into it is what matters well i don't want to say it doesn't matter because like you know just like they said like to the users it's the most important thing it's just we want to insulate it from the rest of our system because our system doesn't care about right the user interface right right so this the ui doesn't matter to the system it could run with or without that GUI on top of it. Yep. Unless you're talking to a visual designer, in which case that's going to be the most important thing. So I guess, you know, keep things relative to, you know. The customer's not going to do it through a bash shell? Come on, man.

I mean, they could. They could. So plug-in architecture, this is kind of what i mentioned before um that you know what we said like this is kind of like the whole this is the shebang this is what we're talking about this is what we want this is the whole point of working with these uh you know the the big static languages and ids and the tools that we are obviously that's not all programmed by any stretch of means but for the most part i think uh that's kind of what we're talking about. Like this book isn't geared for the person who writes

five lines of PowerShell, you know, at a time. It's just a different sort of thing. But business rules should be separate from pieces that are considered pluggable or should be considered pluggable. UI in the database. And we actually got into

a really cool example here talking about ReSharper and Visual Studio, which I'm very passionate about Visual Studio and ReSharper. So it was kind of cool to have that example. I was excited. I was like, hey, I know those guys. Right. I use that. And what they said was kind of, it's kind of scary if you think about it from a perspective which I don't think JetBrains cares that much. They got other products that are, you know, help be their bread and butter.

But if, what was it? Oh, God. ReSharper. If it changes, Visual Studio doesn't care. It's just, it's something that's plugged into Visual Studio. If Visual Studio changes, ReSharper cares, right? Like it could be completely irrelevant at some point in time. So it's the pluggable.

It's the thing that can be added. Yeah, absolutely. And yeah, it's scary to think that Microsoft could potentially make such a big change and really mess up life for them. But I think that Microsoft has a strong incentive to not mess up their partners. And so I've actually been reading, oh God, Satya Nadella's, I hope I pronounced it right, Hit Refresh. I've been reading the book and it talks about a lot how Microsoft's relationship with partners has changed and how it used to not be so great.

It used to be kind of more competitive. Anyway, that's kind of an interesting side note. Interesting book. Should hit me up if you are reading it too. Oh, that's cool. I didn't even know you had one out hey one note on the previous thing with the business rule should be separate pieces that could be pluggable they pointed out and I think it's important to know just because something's pluggable doesn't necessarily mean it's going to be easy right right so you want to strive towards making it pluggable, but that doesn't mean that you're just going to be able to swap it out in 30 minutes, right? Be realistic. Yeah, but we want to do that, though, because the idea is we want some of the modules to be immune to changes in other components.

So it might not be easy, but if we can go through that ordeal, right, it'll pay itself off in dividends later. And this is a kind of different kind of plugin, but I keep seeing more and more things that have web hooks. You know, you basically have some sort of thing you can paste. And so when an action happens in your system, you know, we'll go ahead and call whatever web hooks be out at the, you out at the various pieces, just like a template method. And it's another example where like, if what you do on your end, the action, the stuff that you do with the information I pass to you changes, I don't care. I just, you know, I just call your URL at the appropriate time. Now, if I decide to stop calling that webhook or change when it happens or change the data that gets passed to it, then you've got a problem. Yep. One of the things that they point out here is your business rules should not break due to a change in the UI or even schema changes in the database. And this is where things get weird for us guys, right? Because we're like, oh, wait a second, you change

the database, you change everything. And if you're doing that, that's probably the wrong way to approach it, right? You should be looking at your business layer to figure out what sort of interfaces it's programmed to. And then whatever needs to happen from that point should fan out. Or just don't change the database. Don't change the database. Right. This is where, you know, I'm really finding a great marriage between this book and the Domain Driven Design. Yes.

And especially, there was a Pluralsight course that I think we talked about at the time. I want to say it was Julie Lerman and Scott Smith. Steve Smith. Steve Smith. Steve Smith, yep. They gave that and they gave a great presentation and explanation of using the domain-driven design approach from scratch. But the key to that, though, is that for anyone who doesn't know Julie Lerman, I mean, she is like extremely knowledgeable about entity framework framework highly involved in the development of it uh lots of pluralsight courses about any framework um so the challenge there was like

to have a to take the domain driven design approach and we talked about in the last episode about not letting the entity framework um components leak out into the rest of the application, right? And so it wasn't, hey, don't use entity framework, but there was definitely like, hey, well, there should be like a line in the sand as to like who uses the entity framework components and who doesn't, right? And so even going through here with like not letting the schema changes break your application, right? If elsewhere in your application, if you're not using, if you're using domain models that aren't necessarily, you know, that closely tied to any framework, then it's not going

to, it's not, yes, the schema changed, then it's not going to, it's not, yes, the schema changed, but it's not going to break the logic of those, those components necessary. You might need to go back and do some refactoring, but, uh, you know, things will still compile, for example, like, you know, I mean, that's, that's what this is all about, right? He's like trying to draw, like, where do you find, how do you draw the lines between the things that matter and the things that don't and as far as your domain is concerned as far as your business logic is concerned it doesn't care about what the underlying storage technology is so it doesn't need to know hey this is an entity framework object and you can still do all these

queries right that you might not realize were happening right and don't forget that steve smith is still doing the weekly dev tips podcast so great way to get like little short five minute tips every week he's full of great advice we've referenced him tons of times yeah he's done some excellent excellent courses on plural site another thing that we have here is by arranging our modules into the plugin architecture, we basically create firewalls across the components, right?

Like you create these safe entry and exit points. Yeah, I think that's a great term for it. I always think about, you remember back to science days, we talked about cell walls and cell membranes that will only let certain protein combinations or whatever, like through the walls.

Same idea as the fireball, I suppose. But I just like the idea of like kind of, you know, using that in conjunction with like the interface separation principle or segregation principle in order to kind of cleanly define your lines. And it doesn't even matter what you pass because this is all that's getting through.

And we do refer to drawing those uh along the line where there's an axis of change and i know this term came up uh in an earlier chapter but i don't remember exactly what it was is it italics anyone remember no i couldn't remember either i was thinking at first i was thinking of it um similar to the uh main sequence when we had the conversation about the the zone of pain zone of uselessness um but i don't think that was right though but yeah so we want to draw the lines where there is the access of change so basically the things that are going to change and at different rates and for different reasons we want boundaries between those things yep and yeah i've actually found people on stack overflow asking what the axis of changes

and nobody knows nobody knows hey who put this next one in here uh oh hey uh that was me uh so remember from episode uh 68 uh i already brought this up uh you did the primary benefit of oo is dependency injection so we can build these plugin architectures so that's kind of the whole point if you're doing something in c sharp or java and you're not leveraging um interfaces and these kind of cool dependency inversion principles, then why are you using

Java or C Sharp? Cool. I have an answer to that. C Sharp is awesome. It's got great syntax and power. True that. Just wrapping this one up real quick. We just talked about drawing the lines of

partitioning the system um making sure that you're pointing in the right direction towards those dependencies and uh this is an application of the dependency inversion principle and the stable abstractions principle and so with that it's time for us to beg for reviews again and for you guys to take the time to do so. If you haven't already, again, we love reading them. We super appreciate the time that you guys take to do it. It's near and dear to our hearts and it helps other people see that, you know, there's something that they might want to see over here or listen to or whatever. So, you know, please do if you haven't already. Head to codingblocks.net slash review and take the time to leave us a few words up there and, you know, put a smile on our face.

And thank you. And with that, it's time for my favorite portion of the show. Survey says... Ding! All right, so last episode, we asked the totally awesome and legit question is it okay for a site to open links in a new tab or window for you and your choices are joe has opinions your your incorrect choices are, first, absolutely, no one's got time for holding extra keys.

Or, yeah, yeah, for holding extra keys. Second, yes, but only for links to external sites. Next, yes, but the site better warn me first. And your correct answer. Nope. No, no, nope. Never. No. That's what control or command click is for. All right. So I think Alan, you went first. So let's go, Joe. Would you like to tell me the correct answer and maybe guess a percentage on it? With the correct answer or what I think the vote said? The vote. Let's go with that first.

Clearly, they would have picked the correct one, right? No, I think the vote is going to say yes for links to external sites because I think we've got a lot of web dev listeners. And that was like the stock advice for many years it's not the correct answer though what's your percentage nope no never oh my percentage sorry yeah your percentage up the head i'm gonna say um 36 percent oh god 36 okay i'm going with the same answer, and I'm going to go with 1%. 1%. By Price is Right rules. Price is Right rules.

There you go. Because I also read many a web dev book back in the day, and that was the de facto way to do things. Yeah, man. This isn't the 90s anymore, man. It doesn't matter, man. We're all stuck. We're old. Oh, God. I hate old. Oh, God.

I hate that. But I honestly, no, no, never. I like that one. This whole thing about warn me first, there's nobody on this planet that said yes to that. I can't believe that. That irks me any time I see it. Let me go ahead and get through the answers, and then we will discuss. Man.

So, sadly, I don't know what our audience is thinking. What are you guys thinking? 46% of the vote, yes, but only for links to external sites. So, our audience is saying that if there is a link on, like say, coding blocks, that they want it to automatically open up a new tab or a new window. If they're on Reddit and they click on a new link, they automatically want it to open up a new tab or link. If they're on Facebook or Twitter or whatever it is, they want it to automatically open up on you. That to me is ridiculous.

I hate that. By the way, I would venture to say for things like e-commerce sites and all that, that is still the norm because they don't want you to navigate away from where they want you to buy something. I'd venture to say that that is actually still the case. I'm trying to think of an example of what that looks like. Right. No marketing manager is ever going to say, hey, navigate from the site.

They want you to go to the other site. Well, first of all, they don't even want you to go to the other site. But if you do go to the other site, eventually when you close that tab, we want to show you that product that you're still looking at, right? Right. They want those hooks in you. If it wasn't against web rules, they'd still iframe those external sites. I'm trying to think of an example, though, of an e-commerce site that would open up a site to something external.

Facebook shares all kinds of things, man. Facebook's not an e-commerce site. No, no, no. I mean, if you're on a site that's like, hey, pin this, or Facebook like it or something, they're not going to go to an external site. They're going to, right? Yeah, I'm just trying to look on Amazon to not going to go to an external site. They're going to, right? Yeah, I'm just trying to look on Amazon to even find a link to an external site. Yeah, that's what, that Amazon was what I was trying to think of. Like if you were to go to there.

What about, what about a site, like let's say car parts and they have a link to the manufacturer or something like that. Like, I mean, I'm making things up right now, but potentially something like that, right? They're, they still not going to want them to leave that site. And, and let's, let's even go a step further. Even if you're not an e-commerce site and you're a blog and you want somebody to click something for an affiliate link or something, typically, are you going to want them to go away from your site and potentially click on a link on somebody else's side? you know what i'm saying like it's the whole owning the yeah i just view it as like don't make the decision for

me i if i'm a big boy if i want it if i want to open up a new tab i i know how to i know how to do that i can control click myself or right click and say open up you know i don't need you to do it for me so yeah like i i really hate that and by the way there were like 10 of the vote was warn me first oh man i that i don't like extra clicks man it drives me crazy yeah which which that one was i yeah i i didn't really i think we put that one in as an afterthought i didn't expect it but I was definitely thinking of cases like, you see that one more often with like financial institutions or something like that. Yeah, you're about to leave this site. Hey, this link that you clicked on is not to us, so we don't want to be held liable. Right.

Right. So I get it in those cases. I hate it. But that one, I guess I get because they're trying to like not be held responsible for anything in that regard. So to wrap this one up, how far in second place was the no-nope ever? Because it had to have been second. It was. It was 34%. Those were definitely the two strongest. So almost half and then a third. Okay. That's a vast majority

of it that kind of makes sense but what brought this up so like you know if everyone who's listening is like why would you that was a stupid question so there was some post i don't remember what post it was but um alan had gone in and added in the portion of it that had a bunch of affiliate links, and he set them all to open up in a new target. Target blanks, man. Yeah, and I was like, wait, no, that's awful. Why would we ever do that? Never, ever do. So I went behind him.

I'm like, delete, delete, delete, delete, delete. Because I'm like, no, we're all grown adults. We can open up our own tabs and i was like please never do that again what about mobile yeah does mobile change things no mobile works the same yeah you know what i actually appreciate it when it opens in a new tab for me on mobile because i hate long holding on something to pop up the you know what i'm saying like you don't have a control button to click all right you have to long press something touch you have to long press it or force touch it and then wait for the menu to come up and then taps i hate that

i'd rather just click it and it open up a new tab yeah i don't know man i i i could see mobile like sometimes i'm researching you know i'm like you, why is my dog's poo green or something, you know, on my phone while I'm walking around. Now, you know, I'll click a link, click a link, click a link because I want to keep researching. But it is nice sometimes to be able to not lose that original page. And that's kind of starting point for the research. Imagine if. Grass, by the way. Eating grass.

Yes. Imagine if next time you went to Google, if every time you clicked on something in Google, it was just like, oh, well, I'll open up in a new window for you. Because I want you to keep your search results nearby. Well, they kind of do it anyways. You click any link from Google and it's going through a redirect that then takes you to the page anyway. So they've already captured you. But yeah, I get your point. But yeah, but I mean, it's not going into a new tab or window.

Yeah. So. All right. So people agreed with my target blank, I'm just saying. Yeah, gosh. Audience. Awesome. You let me down.

You were supposed to say no, nope, never. You were supposed to have mine in Jay-Z's back, but no, you didn't. That's awesome. Yeah, never knew. Never knew. So today's survey, what's the oldest code that you actively work with? The oldest code that you actively work with. Not something in the closet that's around that you saw once but actively like you know regular day-to-day

right your regular day-to-day stuff and other options we're gonna have for you are less than one year green as can be lucky one to three years and it was their life before angular i threw that in as a little joke just kind of think like, you know, three years ago, Angular was still around, but not much more than that. Yeah. Three to 10 years back. Now, this is back when JavaScript only ran in the browser. Node.js wasn't out, you know, Rhino or some of the other implementations were just kind of, you know, experiments at the time.

10 to 15 years old. Now, this is starting to get interesting. This is pre-JQuery. This is getting to be like pre-iPhone, right? This is like back when you maybe had a regular cell phone and maybe not. We had to get our own elements by ID back then. You had the Motorola Razr.

Yes, sir. I love that phone. And you were Skyline. And then the last option here, we're going to have more than 15 years old, which is really impressive because that's predating Stack Overflow. So you know that code has some bad patterns in it. I'm kind of thinking I messed up my numbers because I think Stack Overflow is only a little bit more than 10 years old. So anyway, if you're doing code that's 15 years old, it was definitely pre-Stack Overflow.

This one will be interesting. Yeah, I really want to know. I don't know what to expect here. I guess, do you think it would depend on the size of the company? Do you think there's going to be any kind of correlation there? Yeah, definitely. Which way do you think the correlation is going to go? Bigger correlation there yeah definitely yeah what which way do you think the correlation is going to go bigger the company older the code yep if you're thinking like it's

gonna based on past surveys i'm gonna say that this survey is gonna skew to younger code bases so i'm gonna say three to ten years with the heavy on the three. Well, you're thinking like, when you say big, you're thinking like a Microsoft, you know, and you're working on Office or... Even more than 50. Oh, 50 employees. Yeah. Yeah.

We will see. A quick question for all you trailblazing freelancers. If you could reclaim up to 192 hours a year of your precious time, would you? We will see. A quick question for all you trailblazing freelancers. If you could reclaim up to 192 hours a year of your precious time, would you? Our friends at FreshBooks who make ridiculously easy to use cloud accounting software for freelancers are the architects behind this question. And for good reason. By simplifying tasks like invoicing, tracking expenses, and getting paid online, FreshBooks has drastically reduced the time it takes for over 5 million people to deal with their paperwork. If that's not enough incentive, the FreshBooks platform has been rebuilt from the ground up. They've taken simplicity and

speed to an entirely new level and added powerful new features. And if you're doing the math, 192 hours works out to two working days per month. When tax time does roll around, you'll find tidy summaries of your expense reports, your invoice details, your sales tax summaries, and a lot more. If you're a freelancer listening to this and not yet using FreshBooks, now would be the time to try it. FreshBooks is offering a 30-day unrestricted free trial to our listeners. To claim it, just go to freshbooks.com slash coding and enter the code coding space blocks

in the how did you hear about us section. All right, so now it's time to talk about boundary crossing. We never do this. So this basically occurs when a function reaches out from one component across that boundary line that we drew into another component. And this is not an exception, right? We're talking about like the normal use case where, you know, the UI is calling the server or server is calling the database or something like that, right? Yeah, this is what we want. Yeah. I mean,

this is, this is the intended way things should work. And the trick here is the, the key part is managing the source code dependencies. And yeah, that's, that's what they say. Why the source code?

And basically what they're saying is when, depending on what your dependencies look like, when you change one piece of source code, then it might trickle all the way up the line or down the line or however you want to look at it. Right. And so that's why you want these boundaries to be well-defined so that you don't have this whole chain of, of changes that have to happen. Yeah. And going back to the firewall comment, there was a great line where it was talking about like, you know, the building and maintaining of these firewalls to protect against these changes is the whole purpose and the whole intent of the boundaries. Right. So if we think about, you know, managing those boundaries the same way we would manage the code and the compilation and to try to prevent one change from having to force a recompile on another then that's a way of thinking about these lines yeah but what about the dreaded monolith and they bring this up because the point there is that just because we may end up with one

say executable or one jar one whatever we have those boundaries. They're just not as visible. Well, yeah, he says that this is the simplest of the architectural boundaries, right? So, yes, you still have the boundaries, but these are your source code boundaries, you know, at the component levels. Yeah, because they even say, right, within the monolith itself, just because it's all one application doesn't mean there aren't those lines. So even your statically linked libraries, right, those are your boundary lines because those are the things that can be swapped in, whether it's a jar or DLL or whatever. So, you know, and again, they say that the interfaces are important. It's the same concepts. It's just it's all bundled together do you think it's harder to maintain good practice when it's bundled together like

this because it requires more discipline i personally i don't think so i do you do really i absolutely think so because when you when you my thinking is that if if you have everything grouped together like let's say you're in a in a Visual Studio kind of C-sharp world, right? You got one solution file, some large number of projects, right? If you're not careful about putting good names on what those projects are so that the names alone can communicate what its intent and boundary is and instead you fall victim of creating like this is my helper's project and this is my code library project and my utility project then those become dumping grounds of well because you didn't really know what to call it, you also don't know what should and

shouldn't be in there. And so it becomes a very big mess. Okay. Yeah, I agree then. I take back my previous statement. So do you think there are any programmers on a, say like a medium to large size team or even a small team that would argue that architecture isn't, doesn't matter. Architecture doesn't matter. Doesn't matter. It's a waste of time to talk about or think about. Wait, would,

would, would, is there a developer that would say that architecture doesn't matter? Yes. On a small, medium, large team. Yes. I would say that,

I mean, I've even had the conversation with people where they're like, I don't understand the point of an interface. Right. And, and so that almost, especially in the context of this book, but in a lot of conversations we've had, that almost right there says you don't care about it, right? Like you just want to tighten the couple all the way down because you know that this is

going to use this, it's going to use this, and so why not just make it easy? Well, I don't know if that's fair. I mean, just because somebody doesn't understand its use and its purpose and why they should use it doesn't necessarily mean that they don't care. They just don't know. Ignorance is bliss, right? Fair, fair. Yeah, but I was just kind of thinking like,

I don't think there's that many people that would explicitly say, I don't care about software architecture, just let me do my job. But I do feel like there are a lot of people that say, I don't care about learning interfaces. I do think dependency inversion is a waste of time. I do think it's okay to have these kind of like, you know, we'll call them like sloppy lines between things, or we'll say that the lines don't matter, encapsulation don't matter. Like I feel those are common

sentiments. So it's kind of weird to me to say, like, you know, these two kind of mean the same thing. So if you say I don't care about clean lines, I don't care about interfaces, I don't care about dependency inversion, you're kind of saying by our definition of the word, you don't care about architecture. And I think maybe that maybe there are people out there who don't realize kind of what they're advocating against, because they're not thinking of those things as architecture. And then I'm wondering what they think architecture is. But you know what? So in fairness to what Mike said, I agree. Ignorance is almost the excuse there, the answer there. I'm fine with that. But there are people, let's be completely clear. There are people that don't care about the architecture at all. They have a need to make

something happen and they'll just do it however they need to do it. And they don't care what the code looks like. They don't care if it's efficient. They just know that they got the job done and they're moving on. Right. Yeah. That, that ticket's done. And if you decide that you want to refactor it, move it somewhere else, then you have at it, but that's all on you. Right. So, so I think there is, I think there are plenty of people out there that don't care about architecture in, in to a certain degree, I'm sort of okay with that only because it's the same type thing as you need people that are willing to just do jobs, right? That don't overthink or underthink something. They just kind of, they're task runners, right? Like if you have somebody that

works in an office that stacks shelves and that's what you need them to do. Right. And so maybe that's fine. Um, I think that can be detrimental if you have too many of those people that don't care about it, but there are some people that just work really well as task runners. Hey, I need this thing knocked out, go do it. Right. But it seems like those are the kind of people though that you need to give it's like you need to give them more guides you need to give them more examples of like hey this is the pattern that we're following so as long as their status quo adheres to the to good patterns that you've already put in place then yes i understand where you're coming from by saying like hey you just need some task runners and that's fine. But when you don't have, if you don't have good patterns in place or you're trying to migrate to better patterns, then that type of person can get in your way.

Yeah, true. But I would also argue, too, that people that are all trying to go the other direction and make everything way, way, way, way better, you can get a lot of collision there as well. So, I mean, it's answering your question. Yes, I think there are people that really don't care. They really just they could give a hoot about it, right? Like just, hey, what do you need done? I'll do it. And do you think that having good architecture can kind of supplant those people or maybe make it easier for them to do the right things

because doing the right, you know, getting their day job done is easy because things have clean lines and there's a clear pattern for them to follow. And so it's almost harder for them to deviate from it. Absolutely, I think it is. But I still, it's easier for them to deviate from it. Absolutely. I think it is totally, but I still, it's easier for them to follow the status quo,

but they could still fall victim of, Hey, I'm going to create this utility class. I'm going to put it into this, into the wrong place. Just because out of laziness, I don't feel like putting it that for me to get to that other package, to put it in that

one would mean that I'd also have to like republish the package and, you know, make a new version publicly available or whatever, whether that be like a, an NPM module or a NuGet package or whatever, you know, and, and I don't feel like doing that. I need this functionality right here. So I'm going to put it in here. So that still happens. But yeah, that's where code reviews come in hand, right? I will say, though, this is also where tooling can make a big difference in how effective you can make teams like that. Because honestly, let's take NuGet for an example. NuGet can be a freaking pain in the butt, right?

If you want to package up a project to push it back up, especially if you don't know all the nuances, it can be a real pain in the butt, right? Because you push it up, oh, there's an error. Okay, now I need to change something else. I need the debug symbols. I need all that. Oh man, I'm going to have to push up another one. So I'm going to have to go back to the command line and do all that. It makes it a pain, right? So trying to do things right can be problematic, which by the way, I have a real gripe with a particular thing that Microsoft's done. So in general, I love VSTS just absolutely love it. Right? Like if you've never, if you've worked in GitHub a lot and you've never actually messed in visual studio team

services online, like I love it. It's, it's worth checking out if you want to put up a repo or whatever. Here's where I have a real frustration. So there is a package, a plugin that you can buy from Microsoft for auto packaging Nuggets for you. So you set up a project or whatever, and you can tell it, hey, I want this project to be auto Nuggetized so that you can, and you can even do pre-release versions. It's got all kinds of settings. You got to pay for it. Like to me, that's, that's dirty only from the perspective that like they have all these tools up there that make things better, but then that one's really useful. And it's not just, you have to pay 50 bucks for it. Like it's paid on on a on a number of project

things that use it like come on man get that thing and and it's got a horrible rating on the on the visual studio marketplace for that reason people are like are you serious like really what why are you charging per and they're like well we looked at all the places so something that's like two command line. Yeah. Like seriously, it's kind of ridiculous. Don't get me wrong. I don't want to downplay the fact that somebody built that thing and put it

out there, but Microsoft you're, you know, you've created this awesome world where people can, can program it and put these things. Come on, man. He's he's the way don't, don't get in the way of progress, especially for something like that. That's kind of ridiculous. But at any rate, going back to way of progress, especially for something like that. That's kind of ridiculous. But at any rate, going back to the whole thing, I digress on that.

I do think that, yes, if somebody enforces a good architecture, it can enable those people, just like you said. But I also think that tooling can play a huge role in enabling that to be easier, right? Yeah, I think static analysis will call you on your crap oh yeah that's the kind of tooling i was about to ask about it are we talking about static analysis or did you have something else in mind like build pipeline or something both both static analysis one right like it calls you to the floor right where a pull request glosses over that because you can't get the context sometimes static analysis call it out but but even just that that build thing that i was talking about i mean the static analysis may call it out it might not

necessarily like you know in that case that i an example that i made up where it's like okay i'm gonna create this utility class and i'm too lazy to put it where it really belongs so i'm gonna like pollute you know my logging framework with a i don't know, an email client or something just because I'm lazy, then it may not call it out in the zone of uselessness or whatever. But so I think it's a combination of things, but like the whole thing that you're talking about, you have this big mono solution that has everything in it and people just dump it. If you have tooling set up that makes it easy for those various projects to be bundled up and just included in your project,

all of a sudden people will start adhering to it because they don't have to go out of their way to make something work the way that they expect it to. I mean, we've talked about it time and time again, and as comical as it is, it is so true, though, that if you're going to have these monolithic applications and repositories that the naming becomes so important to be able to express what that intent is right in taking back like you know one of the core uh things that you know was

at least a takeaway from for me me from clean code, um, you know, like making sure to name things, you know, expressive, uh, give, give everything an expressive name so that like right away, you knew immediately what that function was going to do. You know what that class is supposed to be for, uh, those types of things. Right. And it really, like, if you think about it at the, at the source code code level for your projects and how you're going to break up those modules, you have to give those things meaningful names. Otherwise, you risk that they're going to get polluted. I'll share one that I had done initially with good intents. I had created a patterns

project right and and i was talking to outlaw and a couple other co-workers at one point and i was like man this is going to become a dumping ground right like and i think even maybe you were the one that suggested hey can we rename this thing and i was like you know what this should be more targeted right so it made me twitch a little bit every time i looked at it yeah because the thing is it only had a pattern in it at the time and then you know we got to talking about hey let's clean up some of this stuff and let's make it more expressive and more targeted and i was like you know what there's a good place to start let me let me take this thing out make it exactly what it is name it that way so it's no longer this generic place where people can just add whatever they want so so just to kind of wrap up this section here um you know one of the benefits of the monolithic uh application or system is that the communications within that

application are going to be fast and inexpensive right you're still in the same process space same memory space so it's just function calls within the same space yep all right so on to deployment components um the simplest representation of an architectural boundary is deployed application so dll jar gem and so that's what we're meaning whenever we say component when we're talking about the clean architecture and the components delivered as a binary as an example of deployment level decoupling we talked about this last episode a little bit and this is in contrast to the source control are basically just trying to kind of keep those lines clean in the actual code and it's similar to a monolith and the only real difference is that rather than a single executable,

it's a bunch of dynamic libraries. Do you remember back in the day, it was very common for just about any application to come with a bin directory that had all those DLLs in there? I don't know why they didn't bundle them into one single file. I'm sure we had the technology

to make things into a single file. Yeah, I don't know either, unless they had plans for being able to make things into a single file. Yeah. I don't know either, unless they had plans for being able to hot swap them at some point. I don't know. Yeah. I don't know. I mean,

like I definitely, I'm used to deploying things as multiple libraries, so I can hot swap them or because I'm, you know, just doing weird stuff or being lazy. But, uh, and single executable is nice.

Like if a user is actually going to see it and it makes things like uninstall easier, I suppose. Yeah. Yeah. I don't know. Um, it's funny.

The next section they brought in were threads and this one felt kind of odd only because it, it sort of doesn't mix in with the rest of the things that they talk about here. And, and the reason, yeah, I mean,

the reason is, is really it's, they don't create boundaries. It's just running code in scheduled and organized ways. Right. Yeah. Yeah. I thought it was interesting to talk about threads.

I mean, mainly because they mentioned how you, you know, a thread can run across kind of multiple or multiple DLLs or multiple components can be kind of executed on the same thread. So I thought it was kind of interesting to think about it, but yeah, it didn't seem like kind of an interesting departure. Same with the next one, local processes, which is just basically stronger boundary. Yeah. I mean, going back to the thread one though, for example, I wonder, so there's a Udacity course that a friend and I were going through. And

one of the things that it goes over was the boss worker pattern for threading, right? And, you know, at first glance with this section on threads, it's right, you're right. It was really short. And I think he was just trying to make a the point that like hey threads are not necessarily boundaries don't think of them as boundaries but it did kind of make me question like well maybe he was coming at that from the point of view of like you know part of the boss worker pattern when you start talking about variants of that pattern gets into um the specialized threads right because if Because if you, if you think about, um, so just a little background, take a step back about what the boss worker pattern is, is that, um, let's say that you have one main thread that takes in all incoming requests, and then he will then spend that off to

one of a collection of worker threads. Right., right? And so in that kind of application, you're all about trying to keep the boss as efficient as possible. But if the boss has to like hand it off to the worker thread, then there's a period of time where the boss has to wait for the worker to acknowledge it, to accept it, and then take receipt of, yep, I got it. Cool. We're good from here. And then the boss can move on. Right? So then there's like, well, how do you make that boss worker pattern more efficient? You know, maybe the boss just dumps it into a queue and then the workers can all read from the queue. And at that point, you're treating all of those workers, those worker threads as the same. Every one of them does the same, is capable of doing the same things. There's no specialization, there's no localization, things like that. And, you know,

so the next variant of that would be like, okay, well, what if you do have specialized threads, right? So because there's like a, I forget, there's some kind of computing law where it's like, if you've done something, if you just recently did something, you're more likely to repeat it. And looping is a prime example of that, right? I forget, there's probably a better name for it, but I don't remember it. But, you know, the idea being that, like, if you have these specialized threads, right, then you can have better quality of service type capabilities built into it um you know and and that localization that you know certain threads know how to do some things very well right so maybe i don't know but maybe that's where he wanted to go ahead and make

this distinction like if that's you're thinking of like the specialized threads kind of scenario like let's just go ahead and nip that idea in the bud. That is not an architectural boundary. That is not a line. Stop. That makes sense. The first part was kind of talking about where to put boundaries. And the second part, the part we're talking about now,

is just kind of like the different kind of boundaries you can have. So we're talking about monolith know, monoliths that, you know, don't really have much. We've got deploying things in static or dynamic linking. Now we're talking about threads and then we go on to local processes and then finally services. So just kind of, I, you know, it just seems so weird to hop to threads to me because it's just such a low

level concept compared to everything else we've been talking about. So I almost expected like a, a paragraph or something to kind of like ease me into it rather than just going from a static linking to threads. Yeah. Which are completely not related. Well, I mean,

I guess in the monolithic it was not maybe called out, but you know, I guess you could assume after the fact that he was referring to like a single threaded application in that particular scenario. I think so, because he was talking about everything ran within the same physical processor, whether it was a multi-core or whatever, and then in the same memory space and all that kind of stuff. So yeah, I think that's kind of what the goal was. And with threads, there are more processes that run independently. But there's no boundaries, right?

It could be running any portion of an application. It doesn't really matter. Next step up from that is basically local processes, which I mentioned before as basically a stronger boundary. So they typically communicate with sockets. So we're talking about processes on the same machine here. They run in separate memory spaces. So these are things that typically can be broken off to services or something um they're kind of like a large

component but it's just like kind of one step up from the thread i you know reading that part made me think of the um the 12 factor app again i know we've referenced that um section before so if you haven't already heard that series we did go go over the 12-factor app. But that was one of the ideas here was that you could just have your process spit out its output to standard out. And if something else wanted to grab it, then it could just take the input from standard in, do whatever it needed, spit it back out, standard out, things like that. And this one was, this is where things get interesting because this is where we start talking about performance of these things. So they talk about this local process. You have to be a little bit more careful here because when you're working in a local process, the thing that is like your liaison is going to and out of the OS layer. And so the marshalling takes time, right?

Taking your data packets and moving it into the OS and then moving it over into something else. Like that translation and that conversion over there, that takes time. It eats up CPU cycles. And so this is where we start talking about some of the performance impacts. Yeah, and the whole reason why you're trying to break these things up

into different processes, though, is you're trying to break these things up into different processes though is you're trying to have these lower level processes be plugins to the higher level processes yep yeah so it's a stronger boundary but it's got a performance performance hit and that takes us to the next level which is services which are the strongest boundary they don't have to run in the same process they They don't have, they can run in the same machine, but usually not. So these are things that can run across like a network or even across the internet. And so strongest boundary, but also the least performant.

And this is, this goes to what we brought up earlier with the, you know, running your data all in SQL server or your database versus bringing it into your application layer, right? Like when you have this service, that's when you are now making this, this very strong mental decision to say, you know what? I don't care about the performance as much as I care about my data integrity at this point or, or my domain level integrity. And,

and this is where you start seeing these things, right? Like you have a services calling out, especially now with cloud services and stuff, right? Like there can be some decent latency between what you're trying to do and what you're trying to get and when you actually get that. Yeah. And just like kind of, we said earlier, like if you've got like a good, strong architecture that's making use of, say for example, services, it can be harder to cheat those services because you kind of have to do things in the appropriate layer or you have to go out of your way. Now, if you're relying on threads for all of your boundaries, like you've got one, say, big executable, then it's really

easy to cheat those layers because they're essentially virtual, right? So you can tie your UI logic into your database calls or do whatever you want to because there isn't that enforcement there that's happening. So I do think that, like we said earlier, services can help encourage doing things the right way, although you can screw up anything. I can. True.

We all can. Master of it. Cool. Yeah. So I think that's about it for this section. Uh, most systems, other than monoliths, uh,

use many boundary strategies. Yep. And so for the resources we like, obviously we like clean architecture. Uh, again, if you would like a chance to get your own copy of this thing, make sure you leave a comment on this slash episode 74.

And now it's time for my favorite part of the show. And it's the tip of the week. So if you enjoy using Visual Studio Code, you can do a control shift C to open up a command prompt that will take you to your project's root directory so a nice little handy feature there thought you might enjoy like it used a lot when i'm doing node programming um mine's kind of interesting and I did this by accident. So, you know, it's easy to forget that when you're in Visual Studio or not Visual Studio, I'm sorry, SQL Server Management Studio, it's really Visual Studio, right? Like it's a full-blown IDE.

And I somehow or another opened up the output window in SQL Server Management Studio the other day, not even realizing it. And there's some glorious things that happen behind the scenes. So if you do that, you'll see all the output of what SQL or what Management Studio is sending to SQL Server when you're doing things in the IDE. So if you expand the tables list, it'll show you the query that it ran to get that list. Oh, that's cool.

Yeah, if you decide to filter something, it'll show you the query that it ran to get that list. Oh, that's cool. Yeah. If you decide to filter something like the store proc list or whatever, it'll show you all the code that it used to go get those meta objects from the database. So it's kind of a cool way if you want to see some of the hidden tricks in SQL Server of finding these things out. I I wouldn't be surprised if, uh, who's, who's that guy that has like the, uh, SQL server tips blog. Oh, Dave, uh, Dave Pennell. Yeah. Yes. Right. Like I would not be surprised at all. If he sniffed a lot of these things, like one of the, one of the tips that I do, or one of the tricks that I do a lot is I'll select star from sys.objects where object definition, like, and then I'll put whatever I want in there and I can search the entire database for procs functions whatever

that have something you can see all that kind of stuff if you have the output window open when you're doing things in that left nav so yeah pretty cool tip hey I do want to clarify real quick uh that in if you're on mac for that visual studio code command shift c would also work and and just in case for those that are that are like wait a minute there's an easier way because you can also do a control tick which will bring up an integrated terminal inside of visual studio code already there so the other one launches it outside yes okay yeah so i want to make that clarification the control shift c or command shift c bring up a separate command prompt you know that's not tied to visual studio code control tick will bring up um the the one

integrated into code but i've actually had problems where like especially on windows where that one is it's hit or miss as to whether or not it actually opens it up for me or not and i'm not sure if that's because of some other extension that i have installed uh in code and maybe they get confused as to which one's supposed to respond to that i don't know yet haven't figured that out cool yeah uh and for my tip um i i have to throw a big thanks out to uh at critner from slack um he's the dankest of the dank and he turned me on to this chrome plugin called octo tree which is a chrome plugin um that works with github that displays a nice folder view of the source code of the repository you're looking at. If it's any public repository, it just works.

It shows up great, like a nice little pane on the left-hand side. And if you want to use it for private repos too, same thing, you just have to give it a token, which you can get from that repository. So it's really cool, and it makes browsing source code so much easier than the kind of normal user interface. It looks just like a folder that you would

have in an IDE folder structure. Very nice. So two thumbs up. Yep. Yeah. And that's it. The show summary. So this episode was all about talking about

drawing those boundaries or firewalls or cell membranes and the kind of anatomy of the types of boundaries that we can draw. And with that, subscribe to us on iTunes, Stitcher, and more using your favorite podcast app. Be sure to leave us a review by heading to www.codingblocks.net slash review. While you're up there, check out our show notes, our examples, discussions, and more. And send your feedback, questions, and rants to the Slack channel at codingblocks.slack.com and follow us on Twitter at CodingBlocks or head over to codingblocks.net and you'll find

all our social links at the top of the page.