Coding Blocks - Clean Architecture – Make Your Architecture Scream

Episode Date: February 19, 2018

Michael can't tell higher from lower, Allen puts his views where he wants them, and Joe snaps it to a Slim Jim as we discuss how to make our architectures scream while discussing Robert C. Martin's Clean Architecture.

you're listening to coding blocks episode 75 subscribe to us and leave us a review on itunes stitcher and more using your favorite podcast app and check us out at codingbox.net where you can find show notes examples discussion and a lot 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. Blast from the past. I was wondering if you were going to do that again. Yeah, yeah.

Because we hadn't heard that in a while. It's been a while. So with that, I'm Alan Underwood. I'm Joe Zach. And I'm Michael Outlaw. A quick question for all of 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 built from the ground up. They've taken simplicity and speed to an entirely new level and added powerful new features. Oh, and if you're doing the math, 192 hours works out to two working days per month.

But hold on a second. Let's make this real. Two working days per month doesn't sound right that's 24 working days a year that's almost five full weeks that's bringing this that's that's like the month of february right that's like way more vacation time that i take off a year 24 days is incredible yeah okay i mean if if you really wanted to be a mathematician about it. But two working days a month, it doesn't spell it out. The point is 192 hours is a lot. It is.

All right. So 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 using FreshBooks yet, now would be a good 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, that's C-O-D-I-N-G, and enter coding blocks in the How Did You Hear About Us section. All right, so before we get into the show, which this one's going to be about screaming architecture and the various different business rules and entities involved in there, first

we like to go over what we very much appreciate, and that is the reviews that we've gotten. Yep, and so for this episode, from iTunes, we have, first of all, these are gonna be some great names. So let me just go ahead and give you that. Prepare yourself for these amazing names. Tillman 32, Satisfied Photo Printer, Cyclomatic Double Complexity, and Portuguesey. Those are awesome. And apparently I have Stitcher.

I didn't even know that. So I've got Styx, Edward Dunn, and Rosengren. Yep. Very nice. Yes. Thank you all. Go ahead. Were you about to do one?

I forgot I put this thing in here. Well, I was going to mention your thing here. So we had a previous tip of the week um someone brought to our attention that it's uh sql sql server management studio 2017 only and you want to explain that alan i forget exactly what it was yeah so i in the last episode's tip of the week i said hey if you open up the output view and you go and you show object explorer and that drop down then it would show you all the cool stuff that's happening when you expand nodes in the left side for navigating, you know, your databases, your tables, all that kind of stuff.

Well, and now I can't remember who it was, man, that's terrible. At any rate, it was brought up that it wasn't working. And what it boils down to is he had SSMS for 2015 installed. Apparently it did not work there. So in order for this tip to work, install SQL Server Management Studio 2017. And the cool part is it's free. So you can go download it from Microsoft. And they are really good about their management studio products being

backward compatible. So chances are you can download that thing and get all the cool new features and it'll still work with, you know, heaven forbid you're still working on SQL server, you know, 2008 or something, but you know, or I don't even, was there a 2000, I don't even remember what the versions are anymore, but yeah, it'll probably still work with all that stuff. So, you know, there you go. Yeah. Big thanks to Jerry for pointing that out for us. Jerry. Thank you, man.

Yep. Hey, and I've got a talk coming up here at Orlando code camp and that's on March 17th. So if you are in the central Florida area or feel like making a drive, you should stop by, say hi, go to my talk, throw stuff. I did a little preview last week, and nothing bad happened. So I'm sure, knock on wood, everything's going to be fine coming up. Is that the measurement of success, if nothing bad happens?

Yeah, not falling over. I left my laptop charger there. Anyway. That sounds like something bad. It was a whole big shebang. That's a $70 mistake. I know, I know. And I got it back back i got it back after i bought another one well now you got it so bonus yes yep that's true that's true hey um also speaking of bonus uh our bud jason from unity 3d college is launching his

master course and he's selling selling tickets from the February 19th to Sunday the 25th. And then he's going to start the course. And if you've ever watched any, if you're interested in like Unity game programming type stuff, and if you've ever watched any videos on YouTube, you've probably seen some of his videos. He puts out excellent videos.

They're really popular. I've watched a few, like not even realizing it was him. And they're really awesome. And we're going to be uh giving away uh doing a little giveaway here on the mailing list so if you're not on the mailing list and you're interested in this giveaway or other giveaways you should sign up for it because we're going to be doing this real soon so basically right after this episode launches we're going to blast that out so if you're interested make sure you are uh on that list and

um checking your email because that's going to go quickly and then uh we're going to have jet brains thing coming up right afterwards. So good time to join the mailing list. Hey, yeah, I was going to add to that. Like if you're not already part of the mailing list, you really should join up because we pretty much only use it to send out, to give out stuff. Yeah, that's pretty much it.

Hey, but also I did want to point out though, you mentioned that Jason, this course isn't like, hey, sign up for a course and you get to watch some videos. This is a very highly interactive course, correct? Yeah, this is his master course, he calls it. It's very hands-on. It's not like you're buying access to a couple of Perl site videos or anything like that. This is very much more a hands-on approach where you actually kind of work and interact with him as he shows you the ropes.

And I mean, if you're interested, just go check out his videos on Unity unity 3d college we'll have a link here they're also up on youtube with fantastic material um i mean you you get to see pretty much who exactly you're going to be dealing with here and if you are interested in game development or unity uh i mean it's it's just an awesome opportunity cool hey excellent and what we got next um also hey speaking of more giveaways uh we're going to be giving away a book again on this episode so make sure you leave a comment on this episode it's going to be codingbox.net slash episode 75 or just go to the website you can find it and drop a comment on the episode um say whatever you want and we will enter you in drawing to win a book and we'll send you the physical or the ebook just uh leave a comment yep excellent and there were some excellent

comments on this previous episode on 74 as well so go up there read those i need to respond to a few of those also if you would if you're interested in plural site or anything like that and you'd like to help show out head to codingblocks.net slash resources. We have links up there for the books and Pluralsight and various different things that we like. If you want to give back by just getting what you were going to get anyways, that's a great way to do it. Also, we forget to put this

in the show every time, but if you are interested in stickers and improving the performance of your laptop or whatever you slap those things on, head to codingblocks.net slash swag and send us a self-addressed stamped envelope. Stomped envelope. You can stomp on it too. Yes.

Put some footprints on there. We will gladly take it and we will ship you out some stickers. So do that. And I think that is pretty much it, guys. All right. Let's get into the meat of the show here. And let's start by talking about the policy and level all right and i really like this chapter as i i think i say that every time but i

i liked um the idea of the word policy it's kind of funny because um i think this is a great word for kind of describing what a computer program is right it's a policy uh that you pass a bunch of inputs and you get a bunch of outputs from and that's something like that i don't really see that word very often in code i'm glad like i feel like i've seen the word code in code more than i've seen uh policy i've seen the word core for sure i've seen the word manager a lot more often but policy is a good word for you know meaning like a rule or a description of behavior i mean you probably see code in your code when you're using visual studio code

yeah as you code you know full name code in your code so you put some of your code isn't it funny we've changed that to src so that it's not code even though it is code yeah whatever um i just name all my helper classes code that's helpful exactly wrong so they they go on to point out right this this whole notion of code is basically policies for how things are supposed to work the expectations of the inputs and the outputs and most systems are made up of multiple sets of these policies, which makes a lot of sense, right? Like your application does many things. So what's a policy? Can you give me an example?

Business rules, formatting, ETL. If you've never heard of ETL, that's extract, transform, and load. So that's basically when you're moving data from one place to another and scrubbing and cleaning and all that. You know, any of those type things that go in your application. Yeah, my mind immediately went to business rules. But like formatting absolutely is like whether it's a PDF or HTML or even like if we're talking about HTML, just the way that is formatted, the various rules that we've kind of defined to make this thing look how it's supposed to look like. Those are all examples of policy. I mean, think about a UPS label that you print out that you get, right?

How that thing prints out, the size that it's got to be and all that, that's a very specific type thing. And that is part of the policy. This thing needs to adhere to a particular standard. So, yeah, all these things, they go into it. Yeah, and like we talked about in some of the previous chapters, policies that change for the same reason should be grouped into the same components and vice versa. Uh, do you remember which one that was?

Is that the, um, there's S and P in there somewhere. SRP, uh, single responsibility. CCP. Right.

Wasn't it? Close caption principle. No, I've actually got that down here. Uh, it's closed caption for people it is we should make some little note cards here ah man anyways srp is single responsibility principle and the common closure principle i believe is what it is there we go i think you're right yes so close so yeah i, it makes sense, right?

Like, you should keep things together that are supposed to change together. We've talked about that previously. But the goal that they point out here is to create an acyclic dependency graph where the items with similar policies are at the same level and the dependencies are at the edges. And that's very vague sounding. Would you agree? I think at this point in the book it is.

Yeah. In a couple chapters, which we're going to get into, it's going to start to, some of this is going to start to come together and make more sense. But when we're talking about dependencies at the edges, it's still like, what edge what edge what are we talking about and even what's the level yes we're talking about policy and level and joe asked like hey what's a policy but we haven't even described like what's a level right we're already talking about things

at the same level yep and that's the thing so right now if this is confusing it should be hopefully the details will iron that out here in a minute. So we're going to keep pressing forward and help this out. So we've talked before about kind of drawing directional graphs between dependencies. And we kind of take a different slant on that same kind of approach here. And we talk about the direction of that dependency flowing based on the level of the component and um and and this is where they actually give us a definition of what they mean by level here and they say that level is the distance from the inputs and outputs so your little class that reads input from the command line that is is that low level high level i guess that would be low level that's the low level so

basically what they talk about is when you have your low level inputs and outputs, those are the things that can change a lot, right? And so that's your lower level component. Okay. And your thing that say like does the math or does the processing, it has your business logic stuff like that, that stuff should be at a higher level because it's further from the input and output. It just does the syncing.

It passes it to someone else and that someone else is responsible for for routing it where it needs to go okay i'm glad that you guys are confused about the higher level low level too because i always get those backwards as well and in fact as you said it i was like wait a minute no the higher level is your business component no no no no no the higher level stuff would be like he mentioned command line so that's that mentions some kind of a ui right that's some kind of interaction so that would be higher level the lower level details are the policies yeah the further opposite the further the policy is from the inputs and outputs the higher the level yes so it's like it means more abstract.

Yes. Yes. You want your. Well, that's going to get really confusing. Then when we get into this upcoming chapter, because it specifically says the further you go, the higher level the software becomes. Right. And that means the more abstract, the farther it is from the actual input and output of the system i guess when i was thinking higher level i was thinking about reading from in to out you know i always have a hard time with like

binary choices like this especially not so like if you've put a not in an if statement like you've stumped me yeah i'm gonna be there for. You know what? That brings up a thing of mine that I am actually very passionate about doing. If I'm checking for a not of something, I don't do not something because like you said, it's confusing. I'll actually put equal, equal false. I know that's not necessary, but it's very explicit. Like if this is not true, then it's just, I think it calls it out easier. It's easier for people to see that equal, equal false. And it is an exclamation

at the beginning of it. I don't know how you guys feel about it, but I think it depends on the variable name and we're way off topic, but I think it depends on the variable name because if you, if you, the variable name that you're trying to not if it was like let's say you had a variable name that was is ready and you want to say is ready equal equal false that would read weird it would read better if it was if not is ready to me reads nice does that make sense so it very much depends on the name of the of the property or variable or whatever the whatever that thing is that condition that you're trying to not that's that's such it's still to me like i don't know i i'm i am hyper crazy about this like i don't i used to do not then whatever all the time and at

some point i think i overlooked one because the i don't even think it had anything to do with the naming of the variable but the the exclamation just kind of disappeared in with the flow of the text. And so I made the mistake and I'm like, never again. Right. So I don't know. It's just, I,

the way, yeah, I definitely understand where you're saying, where you're coming from with it disappearing. And so that is a strong case for going ahead and being explicit about it. But sometimes when I have ran into those situations where like, I thought that it didn't read right, then I looked at that and thought, well, that's an opportunity that, that tells me that the way I'm using this property or variable

or method doesn't read well with the code. So I should give it a better name. If it doesn't sound right when you say it. Yeah. I wanted to read, I wanted to read more grammatically correct while we were doing all this i wanted to pull back up the diagram so that i could at least you know talk about yes so the higher level is what we said the higher level is the more abstract the things that change less frequently and the lower level are the things that change could change all the time. So that that's, that's where they, they go with that.

I wanted to make sure that we were all on the same page there. Let's be the same page. I do want to mention that true and false is hard, but what's way harder is less than or greater, especially if there's an equal sign in there anywhere. And now you, you throw date diff on top and holy cow man i gotta do some examples like i gotta work on paper like okay date diff this is the right order and

this is the way the sign's going please no one ever touch it again okay so higher level then lower level would be the input correct and higher And higher level. Okay. Yeah. And we'll, and we'll dive into this a little bit more. I think it was all start making a little bit more sense here in a second. So let's press on hopefully. So actually the very next bullet point we have here, the further the policy is from the inputs and the outputs,

the higher the level. That's the very next line we have. So, so yes, the further you get away from the things that are taking data in from a UI or some sort of file system or whatever it is, the more abstract it should become. Yeah.

So your web service endpoints low. Yes. Your core library high. Yes. Well, there shouldn't be a core library. Maybe that's called code code, the code library, maybe. No, it's called code. Code.

The code library. Code helpers. Helpers code. All right. So one thing that's interesting, and this is where not having the book is going to be kind of detrimental. And we're obviously not going to copy and paste pictures out of the book because we're not trying to get any lawsuits or anything but in in the diagram that they have on here they show that the the dependencies are pointing in one direction but then the the source code dependencies go in the other direction and they wanted to call that out like they don't necessarily have to flow the same way right but how can you have say a core library that depends on

lower level things like how can you do that without uh touching those lower levels man i think this is jumping way ahead it's it's that's probably inversion of control right yeah i mean that's the answer to like everything in this book so far it really is and it's kind of frustrating and just for those out there listening that have no clue what this is like it all sounds great right like when we talk about a lot of this stuff it sounds great on paper when you say oh well just in inversion of control or dependency inversion or inject the dependencies if you've never seen it then it just doesn't make sense. And so I am going to try and put together some videos that will be like a series of, this is how you typically start an app. And if you wanted to invert that, that control flow,

this is how you do it. So I am going to put some videos together that will hopefully make a lot of this stuff make more sense because if you've never seen it it doesn't um anyways so back to this so they're saying the data flow can go one way but the source code dependencies can go the other way and that all has to do with dependency inversion and we'll talk more about that in a little while um and this is where it's kind of interesting dependencies should be decoupled from the data flow, but coupled to the level. Anybody want to talk to that? So dependencies should be decoupled from the data flow,

which means that if you've got a higher level item, like the example of our core library, it should not be coupled to those lower level items so your core library should not be touching that scanner should not be talking touching that web service there should be a level of indirection there with like an interface or some sort of you know layer boundary so your entity framework layer should know about how to talk to sql server right but the layer that's higher than that that knows how to calculate tax on an order shouldn't know or care about that dependency so data you can flow data from that entity framework layer to that higher level so that

it can do that calculation so that's the data flow but the dependency is coupled to the the sql server dependency is coupled to the same level that Entity Framework is on. Right. Data is going up, but the dependency is not coming down. Right. So picture you have an order tax calculator that is at the highest level. And let's say a level below that is the Entity Framework layer.

And so it might know how to, and realistically, there'd probably be something in between there. But the point is that whatever is getting that data, it's massaging that data and putting it into some kind of package in order to send it up to the higher level. The higher level doesn't know about that dependency. Correct. So we've got SQL Server at the bottom is sending data up to Entity Framework. It's sending data up to the calculator.

But what we are saying too is that calculator knows nothing about Entity Framework and it knows nothing about SQL Server. So that's why we're saying the data can flow one way and the dependencies don't necessarily go down that same path. And this is why I was thinking when i made the comment about there might be something in between realistically because between that entity framework layer in that calculator layer because if we were going back to like our domain driven design conversations right you might have um something in between there that's you know the entity framework layer

that level is one thing but you have another object in between it that's, you know, the entity framework layer, that level is one thing, but you have another object in between it that's actually using that data. And that might package the data up to send it to the higher level calculator to get that result. Right. And the book here has a really nice example of an encryption library. And at the kind of the top of this higher level on this this little hierarchy here we've got an actual library that does the encrypting and it's called encrypt and it has the dependency on two interfaces the character reader and the character writer and because of these interfaces you can swap in things like you know you could do it from the command line you could do it from you know in a network connection you could do all sorts of stuff

in and all sorts of stuff out you could print the encryption results to screen you could send it somewhere you can do whatever you want because the encryption library is at the same level as the character reader and the character writer and the encryption knows about the reader and the writer interfaces on the lower level lowest level, we've got a console reader and a console writer. These things that are just a deal with like a terminal window, reading an input and spitting it out to screen. And the console reader and the console writer

both are aware of those interfaces that they implement. They have to be, but they are at a different level. So what he's describing, to paint the picture again, encryption thing is at the top. That's your high-level component. In the middle, you have these interfaces that are your character readers

and writers that both the encryption component at the top knows about these two interfaces, character reader and writer, and the console reader and writer low-level components at the bottom also are aware of those interfaces.

So all that's in between the encryption layer and the console reader and writer are these interfaces for character reader and writer. And that's your abstraction. And that's how you can add this misdirection or this inversion, right? And if we were to break this up into components for some reason you know if we obviously this is a trivial example here but in this case you would have your encryption library and inside that component you would have the definition for that character reader and you'd have that definition for the character writer

and it's really important that you have that abstraction on that side of the boundary so that you can plug in any sort of readers and writers that you want to at that level. If it were reversed where you had the interfaces for the character reader and character writer in the same library as the reader and the writer, then you would be taking a dependency from encrypt onto that library. And that sounds kind of like a trivial kind of thing. But in this case, it's a very obvious decision to make i think anyone would make that decision but that's the kind of stuff that can trip you up if you're doing something where it's not as obvious and so it's really important to pay attention to that level and make sure that you're flowing in the right direction yep yeah i mean we've talked about this before. We've talked about similar kind of concepts like this. And I, I felt like this book or these chapters answered some questions that

we've, we've had before where it's like, well, where do I put some of these things? Right? Like, where do I put my interfaces? Do I put them in a, in a separate project or where do I put them in a separate project? Or where do I put some of these DTOs? Do I have a separate namespace for those? And if I understood these chapters right, the answer is that they should be next to within their level. They should be next to that same level, right? So in that example that you were just describing, Joe, the encrypt is the highest level policy.

But those interfaces for the reader and writer, they are in that same level with that. I mean, they're below it necessarily in terms of drawing, but they would be in the same thing. I don't know that. Because the encrypt would have to know how to read. It would have to be able to read something, right? So you could, I think this one's kind of open to interpretation a little bit.

So here's the thing. You could do it both ways. You could put that interface up there with that encryption component, right? You could put it up there and then it would know how to talk back and forth to these things. But the part to me that's interesting is in this little circle, right? Encrypt is pointing down to these two interfaces and the reader and writer are pointing up to those two interfaces. So in my mind, I would almost say make that a separate, I don't know, maybe a project, maybe separate project with just those interfaces defined in it.

And then both the encrypt would reference that interface project and the console reader and writers would also reference that interface project. Let me state this a different way. And let's not care about the projects for a moment. Let's say that I was going to ship you a DLL that does encryption. That DLL or JAR file or however I choose to package this thing up, this Ruby gem,

you're going to have, I'm going to need to know how to read and write data from you and back to you, right? So I'm going to supply you with like, hey, here's the interface that I expect that you are going to provide an implementation of. You're going to provide a concrete implementation of this interface. And that is what I'm going to use to do my reading

and what I'm going to use my writing back out to so they're packaged up in my same package right doesn't matter what the project is okay yeah and so that's what i'm getting at okay is that we've talked about these kind of things in the past like hey where do i put this stuff right and these chapters and it's going to come up again later when we get into dto's and we kind of hinted on it a moment ago when we talked about data flow is that it kind of says that it needs to be next to the um it needs to be within the level that it's trying to support whatever that interface or dto needs to be at that level right yeah so go ahead i was gonna say check this out so if you're trying

to decide whether something should be in the same namespace or the same component one question you can ask yourself is that are these classes at the same distance from the input and output if the answer is yes then you could put them together possibly. Then there's other considerations. So it's still a maybe, but if they're not at the same level, then your answer is no, they should be separated. But furthermore, if you can't tell if two classes are at the same level, and that's an indication that you've got levels mixed into your code and you've got business logic tied in with your inputs and outputs, and that's something that you need to take a look at. So it's an indicator of another sort of problem that you've got going on there. That's interesting. Okay, so then how would that apply then to this example with the char reader and char writer?

So if I had a single class that got input from the screen, encrypted encrypted it and spit it out all in one class that would be an area where i've got two different levels i've got input output i've got my logic right but what i'm saying is like going back to the example that he describes in the book right if if the um the encrypt functionality is the highest level of the application, what is the distance from the input and output of those interfaces? Is it the same as the encrypt, or is it closer to? Because the encrypt definitely needs to know how to use those, right? Yes, so I would say that they're at the same level as yeah i would say so i mean the picture definitely has them drawn in a hierarchy so i'm kind of questioning whether that was the intent

or not but to me that they're at the same distance they're both relying on some sort of input and output but it's completely abstracted as to how it gets in there so i don't think there's any difference between encrypt saying hey i know about a character reader or a character reader saying, Hey, I know about character reading. That to me is the same level. Well, the way I interpreted the drawing in terms of the hierarchy point of view, though, is like, it's only drawn in a hierarchy because we're trying to show the relationships between these classes and, and, you know, interfaces and functionality. But the reality is, if we were going to draw these in terms of the layers of the application, well, then we don't care about these interfaces. Those

are details that we don't care about. What we care about is the policy, which is how do we do the encryption? Encrypting is a policy. That's something something we care about and that's at the highest level and i think that character reader and character writer are strongly coupled to that like you can't have encrypt without those guys it's built in it's a dependency so those to me would be in the same component and because they're in the same component and totally bound to each other i would say they're at the same level the interfaces yeah i think they could be yeah yeah i mean i don't think there'd be anything wrong with splitting them out necessarily even though it might just create additional complexity for no real gain but i would agree all right so let's move on to the next pieces of this because i these some of these do get deep and and i i think a lot of it gets a

little bit clearer as we go on um but the key here was and the takeaway is the importance of this entire point is that the higher level components are now reusable because they've got interfaces to them they're not dependent on any concrete there's no dependencies are pointing downwards. And so these things are literally completely decoupled from everything else. So they can be plugged in anywhere. Yeah, you're basically able to, because of those interfaces, you can kind of quote, inject what you want to use in order for it to work with that higher level policy. Yep. And it says that the policies that change for the same reason or the same time

are bounded by the SRP, the single responsibility principle, or the common closure principle. So those words come up again. And this is something that's interesting, and I honestly believe it's true i was trying to think through it at the time but they say that the higher level components the ones that are sitting up there that are abstracted very well they typically change less frequently than the lower level components and if you think about it like you said some sort of calculator chances of it changing how it works is probably pretty low and so it's a safe thing to abstract out.

Yeah, I mean, let's think about if you are writing banking software, the calculation for interest hasn't really changed much in how many decades now? That is a core policy within the business that hasn't really changed a lot. But everything around it, the business that hasn't really changed a lot. But everything around it, the frameworks that are used, the tools, the languages, the operating systems, the databases, all that stuff around it has changed a lot over the years. Now we get into the part that I think...

One thing to wrap up there is that those low-level components that we were talking about all right and now we get into the part that i think go ahead oh i was just going to like one thing to wrap up there is that those low-level components though that we were talking about should be plugins to the higher level i don't know that we said that no we didn't and that's cool too because they had the whole notion of a console reader and writer for the encryption thing right you could easily plug in a web page that a couple input forms, or you could say, pull this from a database. You don't care where it's coming from as long as it meets those contracts of this is an input and this is an output. Yeah, I mean, it could be spoken voice. You could dictate it over the phone. And that's the point. That's what he means when he says that it should be

a plug-in to that higher level. Because there's that interface between the encryption policy and how it's reading and writing the data then when i said you can quote inject whatever functionality you want in there and that's how that can be a plug-in into it right so you could have it like hey you know you want your password encrypted call 1-800 will encrypt it for you and it'll read back out what you should write down in your little password journal uh hopefully you don't use that service too often i'm gonna start that service that's gonna be money that's terrible uh so this is the part this is where i really

liked where it started going into this because how many times you said the word business rules when, when you were talking about something you're working on hundreds, right? And, and I like how he breaks it down here. So I'll start it off with this one. Business rules are the rules or procedures that make or save the business money.

That's pretty cut and dry. That's a great definition. It is. And well, with an important distinction there or, or like, you know, an asterisk there,

they make or save the business money regardless of whether or not they were implemented by a computer. Yep. Yep. If they did the thing by hand, if they were running interest calculations on paper at the bank, it's going to be the same as if they had done it on a computer, right? It doesn't matter if you sold that car online or if a person walked up to you, introduced you to the car, and then had you sign on a dotted line. It's selling the car is the rule. What has to happen for selling that car, your business rules. And so here's where it's interesting.

So they talk about critical business rules. Again, this is with or without a computer. These are the ones when they call them critical business rules, they're critical to the business, right? Like a bank interest, it matters. You know, loan origination fees, that kind of stuff, it matters to the bank. That is part of their core business. So critical business data is data that would exist even if there weren't automated systems.

You ever work somewhere with paper? Not in a while. I used to. It's been a while. Yeah, not in a while. Yeah, I was trying to think of a really good example of that. When you mentioned paper, I remember way back when people filing their taxes by paper. Oh, man. Yeah.

Filling out the 1040 easy. That data had to exist. It didn't matter if you had a computer to enter it. Man, it reminds me. One of my good friends vp over at ups just retired after 42 years it was a long time one of the guys that got up there and was talking about you know way back in the day when they worked together the way he kind of got started was they worked in this area at ups and everything was literally hand ledgers right like they go in there

and they'd fill things in and if there was mistake, they go back and erase it and they fill it in. And one of the things that this guy did was he was like, man, we can automate this stuff, right? So he took those business rules that they were literally handwriting for everything, inventory, accounting, all that stuff, and moved it into a computer. The business rule didn't change. Just the efficiency and the speed at which it happened was what was different and this is where this is where it ties the two together right critical business rules and data are tightly bound makes sense and they're a good space for an object that we've heard about in domain driven design although it means something slightly different here called an entity yeah sound familiar like uh triple d you know here's the thing and and i

want to preface this a little bit domain driven design has very opinionated wording about how they reference some of these things and the meanings are a little bit different here this is more about how you separate your components in your system so that you have a clean architecture that can be maintained over time, right? DDD was more about solving a business domain problem. So just know that entity here does not reflect entity and domain-driven design. And it's not a reference to entity framework. Maybe entity, Maybe the word entity has become the new helper or manager or library or source or code.

Awesome. It needs to be renamed immediately. It's used too much. It is. This is where they say, an object that contains critical business rules and critical business data is an entity. That's a simple definition. And they should be separated from every

other concern in the application. Yeah, sorry, I was just looking at the book. That's fine. So, this is kind of off-topic part of the course. If you had to read one book or you had to choose for somebody whether they read clean architecture or domain driven design i think we're gonna take whatever book we wanted i think i guess it's kind of a rude question i'm kind of pitting two great things against each other and like as you know it's apples to oranges

but i'm thinking like which one has more effect on my day-to-day coding i'm gonna say javascript the good parts yeah you know everyone's doing javascript now i honestly i no slight on domain driven design i loved a lot of what i learned there and the concepts i thought they translate well, but I think in the grand scheme of things, the content in this book is more about making you think about how to build your software in a better way. Well, so was DDD. It was, but I think... I mean, obviously, the audience that you're talking to, that you're trying to make this recommendation to, is someone who's trying to be an architect or do architecture see i and i don't i i guess that's where i don't necessarily see that i think these are both heavy architecture books this isn't like it's not like we're bringing clean code into the the choice for example so i i guess here's here's my take on it domain driven design

almost centered exclusively around the ubiquitous language. Being able to speak to a business person and translate that into objects in an application that you could look at. Like it was really about the communication and being able to say, this is what you need. I'm going to implement it in code. I would say that in different way, though. I mean, it was about keeping that language consistent in your code with what the business is actually using.

Yeah. So when you look at the code, a business person, you could literally talk to the business person about what that code is doing. And the business person could read the code and have an idea. Right. And that's important. I think that's valuable. i like about this and i i don't necessarily see this as only an architect i think the value that you get out of this is as a

developer like some of the concepts here with the inversion of control and data going one way but the dependencies going the other as a developer you can think about these things and you can say, oh, I see how I can make this to where it will be easier to swap out pieces in the future or something like that, right? I know, man. I think if you're talking, depending on who you're talking to, though, if it's like a junior developer, would you tell them this or would you say, hey, go read the art of unit testing? Or, you know what I'm saying? When you open up the whole world of books, that's a different story. That's what I'm saying. The question was phrased to two books that are both heavy architecture books.

So you're speaking to an architect. So you're already speaking to somebody who is not entry level. Yeah, I mean, that's fair. But I think it's nice to plant those seeds. You know what I'm saying? Like it's, it's such a hard thing because we've talked about it so many times and I don't want to go too far off, off topic here. Cause I know we can talk about this forever. That's Joe's fault. But I mean, we've talked about this, right? Like we've just by practice, by what we've done in

our entire careers, like your database is your core, right? Like we've mentioned that. And that's, and so you have a tendency to think of, okay, here's my UI, here's my service layer, here's my business layer, here's my database, right? And everything's pointing down towards that. This flips all that. And I think it makes you think about, okay, what's important? Well, storage is an infrastructure thing. It's not got anything to do with your business. It's literally just where the stuff exists. And so I think I like these for the book just to put those ideas in your head.

So here's my answer to this. I think that both would be extremely valuable reads to someone who is wanting to be an architect or trying to be an architect or is currently assigned an architect you know like any in that kind of role right i think that the clean architecture book puts it into plainer speak totally the domain driven design is a great book but it's it it's more wordy and it's it's easier to get derailed and and lose the understanding of what's trying to be gained like it might take you a couple times to grasp something whereas if you read this and then and then read that you might have a stronger grasp of it because i feel like and i don't know if you guys felt this but i feel like i've gotten a stronger grasp of ddd having read this one.

Yeah, definitely. So which kind of makes for the case of like, oh, maybe I should have maybe I should recommend DDD first. But I kind of wonder like if we had we flipped it, I wonder if maybe we would have had a much stronger understanding or, you know, or at least I would have had a better understanding of domain driven design having come from this one first. You know, the one plus I'll give DDD over this one is he had a lot more code samples in it. Yeah. And so it was easier, like if he said, like you said, he was very verbose in his descriptions of things.

And so sometimes you get lost in it, but you could always look at the code and say, okay, I think I get what he's saying here. And I'm not trying to say that as a bad thing. Like if you've read Neil Stevenson, for example, I mean, that man could go on like five pages just talking about how you're driving down a gravel road, right? And he's describing every little detail about every little piece of gravel as you roll over it, right? Like, I mean, it's a Neil Stevenson book, so you kind of know what you're getting into and you're like, okay, I mean, and it's good. It's great. It's a great level of detail, but yeah, you can get kind of lost in it at times so

you know this one i would say would be the starting point yeah i agree i think it sets up a lot of the foundation and again i think it's a good read for anybody just to plant those seeds so that you're thinking about this stuff as you're creating it whether or not you aspire to be an architect or whatever i do think it helps you at least put things into perspective and, hey, how do I build decoupled software so that it's easier to maintain over time? And thanks for derailing us for 10 minutes with that one simple question. So just to backtrack for a moment then, going back to this entity, the last thing I had said was that the entities should be separated from every other concern in the application. So what I mean by that is let's go back to this encrypting

example that was given, right? That, that, uh, entity, right. It's the core business rule of how to do the encryption, right? So that, um, layer or level, it's not concerned. It's separated from any other concern about how to read the data in. It's separated from how to write the data back out. It doesn't care about any of that. It's just going to use some simple interfaces to do that, and it's up to you to implement those interfaces to get the data in and out. It is isolated and separated from those concerns.

Yep. No dependencies on databases, third-party dependencies, user interfaces, nothing. Right. It's self-contained completely. It's pure business logic. Yep. Yep, so next section is talking about use cases.

And the difference here between use cases and like business rules or policies are that use cases are kind of additional business rules that are are that are not critical but they define how the system should work but without having they would have no impact on a manual business operation like this is something that you would do it's like almost like an example of a behavior that your system needs to account for. It's a description of how the automated system is to be used.

Yeah, it's specific to software. It has no impact on the daily running of the business any other way. It's literally just how your software works. They indicate how and when a critical business entity should be invoked. They indicate the inputs and outputs, where they come from. Oh, sorry, but not where they come from. Very important.

Just kind of back up on that for a moment there. We mentioned banking, right? And you might give a loan out to somebody. And if you were, if you, you know, part of the core business rule would be how do you decide who to give a loan to and the actual process of making that person a customer and filling out the loan paperwork. The steps that you go about doing those core business rules, those are the use cases, right? So if the customer's credit score is greater than this, then we will make them a customer and we will fill out this application and paperwork and whatnot, right? That's the example of a use case. And that could be an automated,

and that would be your automated system, right? So those are decisions made in your software. Whereas if some dude walked in the bank and you've known his mom for 50 years, you'd be like, he's a customer, right? That use case in that software has no impact on how they do business inside that office. And that's what we're getting at.

They're completely disconnected. The critical business rules are the same regardless. The use cases are for the software only. Yeah. And how the data gets in and out is totally irrelevant. And the entities have no knowledge of how use cases use them. And it's similar to the point we made before with the object that contains the critical business rules and business data have, they're totally separated from every other concern and application. Entities have no knowledge of how use cases use them. Which, you know, I mean, at first I didn't like this encryption example that he gave. But the more we go through this, the more I'm like, oh, this is so perfect.

Because let's bring back up this banging example, right? If you, you know, security is going to be important to you, right? But that encryption policy, that encryption entity doesn't care about how the data, where the data is coming from, how the data is being used or what it's being used for, right? It just knows it's one thing. I'm supposed to encrypt some data, and that's it. I got some data in, I'm going to spit it out encrypted. Yeah, and that's all it cares about. Exactly as Joe said, it has no knowledge

of how the use cases are going to use them. It doesn't care if it's for encrypting personally identifiable information for a customer or for an account number or anything like that. It doesn't care. And this is where we talked about the dependency inversion principle earlier. Bingo. Huh? Bingo? I got bingo.

Yes, you did. That was the third acronym tonight. I won. Higher level components know nothing of the lower level components. The direction is inverted. Should I try and explain that? Yeah, sure. I mean, yeah, we touched on it already.

So high level components know nothing of the lower level components in our encryption example. The encryption algorithm itself didn't know anything about how the inputs and outputs might interact with like say a terminal right and the way that works is through an interface right that when when you talk about dependency inversion so the way that we've always that we've talked about it is you knew up a new class right and and you call that class and then some method in that class and then it calls a database or whatever that's that's like dependencies pointing one way and actually the flow of everything's still going that way if you want

dependency inversion typically what you do is instead of knowing up another class like you call some class and then it calls another class and whatever, there's an interface that goes between those two. And logging for whatever reason to me is an easy one to talk about only because typically in any kind of software that you're going to put out in the wild, you kind of want to know when things go wrong. And usually the only way to retrace it is to look at a log file right software does it all the time well if you have your application and then you're using a library and you need to be able to log things in your application you need to be able to log things in the library you could just include that same logging application or that logging DLL or jar or whatever, and both of those. So log for net or log for J, right? And, but that kind of sucks. Now you have a dependency in that

library that has nothing to do with logging. You have a dependency on this, this log for J framework, right? And if some new framework comes out, then you're going to have to do something with your dependencies. Well, instead, if that, that-party library just has an interface for an ilogger you can new up that ilogger in your primary application and just pass it to that third-party library as the dependency you basically told it hey i know that you're looking for this interface for ilogger here's something that fulfills that interface use it you know looking for this interface for iLogger, here's something that fulfills that interface. Use it. You know, we keep saying interface, though,

but it's important to note that that's just one way that you could solve the inversion, the dependency inversion. You care to take a guess at how you might be, another way you might be able to do it? Not an interface. You could probably do like a service locator pattern. It's not the one I was thinking of, but okay. Joe?

Yeah, I'm just thinking interfaces. It's where you depend on, I guess you could do maybe an abstract class. There you go. A class, an abstract class. Yeah, you could totally do that, a subclass of it. Yeah, you could subclass it, and then you could even take it a step further because then you could go with a template method pattern inside of the abstract class,

and so then your subclass only needs to implement whatever pieces of functionality it cares to. The interface, I would say, is probably the cleaner, more common way, especially with modern languages, but it's not the only way yeah that's true but i guess that's the whole deal though is instead of letting that third party library control how it's going to use that logger or what kind of logger it uses you tell it what it's going to use you give it to it And that's how you invert the dependency. Instead of that thing, knowing what to new up, you give it what it's going to use and it just uses it. It doesn't care what it is. Right. So I read, I read some sort of example online that was interesting.

Somebody needed something that worked in IIS, like a plugin to IIS that was going to log messages on notifications. Right. And when they first started out, it was a very simple thing. Hey, just log it to this particular area. But then as things came in, they said, oh, well, you know, for certain types of things, we want it to email. Well, the problem is now when you go that route, what are you going to do? Have a bunch of if statements up in the thing that's really supposed to be this simple notification thing, having to know about, okay, well, how do I start up emails?

How do I start up an SMS if they want to do that? How do I start up these? Instead of that, you just pass in the object that knows how to do this notification. You give it to it. And then it just calls it, right? Well, think about this. I mean, this goes perfectly in line with this encrypting example. In that scenario, the input and output are, the policy doesn't care.

The policy is like how, you know, writing the data, right, in some particular format. But where it writes it to, what could be a file or it could be an email, that part it doesn't care about. Right. It just knows that when you call write, whatever you gave it, it's going to try and write it. And if you gave it a file writer, it's going to write it to a file And if you gave it a file writer, it's going to write it to a file. If you give it a database writer, it's going to write it to the database. Yeah. Right.

Well, because again, and I'm trying to make the distinction here because it's policy is the format in which it's going to write the message. Right. It's going to call and write. You're going to give it a message. You're going to give it some string like you know uh ran into this error but it's also going to include other things like here's the time the date you know the the thread you know what level is the message like so it's it's going to format that message that that's what

its purpose is is to is to um just going back to formatting being a policy right yep so uh just to pick back up where we were here with use cases these use cases are specific to a single application but the entities are generalizations so our entities can be used across multiple applications they're not tied to anything they don't care and i really like the point that um that use cases are specific to a single application if you think like about a batch processor or a mobile app or a website or some sort of service that's running like those are all different applications but they all use the same entities you know ideally so i thought that was kind of cool and one thing um the book like doesn't really touch on is um when i like when i think of use cases i think of very much like ux like this is what

the user does and i think there's a lot of carryover it's just that this is kind of a more specific like software architecture definition of use case yeah i mean it's kind of interesting that you brought up the user interface because there was one part in here where he says that the user use cases do not describe how the system appears to the user and i wrote a comment to myself because like well that depends on who you're asking right like you ask a ui designer and they're gonna be like whoa whoa whoa whoa whoa of course it describes how it's supposed to appear like when that when that user clicks the next button you know the use cases this is what you're supposed to see right so i think that part depends somewhat on the audience yeah i agree i think he was talking more from a

server-side type you know or you know i guess it doesn't even have to be server-side like a desktop application or something the business behind it and there used to be something like uh i forget now but there used to be some way of kind of like writing sentences as use cases where it's like, I, as a normal user, want to be able to do whatever so I can whatever. And so there's like this kind of structure. We've talked about this. This is the given when then. Yes, that was it. a logged in user, when I add a product to my cart, then the cart is updated to reflect the quantity entered. Man, just give me a storyboard. Oh no, man. I love given when then syntax for, for use

cases. It's so awesome. It's good for writing unit tests. I will say that because then it's very spelled out, right right and in very business terms but no i mean it just makes it so obvious to like what your codes should be uh if it's well written given when then yes it's really good but who wants to write like that yeah i do exactly i have oh good god you want to like write a ticket like give 10 of those in there? I definitely have. You have. I definitely have. Well, I don't want to write any tickets. Well, there's that.

I'm a ticket crusher, not a ticket writer. Oh, that's amazing. All right, so this next part was pretty interesting to me. And I don't think I ever thought about it this deeply. The request and response models so use cases accept simple request objects for input and return simple response objects for outputs now i've always done this at like a service tier right like you have a search request and then you have a response object like that that sort of makes sense to me but what they advocate for here is doing it in between boundaries at different levels,

right? So they're saying that your request object that went into your service call should not be the same request object that goes into your business layer call. And that should not be the same request object that goes into your database layer call. He basically makes a very strong point of those should be separate at every level. And and the reason and this makes perfect sense is they don't always change at the same time for the same reason and and it kind of sucks when you think about it because you're like man am i really gonna have to write you know request response objects for every single tier i have if i have a four-tier app i've got to have you know four pairs of these things all the way down. Yes. But this is going back into the conversation that I had about like, where do you put your interfaces? This is part of, you know, where do you put the DTOs, right? Because these

response requests and response models, like where do you put these things? If you're going to make a request to some higher level entity, right? It has to know how to read that data, right? So the interface for that thing, or, you know, if it's, if you're just gonna put the DTO there, it needs to be at the same level as that entity, right? And similarly, if it's going to respond with, with an object back, right, that definition of that object is going to have to be at the same level as that entity so that it can new it up and return it. Which means you might have a bunch of translation in between all those layers, right? That's, that's the thing that stinks. So yeah, you're right. You know, whatever the inputs and outputs are at any given layer, you probably want

those there because it makes the most sense there. Separating it out seems like an unnecessary abstraction. But that also makes you say that, hey, when you have this service layer, they got called and then that needs to talk to the business layer. You're going to have to have a translation of whatever that request was to go into the request into the next layer. And then you have to translate that to go into the request of the next layer, right? That's fine. I mean, that's the adapter pattern then it is and and here's the thing and i think it's worth calling out is they could be the identical objects all the way down right like it could be that you have uh let's call it um calculator request up here, right? That's going to be your request object. There could be a bank request object at the next layer, and it could be basically a copy

and paste of that same class. But the key is it is separate, right? So if that thing ever has to change, you don't have to funnel that change all the way up it's literally just oh you're going to have to change how this layer pushes data into that next layer right so essentially what i'm saying is the multiple layers aren't referencing the same class it could be almost identical looking classes right it hurts and it hurts it does does, but he makes a strong case for it, right? And we had a very similar conversation with the DDD conversation when we talked about if you had a customer object that was in a customer service namespace versus the customer object that was in the shopping namespace

or something similar to that, right? Don't get hung up on this idea that duplication is necessarily bad that you can't have these things repeated for specific purposes because what you're really trying to break here is you know these things are going to change at different times different rates for different reasons so you're trying to break that dependency so that when it does change in one it doesn't impact the other. Yeah, it doesn't flow all the way down. Yes. Pattern where it's going to adapt the data from one DTO to the next isn't necessarily

bad because it insulates you from change impacting something higher level. That's the key. It insulates you is exactly what you said. It breaks the chain. It's the firewall yes take going back to the previous episode now you don't have to like it no you don't and it feels wrong right like code duplication feels wrong but there's a very good reason for it here and hopefully what we all just said there drives that home well it's like he said in the last in the in the last episode

we covered it like um there was some comment where he says like we we see duplication and we feel honor bound to remove it right but there's there's different kinds of duplication right there there was like uh what was it like accidental duplication and then true duplication or something like that like i forget but you know one was where the things might look the same but in reality they're going to change at different rates for different reasons so it's just coincidental that they that they're the same even if it is basically a copy and paste i mean in this case it could be right it could be um but it was interesting the next thing that they say is there should be no dependencies on anything.

These should be simple objects. The request and response objects should be POCOs or POJOs or whatever you want to call them. DTOs. Yes, they are plain old objects. Let me tell you, I don't envy the programmer who has to defend this in the pull request review. Listen, Cody Blolocks told me that sometimes there's coincidental duplication. And that's why

I've copied and pasted this class four different times. You tell them to send their complaints to the Slack channel. That's right. That's right. Oh, and I love this too.

They say that it seems like it might be a good idea to return that entity object with your data, right? Like, hey, we've got this encryption class up here. Let's just tack it on to the response object here because then everything can use it. No.

Here we go. Okay. So entity framework has been our, let's say that- Our whipping child? Yes. The whipping boy du jour. We've beat up on entity framework for many episodes now about this because it's very tempting to just return back

that entity framework object. But this is making a strong case for why you shouldn't do that. And same, same with the domain driven design book was making a strong case for why you wouldn't want that exposed outside of its layer. Right. And he even made a point. I don't remember. I don't think it was within this particular part of the book, but later on where he's saying like you know you might be Tempted to have an object that is A row of a database and you're Tempted to remove it or I mean To return it to return that row

But you can't do that because then You're you're leaking that that Dependency and you don't want to do that You're leaking where it came from And that's the problem and now You're coupling everything else To that decision that you've Made you're coupling everything else to that decision that you've made which was hey i want to not only use entity framework but i'm going to use sql server

and now when you decide to change either or both of those you you've you've made more work for yourself yep and i've seen it especially when it comes time to actually change stuff the database you're like oh i don't know there's all this downstream effects. I'm going to change this one thing. It's going to break a whole bunch of stuff. That's an example where you're missing that insulation there. Let me tell you, though, if this is the worst thing that you're sending me in your pull request, we're going to be all right.

Right on. Yeah, man. Well, yeah. And, you know, I know we're picking on Entity Framework here, but not because we don't like it. No, yeah. Nothing at all. Nothing can be further from the truth. But it's just that, you know that meme about like, I've seen things.

Right? Like, that's what it feels like. And so that's why we pick on entity framework because we've seen some bad things with entity framework where it's like uh this is dirty and it's just probably the easiest to pick off because it is probably the most ubiquitous in terms of you know orms in the dot net world yeah definitely yeah but yeah now here's the other thing right like the what you said about they change at different times, the whole reason why you would never include this thing back.

What if that, for some crazy reason, that encryption component did change? Now you've got to change all your downstream code to handle that change, right? Not necessarily. No. No, no, no. That's why they say don't return it, though. So if you're returning a response object,

you don't tack on that higher level component because if you're returning that thing down and it's now five layers deep and something five layers deep is trying to use it and that thing changed,

you've now, you've leaked out that dependency all the way down, right? It'd be the other direction though, right? It would be the other direction though, right? It would be like not passing in your database row to the encryption. Oh, no, no, no.

But remember, the whole point was do not return a reference to the entity object. So what I'm saying is if you got a response, you went to use that entity object, and instead of just getting the output of it and sticking it on a property on your POCO. Oh, I see what you're saying. Yeah, yeah. You don't return it back out because now you've you've made other things dependent on that entity object when really it should have just been your use case so so yeah

you would return back here's the encrypted string correct not necessarily which encryption algorithm you used which that algorithm might be encompassed and you know enclosed in a particular object yep hey and this is where i did put in the note, common closure and single responsibility principles. Boom, I remembered it. Yeah. All right. Stumped to a slip, Jim. Yeah. I thought we already agreed that that was wrong. It was the closed caption programming. All right.

So who wants to conclude on this one? It's just kind of. So, okay. So just to wrap up this section, then the business rules are the reason a software system exists. And these business rules should remain pristine and they should remain independent and reusable. All right.

Who's going to lead in the next one? You got to do it properly. Whoever does it. Allah is the only one who can do it. Oh, man. Now this is, I was just going to say it. No pressure. No, you can't just say this.

You're the chosen one. Yeah. That's right. All right. Here goes. Are you ready? Screaming architecture. That's pretty good. I like it. That was pretty good. I like it.

That was really good. I like it. So the example here, we talked just a little bit before about how your project or your application kind of should reflect this purpose. You can imagine if, in the example of that encryption program that we were talking about, if you opened it up and you were immediately confronted with things like

character reader line scanner pretty print formatting you know like those things to be scream console application but they don't scream what the purpose is which is that this is should be encryption so in an ideal world i should be able to open this project and like be confronted immediately with the purpose of the application or the component, which is encryption. And the whole thing should be roughly themed around encryption because that is its reason to be. Man, I love this. Last night, I started up Visual Studio on the Mac and I created a new application and you

open it up. And what do you see? Folders, views, models, controllers. And I'm like, man,

that, that burns me up. And even the same thing, like when I was initially looking into doing react JS on the web, all the tutorials were controllers, views, models. I'm like, no, I'm not burying all my stuff in there. If I'm writing an application about podcasts, I'm going to have a podcast folder and I'll put my views, models, and controllers in that. And if I have views where I want them,

thank you. That's right. Like, dude, this stuff makes me so mad. And honestly, I don't know about you guys, but anytime I start to learn something new, it really frustrates me. When I look at the file structure, and the file structure is something like source views. Right. And I'm like, no, in my soul, I can't do this. I've never been able to do that by the way, because I look at it and I'm like, so you're telling me if I write a real application, this got some real meat to it, that I'm going to have 50 views in one folder. Really? No. And then, oh, oh, by the way, all the models that are used in those views are going to be in some models folder.

And I'm going to have to scroll up and down to find all this stuff. And it's not going to make any sense, man. It like, I actually got angry and happy when I read this because it reminded me of all the bad. And I literally just created a project in visual studio last night. And it did this very thing where it's like, it screams framework and tells you nothing about what you're actually doing. Definitely. Uh, you know, creating a solution with a visual studio was definitely the thing that came to mind like as i was reading this and i was kind of like okay well what am i thinking of like as an example of how this is wrong you know when you create a an mvc app a web app with visual studio and it's like here's your models here's your views here's your

controllers right like that was definitely the example in my head of like, oh, yeah, that that's just the architecture of what I created and the tooling that I used. That's not necessarily anything about the application I want to create. But I don't want to just pick on them. Like, it seems like every tutorial out there are the same way. Like, OK, so we all do EXTGS programming. Go read their tutorials, views, models, stores. Right. No, that's not how you write software and if you do write software you're doing it wrong if you're doing it that way straight up we're all doing it wrong yeah we're all doing it wrong but but i mean seriously like it is very important that somebody be able to open up your application and look at it and say, oh, okay, there's a customer service section.

Okay, there's an accounting section, right? Like, make it obvious. It should scream the architecture. Well, what if we said that maybe, because I definitely think that websites are the biggest defender here. And there's been times I've downloaded like application skeleton projects and stuff from github just because it automatically set the folders in the prescribed way for me and i i heavily dislike that but if we're saying you know what this is my website project it's going to be little and tiny and all it is is uh you know basically a facade for the website and i'm going to have my other stuff and some other component and at that point then i think

it's kind of fair because i'm saying well my project it is the framework it is the website yeah i still i still don't like i just don't have a good solution because i get that if i you know have like an asp site or something or a or a you know angular site like i like that things are kind of organized by layer and i think it makes sense and it's okay to hop around although you inevitably end up with like five different freaking things open that span all the folders anyway. And that's what I was going to say. Yeah, go ahead. The problem is this, though.

I mean, we talked with Michael and Clint about, you know, a while back about the new project, you know, the file new within Visual Studio, right? And that whole experience and trying to improve upon that, right? So if you're a developer who is working on the tooling to improve the file new experience, right? You can't know what the end application is going to be. You have it by a name, but that tells you nothing about what it's you know uh what it really is necessarily so i mean from it's it i guess it's a double-edged sword like

you know from their point of view right whether you are authoring um create racked app or you're doing file new experience in visual studio like you're going to lay down some structure that you you know as a guide to somebody but it's going to be up to that developer to just take that as like okay you know this is a um an example pattern of like how you think things should be laid out, but it's not necessarily the end-all be-all answer, right? Yeah, I think that's fair. I mean, he even goes in this chapter and says, you know, people who write frameworks are very proud of them and they should be.

I mean, there's a ton of work that goes into frameworks to enable you to write software faster, right? That's the purpose of a framework. And if it's not enabling that, then you probably chose the wrong framework. But on the flip side, he also says you should scrutinize those things. If your software starts looking like it's about the framework and not about the business problem or whatever you're actually trying to create, then you're probably not doing it right.

And I agree with that i i actually like one of the bullets we got here if your architecture is based on frameworks then it cannot be based on your use case i agree with that if you're coding around it go ahead just thinking like if i were to start up a new view uh what project i was looking at somebody's recommendations they end up with uh 18 total files and folders just for like the basic kind of like you know there's some files in there for like your index or you're sitting your css or whatever your basic stuff routing and there's a couple folders for where you're supposed to put your stuff but then you know there's a an npm folder in there and there's a there's a no folder just full of packages too it's just like crazy to

think like hey i'm starting a new website and i've already got 18 000 files and folders and then the first thing you do is you go into like you like hunt around for index right and then you like delete six lines and put your you know two lines in there and you know you start from there it's just crazy to think you've got this whole huge you know scaled exoskeleton kind of built around you yeah go run create react app and then go look at the hundred of node modules that are in that folder yeah that's the video of me doing just that i'm like oh my gosh my computer ran out of space pause the video yeah oh man so here's another here's another anecdotal thing that i think is kind of apropos here house's architecture is focused on usability, meaning does it have a bathroom?

Does it have a kitchen? Does it have a bedroom? Are there doors in between all those things? Are there windows? Not whether or not the outside's built with bricks or stucco, right? And so what they're saying is your application should focus on the usability of the application, what it's supposed to do.

Worry about the frameworks and the infrastructure decisions when the time arises. Focus on your core. And sticking with the theme of this chapter, though, that blueprint for that house screams what it is. Yes. Right? Yes. So you can immediately look at that.

So if you were to look at your code's directory structure as a blueprint, for example, or the solution structure as it might look in like an Eclipse or Visual Studio or Visual Studio Code, whatever you're using, then if you think of that as the blueprint, does that structure alone scream the architecture and intent of your application hopefully the answer is yes yeah and i was just thinking like if if we were you know building a house and we were using some sort of framework we what we're saying kind of like is a bad example would be i open up the house project and i see folders like surfaces and portals and measurements

because that's not that's not housey like sure houses have those things but that's not specific a better way of thinking about it would be if I open up the house project and I see a folder called doors or windows or walls or like those things I see that I know what we're talking about and it helps guide me as a new program and an existing one to the place where I want to go. Like, so yeah, I mean, I like this idea.

It's still, it kind of bothers me. I think I have some like internal conflict because it's so common to see this kind of stuff in front of frameworks that I wonder, it's like, are they all doing it wrong or is there something I'm misunderstanding? I didn't think about it, but I think what mike said

was probably exactly it right like when you're building the tooling to to set up your framework like you said you can't know the use case for what people are going to use so you have to set it up in a way to where it makes sense right creating interviews models controllers thing fine right you you scaffolded up the application now to really use it there really should be something that says hey don't leave these out here put them in a folder or something right like you know you know i think uncle bob has gotten to the point in his career where he's got people that he could pay to do the ui for him so he doesn't care yeah i need i need to figure out how to get there oh that's awesome um and and he points out again he's always deferring decisions infrastructure type decisions

the details until the last possible moment yeah i'm totally kidding by the way i know he's done a lot of stuff i'm gonna tweet him that you were terribly serious. Oh, I'm sorry. I'll be right back. And then they pose this question in the book. I'm pretty sure that we all would have come to the same thing, but what is the web? What layer is that? It's your IO. So it's low level.

Yep. Exactly. All right. So there's the theme and the purpose of the architecture so the architecture is all about the structures that support the use cases of the application and architecture is not a framework nor is it supplied by a framework and that's kind of what we were talking about before with those web projects where it and so just you know in going back to the purpose of this though similar

to what alan said a moment ago the a good architecture allows you to defer and delay these decisions but it also makes them easy to change your mind about those decisions no yeah and i think talking about those frameworks the way we did like really exemplifies that like the first thing you do is you go in there, you chip your way into something that actually matters, which is tough to find. And you chip your little changes in and then refresh it. And that's the opposite of deferring decisions. The opposite of delaying all those details. It's like you're inserting your application into their framework.

A little funny story to go along with this, with the, uh, the details. So I was trying to force myself to use visual studio on Mac, just see how it was, you know, if it was good, if it was bad, whatever. And, you know, in visual studio on windows, if you start up a new app, you can create a local database, right? It's like a little mini SQL server or SQL server light baked in. Oh, local DB. Yeah. Yeah.

And so, you know, I was going to go do that really bad because I was not deferring decisions on what I was going to do. I was just going to set up a database. In Visual Studio for Mac, they don't have that. And so it forced me to defer my decision. And I was like, you know what? This is a good opportunity just to find an interface and mock

some data out, right? So it kind of forced me. So it was almost nice that it put me in that mind like, you know what? This is a good opportunity just to find an interface and mock some data out. So it kind of forced me. So it was almost nice that it put me in that mind like, no, thou shalt not have the local DB. You will do this right. So in other words, the takeaway here is in order to really take advantage of these principles and write good code, all Windows developers should do their coding on a Unix-type platform. That's right.

And all Unix developers should do their development on a Windows-type platform. And then that way you're forced to write good interfaces and mock classes. That's right. And delay those decisions for as long as possible. There it is. I think I summed up this entire book. Hate, hate, hate, hate, hate. Say what? You go to lunch together and hate? And then hate, hate this entire book hate hate hate so what you go to lunch

together and hate and then hate hate hate yeah all right so we know we now know that frameworks are tools and they are oh that came out wrong they're they are tools that we use. They are not waves of life. They are not our architecture. Yep. And as we said a minute ago, he says, look at them with skepticism. And I agree with this. I think that's legit. They should not dictate your application architecture. They should not force controllers, views, models, et cetera.

And then he also says, if you're going to take a framework, think about the two things. How should you use it? And how should you not? Or how should you protect yourself? That point there was my favorite takeaway from this section. How should you protect yourself away

from the framework that you're using? Isn't that interesting? And in JavaScript world, I think writing your own modules is the answer to that. That's it, right? That's how you keep yourself away from that. The more you chisel your stuff

into those folders, the worse off you're going to be. So if you can kind of package those guys, like otherwise you're totally at the mercy, just not doing it. And we're not saying don't ever use Angular or react or view or ember because those guys are totally prescribed frameworks we're saying do it but don't let

them dictate your application architecture right so yeah i was going to bring up react as an example then because like if react is a framework well it's not angular is react is not react just a view layer right a view framework yeah you wouldn't call it that no not so much i mean the they don't really enforce much i mean if you just want to create a rack react component with a few lines of code and jam out some html can totally do that. Like there's nothing stopping you. It's not necessarily going to be the best way to do it. Angular is a framework. Angular is full on NBC, right?

I'd say view and react are very much just view layers that you can, you can basically do as little or as much of it as you want. There's no prescribed major path for any of them. I mean, yeah, I was just curious to see like what it refers to itself as and it's called it's referred to as a it is just a library is what they refer to it but um and and looking at the wikipedia page they say it could be using combination with other libraries or frameworks yes so typically what you hear about with React is it'll be used along with something like Redux or Flux or any of those types.

Those are frameworks, right? Those dictate how you do things and how data flows. But React itself is literally just spinoffs of HTML on the page, which is, you know, kind of nice. So, yeah. Quickly wanted to go over testable architectures. If you've done your job right, which a lot of times means unit testing up front, then unit testing should be easy to do.

Because as we've talked about many times before, if you put your unit testing off, it can be really hard to do because it's really hard to set up your code in such a way that it's going to be unit testable and a lot of the reasons that your code is hard to unit test is because it's mixing these levels it's doing things that it kind of shouldn't and unit testing is a nice way of kind of enforcing that and entity objects will be plain old objects with no external dependencies so those should all be nice and testable use case objects will coordinate the use of entity objects

again no infrastructure dependency there so yeah i mean testability is great just to just to step back where i wanted to finish my point with the react thing though because like okay fine so let's say react isn't a framework and let's pick on Angular for a moment. How do you protect yourself from Angular? You don't. I mean... You buy in or you don't. You do as little as you can in Angular and you do as much as you can out of it. I think what Joe's saying. Which would be totally weird you've never seen

an angular app written like that but you would write all your javascript all your core javascript functionality would be outside of angular as much as possible and you would only use that i guess for the presentation and that'd, that seems like you're fighting the framework at that point, right? I know. Yeah, it's, man, it's such a tough thing. But that's why that statement that he said, how do you protect yourself from the framework?

That's why it kind of hit home for me. That's when you use something else, right? Like you almost just go after other patterns. Like I said, Redux is a good one, right? Like it's more of a prescribed pattern than a framework. Whereas Angular is a full one, right? Like it's more of a prescribed pattern than a framework. Whereas Angular is a full-on MVC framework. Like you have to code within the construct of it.

Otherwise, it's just not going to work right. So yeah, I mean, I think when you choose something like that, that's what it is. But I think you can still architect it in a way to where it would be meaningful. Like you could set up your folders to say, hey, this is my customer service area. This is my accounting area. That kind of stuff. So that's, that's a hard one, man. Yeah.

I don't know. All right. Well let's just wrap this up by saying that your architecture should quickly identify the purpose of your system. It should be screaming that architecture. Oh man, I love this. I put this in here. So he wrapped up this particular section with,

what happens, you've written the software and then somebody comes over to you and says, hey, we see some things that look like models. Where are the views in the controllers? And then your response should be, oh, those details, they needn't concern us at the moment. We then your response should be, oh, those details, they needn't concern us at the moment. We'll decide about those later. Like, how awesome would that be?

I've never been in a position to say that, but that would be pretty cool. All right. It's kind of like Obi-Wan talking. These are not the views and controllers you're looking for. Those don't concern you. Oh, man. All right. so with that hey guys for those that did leave us a review

or have in the past like we've got many many many now and we read them all thank you very much for taking the time to do that as always if you wouldn't mind doing it please go to www.codingblocks.net slash review and leave us review on iTunes or Stitcher, or I think even pod chaser we have. So any, any one of those things, you can find the links up there. So if you want to give back, that's a great way to do it. All right. And so with that, let's go to my favorite portion of the show. Survey says... All right. Last episode, we asked, what is the oldest code that you actively, regularly work with? And your choices were less than one year, green as can be. One to three years. Was there life before Angular? Three to ten years, back when JavaScript only ran in the browser. Ten to fifteen years, pre-jQuery, we had to get element by ID back then.

For more than fifteen years old, pre-stack overflow. You either knew it or you didn't. So I think it's my turn. I'm going to say most people say three to ten years, and I'm going to go with 36%. 36. Three to ten, 36. What do you say, Joe?

Just because Alan stole my answer, I'm going to say 10 to 15 with 28%. Okay. They're programming in COBOL now? You could have. 10 years is not that long ago. Yeah, it's really not. See the gray in my beard? This is because of JavaScript.

See, I have a beard because all the hair fell off my head down my face. Yeah, I mean, I'm wearing a hat for a reason. The reason is JavaScript. All right. All right. So then Alan wins. Oh, really? I even fell within the percentage.

Nice. Three to ten was by far the most popular 43% of the vote. Nice. Yeah. It was by far and away the winner. Okay. Sadly, we do have some that are working on apps that are 10 to 15 years and that are more than 15 years. Ouch.

What was the second most popular? Those two. Oh, man. Wow. Yeah. Ouch. I'm sorry, guys. Those two were tied for a second.

I mean, maybe you like it. I don't know. Everybody has different things to float their boats. I would not want to. Yeah, that was, yeah. All right. So. That's kind of sad.

Like, I always felt like looking at job postings, it always seems like they're like the new projects. But maybe that's kind of like a, you know, you tend to see more job postings for like newer, hotter projects because those are the teams that are hiring and others have kind of solidified. Well, you know, you guys are being like really negative about this. Maybe the people that wrote that responded with those answers, they're all working on something like, you know, they're they're working in C and they're working on the unreal game engine or they're working on the linux kernel you know but they're doing fun cool things in a cool language but it's just an older code base we'll go with that yeah i mean i think

i think 10 years is not crazy like i've written written lots of code one 10 years ago. It was all awesome. All right. So with. Show my age here. Yeah. With Valentine's Day coming upon us. This episode survey is. Have you ever made a mixtape? And your choices are.

Does a playlist count? count oh it doesn't then no i haven't or man i got my technique down in everything i know exactly when to play bon jovi's five words yes i have i can't wait to hear the results of this one. That's how I got on. Do teens these days send a YouTube playlist? Yeah, man. Teens these days don't even talk to each other. They just sit there and they're standing next to each other, tapping on their phones, right? Your friend's phone buzzes. Yeah, I just sent you a message.

There's no such thing as interaction. I miss a little about it. I have no clue no clue yeah you didn't have to woo anybody nowadays did either of you get my five words reference though i did not oh no wanted dead or alive wanted dead or uh it's not like a thing in the bon jovi songs where it's like these five words i swear to you he's always saying that no i didn't get it all right man let's go back before my time what liar before your time 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 that 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 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. 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 that how did you hear about us section. All right, so getting back in here, we're going to get into the last parts of this. So here we are on clean architecture it's

really about the separation of concerns we talk about it a lot we've mentioned it about a billion times in this book and that's really what it is dividing software into layers like an oger like an ogre yeah okay Like an ogre? Yeah. Okay. You don't remember, like, ogres are like onions. They got layers. From, uh, what's the movie name now? Shrek?

Shrek, there you go. Oh, man, I don't remember that. Sorry, man, my ogres are all like World War, like World War got based down. I down like i just think like the two-headed guys yeah sorry man picture anyway uh this i wanted to mention this is actually the chapter that like is that shares the name with the book right so we're finally talking about we've been building up all this time to the clean architecture and it really brings a lot of things together we've talked about the separation concerns we talk about the layers we talk about being independent of frameworks things should be testable it should be independent of a ui database um they should be independent of interfaces to third parties we've talked many

times about how dependency injection is really crucial to being able to do this. And now we're kind of all folding it into one single picture. I want to just wrap that, you know, come back to that though, because he said that we're finally in, you know, the book is titled the clean architecture. This chapter is the clean architecture. So we're finally learning how to do the clean architecture we are this starts on page 201 welcome to the beginning chapter 22 and we're finally getting to like oh this is the clean architecture okay that's awesome let's discuss this diagram that we are i don't know if you've heard but our ability to describe a diagram is amazing. Yeah, man. We're working on it. I will say it kind of sucks that this diagram is completely inverse of the language that you would use from high to low level components.

Okay. I thought about that. That drives me a little bit bonkers. Okay. First of all, let's get into the diagram. The diagram, as he titles it, is the clean architecture. The diagram, as the rest of the internet would describe it, is the clean architecture. The diagram, as the rest of the internet would describe it, is the onion architecture.

It looks almost identical, man. I was a little bit bothered that he never... He's been really good about citing references and whatnot and giving credit to other things or calling something out if it's already a known thing. And it kind of

like... I don't know. There was something that just irked me if it's known already a known thing. And it kind of like, I don't know, there was something like just irked me about it. Like, why are we not like facing, you know, calling out the elephant in the room here? Like, why are we ignoring that? It's pretty close. I mean, yeah. I thought you did mention it in the book. I didn't see it. I never saw it. I didn't see it. It wasn't said.

So, okay. We've been dancing around this onion architecture diagram in all of our previous conversations and with the high level and the low level conversations but i think i got a way to picture what you just described where you were like um were you saying like it's the inverse of how you would think of it maybe it's it's this uh concentric circles within each other because we're looking at it top down. But if we were to look at it from its side, maybe it's a cone, an inverted cone.

Oh, it's like a ziggurat. So it's like- Or the peak of it is the entities. Yeah, it's an ice cream cone sitting upside down on the table. So that the very tip of that cone is the entities. And as you go down at closer to the table that bottom layer that's touching the table that is your external interfaces because that's the interface that that

cone is making to the table i mean that that's that's a good description it's not how i looked at it but you make it you make a good you're right it's not how i looked at it either but as you guys corrected me on the higher high level versus low level, right? Like that was kind of in my mind, like how I was able to like make sense of it all. I was like, okay, it's a cone. Okay. I'll buy that. So let's hit it here.

So the innermost or the tip of the ice cream cone, which would be facing up towards you. Yeah, but we should say ice cream cone because you hold them upside down. Yes. Let's go ziggurat. I don't know what upside down yes let's go ziggurat i don't know what that is what's a ziggurat okay it's like the pyramid that has the steps like then and like a necropolis okay i'm gonna say i'm gonna say how about a street cone then what would you call this like the orange cones okay there you go yeah you would see like in a construction site or wherever they're trying to direct traffic.

Okay, there we go. A road cone. A caution cone. We don't even know what to call these cones. Dang it. It's a freaking ice cream cone that fell out of your hands. You lost the ice cream and the cone's sitting on top of the table now. Traffic cone.

That's what they're called. All right, a traffic cone. Here we go. So the innermost tip that is pointing up is your enterprise slash critical business rules. That's what they're called. All right. A traffic cone. Here we go. So the innermost tip that is pointing up is your enterprise slash critical business rules. That's what we talked about. Should depend on nothing. It is literally floating out there. It's pluggable.

You can put it on anything you want. The next ring in, so moving further down towards the road, the ground, as it were, is your application business rules. This is your use cases. Then your next fatter ring as you're moving down towards the ground is the interface adapters, your gateways, controllers, and presenters. And then the one that is touching the ground, these are your outer most layer here. These are your frameworks and drivers, devices, web, UI, external interfaces, DB, file systems, all that stuff. So as he put it, you're going from more abstract down to the details. And the details, even though it sounds really weird to say it, is the database. The details are the UI. The details are those things that you could literally swap out

if you wanted yeah and um just look at the go over real quick again so the entities we said that's the core that's the thing that's used by everything the next layer there was is the use cases and i wanted to call that out specifically because the use cases we said are application specific so that means everything past that point is application specific. Your gateways, your controllers, your presenters, application. Even your database, your external interfaces, your UIs, those are all application specific. The only thing that is not application specific is your entities. That's business specific. So again, looking at this thing top down then,

the entities are our innermost circle. They are the most general and they are the highest level within the application. Yep. So basically what we're saying is the inner circles are your policies. Your outer circles are your mechanisms. In the onion architecture, I purposely in the show notes, I put infrastructure in places because I love that terminology from the onion architecture, right? Databases, file systems, that's infrastructure decisions that you make. And I like that naming like mechanisms. I like, I like the notion that it's actually something you put in place. The inner circles, your entities cannot depend on anything that is further in the case of we're talking about looking down. It can't depend on anything further down from it. Everything at the bottom depends on everything at the top right that it the dependencies go up

not down and the outer circles cannot influence the inner circles so the things down at the bottom your your infrastructure your databases all that stuff it cannot dictate what your business entity is doing yep and then we're going to go over basically each one of those. They're not layers because it's not an onion. We're going to talk about each segment of the cone here. And entities are the core there that are shared between applications. They should be usable in many applications and should not be impacted. This is just what we said before.

They encapsulate the most general high-level rules. So calculating interest, right? What are some some other rules that would live in here encryption calculating interest uh order tax calculator yeah uh okay amortization sheets i have all kinds of stuff that just boils down to it right all right so next layer is use cases use cases are application specific and the changes here should not impact the entities and it shouldn't be uh impacted by details further down on the cone like uh you know what database you're using so uh if we remember those use cases you want to give an example of uh of those? A use case that came to mind was like batch processing of orders, right? Like if you have something that needs to be released to pick out on the floor or something,

that's a batch process that is very specific to your application, right? You're going to go through, you're going to print out paperwork and send it out to the floor or create some sort of digital report that people are going to go use well the example we gave before was if the um if the customer's credit score met a certain limit then you would create a customer object for them for that person initiate a new loan yeah initiate the loan yep and those details are abstracted So how we get the credit score, how the loan is provided, that stuff is at a lower level. This is just that use case. It's that description of what should happen. Yeah, so these use cases, they orchestrate

the flow of the data in and out of the entities. They're directing the entities to use that critical business rules that we talked about earlier to achieve the objectives of the use case then on to interface adapters these are the things that convert data from the different data layers to the use case or entity layers these are things like presenters, views, controllers. No code further in should have any knowledge of the database. I guess in our case, we would say no code further up. So the use case and entities have no knowledge of the database.

Right. And this is what we said right here. This converts data from data layers to use case or entity layers. That's where we were talking about every single layer should have its known request and response objects and so this translation of that data between those layers that's where this this would happen these interface adapters yeah and now we're on to frameworks and drivers which is um basically the uh the bottom of this cone here these are the the lowest details things these are the websites the devices um these are the glue

that hook up the various wait what did i skip something no i started saying something that's different notes i think what we're trying to say say is these are the glue that hooks up things. So like this is like an example is SQL Server. You're not writing much code in this particular layer, right? We use SQL Server, but we don't write it. We use Apache or IIS, but we don't write those things. So we're hooking up like IIS to the rest of our application so that it can be served up.

And similarly, we're setting up SQL Server so that it can serve up the data, but we're not really writing SQL Server itself. We're not writing Apache itself or IIS or whatever. And this is where the inversion stuff would happen too, right? Because it's like the entry point into your application to a certain degree. So if you have a website and you want your UI to, and your business layer to utilize data from a database,

then you're probably going to inject your SQL calls. Like you're going to create those classes that call to the database and you're going to pass those up to your business layer so that the business layer can just say, hey, go get me account data or go get me customer data or whatever. This is why it says this is where the glue is. This is where the inversion happens.

No, no, no. That's the adapter though. What you're describing is the adapter. This frameworks and drivers, these are all the tools that we're using. These are the lowest level tools that we're using. These are those. These are the lowest level tools that we're using. I don't think the we're going to run on Apache. We're going to we're going to run on Apache. We're going to use Oracle and we're going to configure Apache to serve up our application.

And we're going to configure Oracle to serve up our data. Like, though, that's the gluing that's being done because he makes the point like you're not writing code in this section. And then what you described, you are writing code. And you're writing a decent amount of code to do that part, right? That's the interface adapters. Okay. Yeah, I got fed off when I saw the word glue. Because when I saw glue, I immediately started thinking, like, wait, that's how we connect layers with glue, right?

Right. But not the case. wait that's how we connect layers with glue right right but uh i i think that's where and this is where by the way i've gone looking for code examples on how he's done this stuff and i and i'm going to continue to look because i would love to come back to this because this layer this layer is are the details that don't matter these are the details that we defer which web server we're going to use Which web server we're going to use, which app server we're going to use, which database server we're going to use.

These are the details that we're going to try to defer for as long as possible. And we will eventually wire them up, right? We will eventually install something, configure something and use it, right? But we're going to hold off on that decision for as long as possible. That's what the frameworks and drivers section is okay yeah i think i got hung up here because i kept thinking like

okay well where's my website then on this on this chart and it's like oh it's not it's not really reflected here because it's got use cases it's got controllers it's got ties into database and web here like it this isn't a drawing of those sort of things. This isn't a component diagram. This is a layer diagram. Right. The one above it is the one, like, where the controllers are. That's what's going to do that kind of stuff.

That's correct. Yeah. All right. So, then we have this whole notion of crossing boundaries. So, this is when they talk about the flow of control went from the controller through an application use case and then to the presenter. So they had this diagram that shows this. And what they're trying to show is from going between the layers, it starts in the controller, which was in that, not the bottom layer, but the one just above it. It goes from that.

Then it goes and calls into a use case, which is up in that second layer. The one that's not the entities at the top, but the one below it calls into a use case. And then that brings stuff back out into the presenter. So that's where it shows it moving up the chain and then coming back out and, and hooking that data in. Yeah. And, uh, we, once again, we're coming back to dependency inversion. We want those source code dependencies pointing in towards the use cases, not the other way out. We don't want those use cases to have ties into the outermost layer.

So that's where we're going to get around that with a dependency inversion, injecting those things in there one way or another. Yeah, I tried to spell this out here. I don't know. Let's see. So you have a use case, which is your second layer, right? That's not your top one, but that's the one right below your entities. It needs to call a presenter,

but you can't do that because your upper layer cannot call your bottom layer, right? It's not allowed to reach down and know about those detail, those implementation details. So they can't know about those outer circles. So the use case would then need to call an interface. It would basically have some sort of interface that it knows about. The implementation of that interface would be provided by the outer layer, or maybe in the case that you were just talking about, not that most outer layer, but that second one where the controllers and all those things live, that would be provided from there.

The interface adapters. The interface adapters. And that's how the dependency is inverted. So you have this use case that's depending on i what encrypt we'll call it we'll call it i encrypt right it doesn't know what is actually going to do that it's just going to be past something that fills in that contract so that controller is going to pass in let's call it a shaw 256 encrypt wait wait wait wait wait no let's not's call it a SHA-256 encryptor. No, wait, wait, wait, wait, wait, wait. No, let's not confuse that because in that case,

encrypt was our entity. Yeah. So our use case was going to be to take in like a reader or a writer. So the reader or writer, no, because that had to be at the entity level too. What was the thing? Set up a customer. Let's say set up a customer as a use case, right?

Set up a customer. Okay. So iCustomer. iCustomer. iCustomer is going to come in or iAccount, iNewAccount, something, whatever. It doesn't have any implementation that it can use, but it's going to be given an iCustomer object from down in the controller. And so that controller is going to be what knows what kind of iCustomer object

to create, be it a factory or some other type of mechanism. And it's going to give it to that use case layer. And that use case layer is going to be like, all right, I have this iAccount object now. Let's call.create on it, right? So iAccount.create. If everything passes, it doesn't know about the implementation it's just going to let that stuff flow back out and i think that's that that's that's inversion of control is literally again you mentioned earlier it doesn't have to be an interface it could have been an abstract class you could have had a base account right or or something that that polymorphism is affected by is really polymorphism man and you know what that's that's something that i honestly feel i

don't know about you guys but i feel they did such a disservice in in school is the whole talk about polymorphism was centered around making objects conform to it. But they never gave you a good reason why. Other than, hey, it's a roadmap. Like, that's literally the answer I was always given was, oh, well, you want, you know, if there's a click event that's available, then everything should have the term click event. And I was like, man, that seems kind of...

Right, it's about attaching behaviors to things. It's like, oh, just implement stuff. So you get work for free. Yeah. No, that's not really what that's for. That's not the purpose. And that's really where,

like, if you want to take polymorphism as what it, what it's very useful for, it's this, it's literally being able to flip things on its head and say, okay, instead of me dictating what's going to happen, how about you tell me here, here's the thing that you want me to use and I'll just use it

because I know how to use it, right? I mean, one case that I was thinking about this, again, in that use case example, that interface for the iCustomer is going to sit, the definition of the interface is going to sit next to the use case in terms of in terms of the levels here the implementation of the iCustomer interface will exist below that in that adapter interface or interface adapter level right and instead of you know one advantage of using the interface instead of a concrete class would be you could kind of have some a little bit more control over like how something has happened. So maybe if you wanted to say a name property, maybe it just returns back, um, a string as it is, or maybe it does some kind of computation to say like, Oh, you know what? I'm actually going to concatenate all of the, you know, the first name and the middle name and the last name,

uh, with a space in between, uh, you know, and if there's not a middle name, then I'll only have one space, right? Like, so it's going to, it's making those kinds of decisions, right? Like that's what that, that's an implementation detail in that interface adapter that is deciding. But because you only had an interface, you had a little bit more freedom in how you decided to make that, right? At least like in a C sharp world world because you could have that interface defined name as a property and you know yes technically behind the scenes it's going to create a method the same as what you might have to do in a class abstract class equivalent but you know at least from the syntactic sugar it's going to it's not going to look like that it's just going to look like that. It's going to look like one is just a simple property,

almost like a variable when in reality it's not. So data crossing the boundaries. This is getting into the areas that I was describing before about the DTO. So typically data crossing the boundaries consists of simple data structures, which I keep referring to as DTOs. Or POCOs or POJOs. A POCO has behavior though, right? No, no, no.

That's like a POCO or a POJO. That's a plain old Java class or Java object or a plain old C-sharp object, right? And I mean, when you think of those, when you think of a class, you typically think of something that has behavior, right? So this is where I guess it gets to be a little bit, I don't know, maybe it's a holy war, but I've definitely had disagreements with people where I'm like, no, no, no, a DTO is just a simple data transfer object. That's when it's just data only.

There's no behavior to it. When I think POCO or POJO, I think a class, an object that can have behavior to it. But that's irrelevant, at least to this point, as far as the data crossing. The point is that these are simple data structures. So if you're in a C world, for example, it just be a struck right that you're passing back and forth dto is more appropriate just looking at what some people define it here it's a dto is a class representing some data with no logic in it right that's what we're talking about a simple class it's it's a bag i've i've heard it as a bag of properties yep that. That's essentially what you've got.

Yeah, I just think that difference, like the only minor difference is just its intent. It's intended to be used to move data. Yeah. So I don't think that's a real important distinction. That's the only difference between that and Poco. So if I say DTL, I'm generally meaning this thing is going to travel. Yeah. poco so if i say dtl i'm generally meaning this thing is going to travel yeah so well but but the point here i'm trying to make though is that like going back to the c example like it doesn't have to be an object at all it doesn't have to be a

class it could be a struct right right it's just it's just as you know it could it could be a json object it's just some data that you're passing back and forth. Um, you know, God help you if you write it in XML. Right. I curse you, but I could validate it. Oh,

right. Everybody uses DTDs. Right. So this goes back to the conversation we had before about like not passing the entity objects. Right. So, or the,

or the data rows back and forth, right? So passing entity objects would be coming from the center of the circle out, or the data rows would be going the other direction, coming from the outside of the circle inwards, right? Or if you think back to our cone examples, the entity objects would be going down the cone towards the ground, and the data rows would be coming up towards cone uh towards the ground and the data rows

would be coming up towards the tip of the cone um ziggurat yep yeah or that made up word that joe keeps saying a wedding cake okay that's like a ziggurat okay okay i got it i know what you're talking about you're talking about like the mayan looking pyramids right yeah yeah i got you all right i'm there all right the ziggurat um yeah so so ideally we don't want to pass those around because then we are leaking uh a dependency if we do that and we want to keep we want to keep those dependencies isolated or insulated as i said earlier no you won't you won't yeah no he will don't do it you can do it don't don't do it but if you do do it just know that you're going to violate the dependency rules that we've described yeah so don't do it do it don't don't do it but get it done and just go ahead and do it. Yes. No, don't do it.

Do it. All right, so data is passed in the format that is most convenient to the inner circle. So if you are in the use case ring and you're trying to pass data to the entity, then you're going to pass something that the entity knows about. And this is where I was coming up with the idea of like, okay, well, that means that the entity has about. And this is where I was coming up with the idea of like, okay, well, that means that the entity has to define the interface.

It doesn't implement it, but it defines the interface or the abstract class that it expects the data to come in as, right? And similarly, from the use case, you know, ring, if it's coming from the controller, then the controller is going to pass the data to the use case in a way that the use case, you know, ring, if it's coming from the controller, then the controller is going to pass the data to the use case in a way that the use case knows. And that means that the use case has

defined the interface that it wants to be met, right? And these data structures, these are simple, they're isolated, they stay within their level. So this goes back to, I think Joe made the point about like, you know, hey, if you have this, this, these four layers, then you end up with these eight request response models, one per, you know, for each layer. Does that make sense? Yep. And when passing the data, it's,'s oh i already said that was in the form of the most um convenient so this is where it comes back to um you know again that the dto's

our dto this means that our dto's when crossing the boundaries they belong to that inner circle like that going back from the you know the if the entities is the most uh center circle and use cases is a ring outside of that then the entity knows the dto it has that definition of it but it sounds like just it sounds like each layer would have its own set of DTOs, request and response objects. And then to marshal things into a more abstract class, the lower level class, the one that is more detail or closer to the inputs and outputs is going to know how to translate that data

into that upper or inner layer. That is my understanding. Each layer would know how to do the translation to the next yep and you know the thing that works about that traffic cone example again like i kind of described this before was that that um when i said the cone touching the table like that it touching the ground is an interface right so like only the bottom part of that cone, which would be the outermost ring of the circle knows, uh, the details of touching the ground. Is the ground wet? Is it mud? Is it concrete? Is it tar? Right. Like as an example. Yep. Yeah. It's again, I think when we started all this, you know, there were a lot of things that were thrown out in terms of statements that they weren't clear. But I'm thinking, at least along the way, I know when I was reading all this, it started becoming a lot clearer.

Oh, yeah. As he got into all these ones. And I mean, we've talked about a lot of stuff. I mean, we're two hours and probably 15 minutes into this. So, you know, hopefully this is all making sense. I mean, like I said, just reading this book has given me a much stronger understanding of domain-driven design. I mean, that seems crazy. One book helped you understand the other. At the time, we even said that we wanted to go back and reread domain-driven

design after getting laid in the books. Like, okay, I'm starting to kind of get it. Let's go back. Yep. And so wrapping up this one, one of the things that he points out at the end of this particular section was conforming to the rules is not that difficult, but it does require you to mentally take it on, right? Like you have to be thinking about it as you're doing it. And if you do that, if you take the time to do it, then it'll set you have to be thinking about it as you're doing it. And if you do that, if you take the time to do it, then it'll set you up to be able to plug and play these things as you move along, which may not sound like much until you decide that, hey, my site's slow because my database is slow and we need to be able to plug in something to make it faster, right? Like having

those separations can really pay off dividends in the future with smaller pains. And because you're removing dependencies from the layers, then it makes things more testable. Yep. We've talked about testability being, you know, easier to maintain. It's more bulletproof. You feel more comfortable making changes, especially big changes, because you have tests to back up whether or not what you did worked or broke something. They give you confidence. Yes, that's the word I was trying to look for. Thank you. Yep. So that basically wraps up those sections here. I think we have a show summary, so we'll do that later. So resources, this chapter actually pretty much

sums up the whole book. I feel like it really ties in all the advice, kind of brings it all into one spot into one chapter. So if you only read one chapter in the book, let's say read this one and then kind of dive in. Skim your way back. Yeah, this did really kind of tie a bow on it. So obviously one of the resources we like is clean architecture. And don't forget, if you've made it this far,

that we do have a contest on this one. So if you go up there to this episode, episode 75 and leave us a comment on there, you can be entered for your chance to win your own paperback or Kindle version of the book. And I'll tell you, Uncle Bob is a lot more eloquent and well-spoken and organized than I am. Oh, man. If you liked what I had to say about it, you'll love Uncle Bob. Yes. Oh, man. All right.

So with that, it's my favorite part of the show, and that is the tip of the week. Yeah, and I'm going first here. I wanted to mention a kind of a problem that I ran into the other day, sending some emails. Had a real weird issue where certain email clients weren't getting image embeds.

If you've never done image embeds before, the concept is really simple. You basically send an attachment, but then you kind of tell the email like, hey, listen, that attachment, it really goes here. It's an image. And there were a couple of problems with it, but the main ones I was dealing with was actually on the iPhone. And back actually Outlook on both of those guys was being weird only on like iPhone and Mac. And so I thought it was this I thought was that I tried a bunch of different things. And it ended up being the stupid, stupidest problem in the world. I had a mime type with a period in it, which I know is wrong. It wasn't intended. It was just a bug, but it worked everywhere else. But not in these very specific things.

And actually, when I read into it too, I happened to notice that the MIME type for JPEG is JPEG. And it doesn't matter which extension you're using. That's always the correct, the MIME type. So I don't know if there's any good MIME type libraries out there. I'm sure there's like NuGet package, if you wanted to bring that in or you know an npm package or something but i just thought it's kind of interesting and if you've never dealt with mpeg with mine types before it's basically just a way of kind of classifying your data and saying

hey this is a bitmap image or this is a mp3 file or something there's actually a big list of like i think it's iso standards of what all the the ones are but you can't take it for granted. That's just going to be the file extension. And you definitely can't include that period. Nice tip. All right. So for mine, I'm going to give a team city tip here that I ran into where I discovered that if you had,'s say you have a Visual Studio solution that contains a lot of projects, and you only want to compile certain projects within that solution at a time to maybe have multiple configurations, and each one is just targeting a specific project

so that you don't have to build necessarily the entire solution, but only parts of it at a time that you care to build. Within TeamCity, you can set your target to be the project name and then do something like build or rebuild or clean or whatever. Say you have a project that's called my project name, you could say my project name, colon build, and it'll target just that one project name and build just that one project out of the entire solution. And you might have like, you know, 100 and 100 projects total in that solution, for example. But here's where the real problem came in. In my case, I had a project that had spaces in the name.

So it was my space project space name. And I wanted to build that. So thanks to our amazing Slack community, what I learned was if I did my percent percent 20 project, percent percent 20 project, percent percent 20 name, colon build, then team city would properly build just that one project out of the entire solution.

So it was crazy weird. It's not like I had to double encode the percent, but I basically had to escape the percent with a percent. So that's, that's how that worked. But I wanted to say thanks to, um, the, uh, Slack community, Critner, Sean, Robert, and Aztec that helped me, uh, figure that one out. Cause I was definitely stumbling on it and, uh, you know, big thanks to them. yeah our slight community is awesome truly yes and if you're not a part of it you should definitely uh join you can head to www.codingbox.net slash slack man what are you listening to over there yeah what is that are you playing a game? No. You lie.

You lie. Alright, so. Maybe we want to play. Yeah, exactly. Alright, so my tips. I don't understand. Is it my phone? Anyway, well.

Does it start? You really don't hear it? Whatever it was? It sounded like, almost like a cash register no not now yeah i definitely heard like he was definitely cashing in something because you'd hear the register ring every now and then yeah anyways all right so mine actually i have a few here two of them are basically the same so with this whole abstraction you get one i can't do it man these these are like state of consciousness as soon as they're gone they're gone so one is the common common logging

abstraction for dot net it's a new get package i have a link in here but it's really nice because along the lines of what we were talking about you don't want to leak your your implementations all the way into every layer of your thing and the common logging for abstract the common logging abstraction allows you to just have interfaces and abstractions that you can include in your projects and then whichever logging framework you want to choose whether it be log for net um oh wow there's one that you mentioned recently that was pretty good jo, that you said has been getting a lot of potential. Sir, sir, sir. Oh, yeah.

For you now, sir, sir, sir. Something like that. Yeah. There's also there's other ones and log whatever. But but the key is here, you can just include the interfaces, the abstractions, and it will work. So like that, my buddy, Will Madison had mentioned SLF4J previously back when we had talked about this a while back, and that's an abstraction

in Java for being able to do the same type thing. So I have a link for that one as well. And then the other thing I want to say is, so I think it was the last episode. I couldn't take it anymore. So we had the paperback version of, of clean architecture simply because that's all that was available when we started reading the book, if you guys remember correctly, some, you know, four score and 20 years ago. And I couldn't take it because I'm typically reading in the dark and I don't like having lights and stuff over me. And so I bought it for the Kindle, which was awesome because I could read it on my Kindle. And then when I was going to do the show notes the other night, I was like, wait a second, I don't need my Kindle next to me. You can read it on the web. So in case you didn't know,

you can go into your Amazon account. I mean, a lot of people probably do know, but if you don't go into your Amazon account, there's a under the the pull down over there where your orders and stuff are and there's a place for content you can go see all your kindle books in there and you can say open it up and read it on the web so you can have it as another tab in your browser so if you're wanting to read and do some research or whatever you don't have to have multiple devices sitting around to do it so that was my other tip. Well, you can also go to read.amazon.com. See, not everything.

No, not everything works there. And that's what's frustrating. I've tried that in the past. Some books won't load up on read.amazon.com. Why? I have no idea. But this one does. I have some books that didn't. but the one that, oh wait,

it did open it up in read.amazon. Okay, so now I take it back. You're correct. So I used to have books that wouldn't open up there. Read.amazon.com. We'll leave the link there. Oh wait, you removed one of your things because I had a note. Did I? I pasted the link

in for Sarah Log, which is logging but i might have deleted something i thought you were going to talk about um email addresses oh oh we were going to mention that too okay so this one's this one is sort of just a random thing that we were going to discuss because we started to before the show but it might be useful so i brought up one of my tips was going to be hey if if you have in your application where you're having to take in email addresses, a lot of people would just say string email and then have some sort of regex validator that they run against it that they copied and pasted from Stack Overflow. Right. There's another way.

There's a C sharp class called mail address. And I think it's in the system dot net dot. I don't remember what anymore here. I can tell you right now, the namespace, it is system.net.mail namespace. And it's called mail address. And this is a way that you can get validation, but it also breaks things out to where you can create an email address that

will give you back a host, a user, a display name, and an address. So, and you had thoughts. Specifically, what you were going to say was that if you wanted to use it as a way of verifying an address, if you try to pass in a string to it, it'll throw an exception if it's not a valid format so basically it was like a cheat to use that thing as a way of describe you know knowing whether or not the input was a valid email address or not so even if you don't want to send an email you just like new one up and see if it fails as instead of saying like mail message dot validate or something because there isn't like a validate method you just create a new one and see what happens yep and if it throws then you're good so just try catch the thing knew it and and you've got whether or not it's a real address or not so pretty cool so so one of the things that

we were talking about was like okay if you were going to um you know how might you do this if you were going to write it like kind of where you were coming from is like a lot of people just take that well i can do this myself kind of path and they'll try to write their own regular expression or something similar to that right now have you ever seen the official spec for that uh you mean the like the properties constructors all that or you mean for an email address for for validating an email oh yeah it's ridiculous and almost nothing does it right i'm gonna see if i can get this thing to cooperate with me here if i can do. Funny story while you're doing that. I had one of the VWs in the buyback program for Dieselgate, right?

And typically when I sign up for any kind of service, I usually use my Gmail plus and then whatever the name of it is. So it might be my email plus VW, you know, and that's because Gmail will allow you to do a plus and anything that you put after the plus will still get routed to your email account. But now you can set up filters for it, right? Man, I can't tell you how many times that's caused me a problem over, over the years, because what you're probably about the show is most people don't do email validation properly and on top of it they don't encode them properly so if they're doing get requests with them then that plus doesn't come in properly and it jacks up requests i literally had to go in and

hack the vw claim site to make my thing work because I used that email address. I had to troubleshoot the problem to a person on the phone and be like, yo, this isn't working because of this. Will you please go in and do X, Y, and Z. So here's, here's the thing.

The, the spec for RFC 5322 is insane. And you are insane. If you decide to write your own, you really shouldn't. And that's why you should use something like the mail address class that Alan was describing. So the worst offending went on here is definitely the Perl implementation. If you were to try to write a regular expression, and this only works says 99.99 of the time it'll work that's how crazy the the spec is for it um how many characters do you think the regular expression is for pearl um oh i feel like i knew this no don't don't don't looking it up Oh I feel like I knew this No don't look it up

I have no clue man I'm going to give you a link in a minute Oh my No way Oh man you looked I couldn't help it You're like a little kid man That's ridiculous

I'll put it like this I can't even count it I'll go ahead and share it with, uh, with Joe here. Uh, where's Joe at? There you go, Joe.

Now you can see what we're talking about. The Pearl regular expression to somewhat verify an email address. Most of the time is 6,499 characters long. And that's why you shouldn't try to roll your own. Man. And even then, it's only 99.99% of the time going to get it. That is insane. There is no 100% solution, is there?

It's basically just send an email, see what happens. Pretty much. Did it bounce? No. Right. Okay. Yeah, man. That is insanity right so if you think you got clever

and you wrote like a regular expression in your javascript that was like you know for some stuff and then at and some stuff and a dot and some stuff like you're gonna get 95 but you don't even have to have a dot in that last like you're gonna get 95 percent of the way there but you don't even have to have a dot in that last one do you i can't remember maybe not you're gonna handle uh yeah i'm gonna say that 99.9 percent of email doesn't do i mean don't like don't like definitely use the library don't get me wrong absolutely absolutely but maybe i'm telling you no just don't do this but if you're going to do it but don't do it go ahead and do it we'll approve it yeah so yeah definitely don't do it um but uh it's funny

that it's so complicated but like yet i feel like all three of us could easily like look at you know just about every address email address we've ever seen in our lives and been like thumbs up thumbs down with like 99.9% accuracy. You know, that's funny. You're probably right. You're probably right. Although there are some obscure rules that you just don't know about. If I go look for obscure email addresses, then I'm sure I could find some.

Yeah, man. So at any rate, yeah, the mail address class. If you didn't know about it and you do.NET development, C Sharp, VB, whatever, you know, be aware of it. It could help you out. Yeah, and don't be that person that has the weird address. Don't do it. Yeah, Alan.

Hey, man. I just tried to leverage what Google gave me, man. That's all I'm doing. With a weird address. The plus sign. I just leveraged it. All right. So, yeah, we've covered a lot in this show we're not gonna go over it again we went over it a lot we talked about stuff yeah uh screening architecture and use cases and policies and crossing boundaries and uh yeah so stuff and stuff. And with that,

we ask that you subscribe to us on iTunes, Stitcher and more using your favorite podcast app. If you happen to be listening to this because a friend might've pointed you to it or, uh, whatnot and be sure to give us a review by visiting www.codingblocks.net slash review. And while you're up there,

check out all our show notes, examples, discussions, and more. And send your feedback, questions, and rants to the Slack channel at codingblocks.slack.com. And be sure to follow us on Twitter at Coding Blocks or head over to codingblocks.net

and you'll find all our social links at the top of the page.