Coding Blocks - Software Architecture – What is Supple Design?

Episode Date: July 27, 2017

More Domain Driven Design talk this week: Supple Design, Declarative(ish?) Programming, and Ohio Envy. Sponsors FreshBooks.com/Coding – Use code “CODING BLOCKS” in the “How Did You Hear About Us?” section GetAirbrake.com/cb Linode – Use code “CODINGBLOCKS17” for $20 towards hosting (up to four months free!) Start Slack’ing Now. We’re so happy you’ve found us and […]

You're listening to Coding Blocks, episode 64. Subscribe to us and leave us a review on iTunes, Stitcher, and more using your favorite podcast app. Visit us at CodingBlocks.net where you can find show notes, examples, discussion, and more. Send your feedback, questions, and rants to comments at CodingBlocks.net and follow us on Twitter at CodingBlocks or head to www.CodingBlocks.net and find all our social links there at the top of the page. With that, I'm Alan Underwood. I'm back, Joe Zach. And I'm Michael Outlaw. This episode is sponsored by FreshBooks. The all new FreshBooks makes ridiculously easy accounting software that's transformed how freelancers and small business

owners deal with their day-to-day paperwork. It's been redesigned from the ground up and custom built for exactly the way you work. FreshBooks provides the simplest way to be more productive, organized, and most importantly, get paid quickly. Getting started on FreshBooks is extremely simple, even if you're not a numbers person, especially if you're not a numbers person. Now when you email a client an invoice, FreshBooks can show you whether they've seen it. This puts an end to the guessing game. The new notification center is like your personal assistant telling you what's changed in your business since you last logged in and what should be dealt with like overdue invoices. This lets you

focus on what's needed to get done and help you get back to your work faster. 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, here we are with the podcast news. First up, iTunes reviews. Big thanks to Angela Gallo, 44, J. Belmont, 80, Polymathic,

Chirag, 926, TonyB0312, Mark2457, Juice to Palm, and Teddy Y. Someone take Stitcher. Yeah, Mike, you want to do this one? These are pretty easy today.

Thank you. From Stitcher, Roy, APNet, and Nick Assembly. Very nice. Thank you to all of you guys that took the time to, guys and gals, that took the time to leave us a review. We super appreciate it. Very much. Yeah, for the full show it's a show notes show notes visit codingblocks.net slash episode 64 yep and we had

some fun news this time didn't we joe yeah i had some visitors here in orlando so not only has alan been around uh visiting disney with his family but we also got to meet Andrew Diamond and Casey yeah had a great time I really enjoyed them coming out it was fun that that guy's got a very bright future ahead of him so um thanks for coming out hanging out having dinner with us and definitely look forward to meeting more of you folks as time go on and thanks for all the help with everything we actually um we have a lot of really great people in slack and uh andrew diamonds one of them and actually i've got to say i've got a little bit of ohio envy because i know we've got a lot of people uh in the ohio region up there um you know angry zoot uh sean um sorry to living ryan everyone i'm forgetting but

really appreciate you guys uh being awesome slack and just being awesome in general so it's nice to finally uh meet one of the ohio crew yeah the ohio crew actually have their own channel in slack just for uh them hashtag jealous yeah right they all want to be around lebron that's my story and i'm sticking to it and because these guys don't do sports at all they may not even know who I'm talking about. I was like, wait, what does that have anything to do with how did we get to sports ball? Oh, man. All right.

So in the last episode, we covered, obviously, we were talking about DDD, and we talked about the specification pattern. And I think I completely lost Michael on that one. And so I mentioned that I was going to do a video. I haven't quite gotten that part done yet, but I did create the code and that is available on our github page at github.com slash coding blocks and I will be doing a video where I actually talked through the specification pattern at least starting out for valid not necessarily validation but making sure through the specification pattern, at least starting out for valid, not necessarily validation, but making sure certain requirements are met. And then maybe in the future, I'll even go into and talk about maybe doing the selection via the specification pattern. So look for those coming

soon. I will have them up on YouTube and we'll share the links out as soon as we have them. And the next thing I want to mention, even though it looks like we're running out of time and the site wasn't clear to us or me specifically. So this is my bad for asking too late, really. But if you guys wouldn't mind, we don't ask for much, but if you go to podcastawards.com, we'll have a link in the show notes here but if you'll go up there and nominate us for either the education or the technology section that would be amazing apparently they have two rounds of this stuff one is the nominations and then the second is the voting for the the ones that were nominated so i didn't realize that and that's my bad we'll probably

send out a newsletter with this as well but if you guys would take the time to go up there and sign up and nominate us that would be amazing yeah we really want to go viral here guys so uh you know we're trying we're trying to be we're trying to be beavers right so we really appreciate those votes and thank you yes totally and then did you say we're trying to be beavers uh i is it believers um oh beaver it's yeah it's beaver i got it right yeah beavers jordan beaver believers um wait but nothing moving right along all right and so doing the specification thing, I did find an interesting article the other day. So,

um, when outlaw and I were talking about the specification pattern, apparently this is a deep thing here. He mentioned that, well, you'd only do this with, um, you know,

particular collections or whatever. And I was like, yeah, totally. You do it with a local collection. Well, I actually found an article where somebody had modified it to work with in Hibernate. So you basically specify, you create your specification

and then that could be used using expression trees in C sharp within Hibernate. And so your specification could actually query your data for you using that ORM. So that was a really interesting take on it. So you can, if you want to go a little step further, you could use specification to query external collections that you don't necessarily have in a list or an IEnumerable or something. And so I thought that was interesting. We'll have a link in the show notes here. So check that out.

Nate, the DBA is probably cringing at the thought of something else, writing the sequel for him. Right. If anyone's going to do it, this guy looks like a pretty good candidate. He's written a book on F sharp. He's an author on Pearl site.

I saw the MVP for F sharp. So, I mean, if anybody could do it, it's a, like a functional person, right? Yeah, it's pretty cool stuff. Yeah, it looks really cool.

So, in other news, we talked about DreamHack last episode. We talked about that was coming up. So that has come and gone. And if you weren't there, man, you missed the excitement. It was so amazing to be there. Three days of nonstop gaming competitions, all kinds of different games that were going on,

anything from like Pokemon and Magic to Halo and League of Legends and Rocket League. It was it was awesome. Yeah, it sounds great. Did you win anything? Uh, well, okay. So you want to say like, did I win anything in regards to like the games? Like, you know, but no, maybe not in that regards, but like there were other things like, uh, so, uh, my son was brought up for the, um, my oldest was brought up for the, uh, in the halo during the halo finals, he was picked out of the audience to get up on stage for a Halo trivia and he won that by keeping his mouth shut.

Oh, very cool. That's awesome. So he was really excited because he got like a nice set of headphones that came with an amplifier and everything. Oh, nice. Excellent. Excellent. Oh, we got some sad news next we do dev boot camp is shutting down uh they sponsored the show a while back and so uh that's a bummer and uh if you actually look at the comments of

reddit or the news article uh what the uh hacker news article i've linked here i mean see a lot of the interesting stories and comments that people were talking about. A lot of people were sad to see them go. I didn't actually see any negative comments. I kind of expected to see maybe some people who were angry at not getting jobs or feeling like they got ripped off or they lost something or maybe some people who had hired

some graduates and had a bad experience. Actually, all the comments I saw were positive, which is really surprising to me, given Reddit and Hacker News. Yeah, I agree. Even a hater is going to hate. That's right. It is sad.

You hate to see. And apparently they kind of started that whole industry, right? So, yeah, you know, best luck and wishes to the people that are moving on from there. Yeah, and what's weird is, like is the university here, University of Central Florida, is actually offering boot camps now. So it's kind of funny to see how much that influence has spread. And so it's definitely a bummer to see them go. Yep.

Oh, one other thing. They were ahead of their time. Yep, exactly. You always want to be the second, right? Unless you're Facebook. I don't know MySpace. Oh, oh right you chased it back a long way like friendster before myspace though yeah it's all leapfrogging you can't win yeah i did want to mention uh paul spoon wrote an interesting article about um what he called a mechanized approach to architecture that was really interesting and uh i'm just gonna throw

out that little teaser let you uh click the link in the uh show notes here but it basically it focused on kind of um deliverables for uh architects and um you covered some really cool topics too and i'm really looking forward to read more on the blog and it kind of ties in with some of the stuff that we're kind of talking about big picture tonight so i wanted to throw that out there but i will have a link to the show notes but you can also find it at spoon.codes. Very nice. All right. And with that, let's get into the meat of the show today, which is continuing on domain driven design.

And for anybody that's wanting to follow along in the book or if they want to pick up the book and come back here and revisit again, we are in chapter 10 and we're picking up with assertions this time, which I believe was page 255. And so we're going to try and finish off this chapter and then we'll move on to other sections in one of the upcoming episodes. Like how specific you are. Like not only what chapter are we in, but this is the specific page number. We're going to be looking specifically at paragraphs 1, 3, and 7. That's right. That's right.

Skipping the rest of it. So yeah, that'll help you guys follow along a little bit. So some of the key points here with assertions, and I know all of us here on this show are fans of this because it basically ties into testing. But you need the ability to understand the meaning of a design without digging into its implementation. And that's key. We talked about it with clean code. We've talked about it several times. If you have to trace through the code, then something's wrong, right? And assertions help with that because especially Michael had in the previous episode where we talked about testing,

he talked about the pattern that he does when he's creating his assertions for his tests. And if you follow the naming conventions, it's really easy to see what's going on. So another part of this that helps is that intention revealing interfaces. We talked about this last time, but basically if you name your methods in a way that lead the developer to understand what's going on, then you can use that. And here's a key part, assertions or unit tests or whatever, they describe state. They don't describe the procedures, the process, anything. It is talking about state only. Okay. So when I, when I think of the word assertion, I kind of think of one of two things. Like one is if we're talking about unit testing, there's a little assert function

that I can call that kind of says this is true. And then it kind of percolates up to my test runner. Now, the other way I think of is I think it was an old C++ keyword or something, but is basically you can call a function, give it something that should evaluate to true. And if it's not, it's going to throw an exception. So you can use it to kind of guard code. So you can say like assert something is not null or assert this equals that. And then, you know, if that condition is false, then the program is foobarred, right? And you got to stop, you got to stop execution. So that's what I think of. Are we talking about the same thing here? Yeah, we are. As a matter of fact, one of the things that he points out in the book is

if you are using a language like Java or C sharp that doesn't have the assert keyword in it, like, you know, as part of the language, then that's where you use something like automated unit tests. So in your case, what you're talking about with like C plus plus, that would be part of it. So you could ensure the pre-state and the post-state. And so, yes, that's exactly what we're talking about. No, I also use, I do something a lot.

This is a big pattern of mine. I'll do an if. If something is null, then I'll throw an exception. So it's just a little bit more explicit rather than waiting until it fails somewhere down in the next five lines. I get some sort of generic message. So I like to have something more specific. But I also like to do it in some cases where I like to validate my assumptions. Like an example I just ran across recently i got um some data in and it had like an event type id

an event id current create day was basically a data table and i knew that every column was the same except for the event id column and so i knew that i could just get the top one say create date and that was going to be the same for every other row. So I didn't have to, you know, loop through and I could just kind of grab that once. And just because of the nature of the database I was using, that data was duplicated per row. But what I did is rather than just kind of like blindly assume that I put a little if check in there to make sure that the column only had one unique value.

And if not, I would throw an exception because I didn't want to mess up the data in the system. And it sounds like this is a similar type of thing. Yeah, that was like a precondition check that you were doing before you actually operated on the data, right? But I just did a crappy if check. I'm kind of wishing I had like a more formal method because then I could search the code base for this more formal method and actually see all the places that I'm doing this. Well, not only that, but it would make the intent more expressive, right? And then, and there was this great quote that started off this,

this section where, um, kind of along the lines of making it more expressive, where he says assertions make side effects explicit and easier to deal with. Right. And so when we were talking about, you know, you brought up the example of unit tests and doing the assertions there. Uh, I, I hadn't really considered my assertions in that regard that they were like making the side effects explicit. But it makes sense, right? Because that's really all you're ever doing is you're checking the state of an object at the end of whatever procedure is called. So yeah, it does make a lot of sense. And when you name them properly, it helps out a lot.

So he also says that you state the post conditions from the operations and the invariance of the classes and the aggregates. So basically all he's saying is anytime that you're making any operations, because your aggregates are what are in control of the variance for everything that it encompasses, right? So having these assertions there will help you state these things in a way that people can understand. And to your point, Joe, the other thing was, you know, if the language doesn't support the assert keyword or an assertion, then, you know, this is how you do it with automated unit tests. So as you're writing your code, it's constantly building that and these things can pass. And I think it's worth saying, and we've said it before

in our episode on unit tests, 100% coverage may not be as important as covering the needs that you want, right? So if you're going to write a unit test, make sure that you're covering all the bases for that unit test, not necessarily that you're just trying to make sure every single method has coverage. You know what I'm saying? So if it's important that you don't allow a negative number or it needs to be handled properly or if it can only be a positive number or if it can't be zero or whatever you need to make sure all that stuff's covered you know yeah you know this reminds me a lot of coding by contract which there used to be a lot of buzz around a couple years ago and you could actually look in c-sharp particularly like you could kind of there were

libraries that would let you uh like drop annotations in that said only positive numbers are only negative and it would fail things if it tried to even enter and actually just for the fun of i just googled like c-sh sharp code by contract it turns out microsoft actually built a lot of stuff into um the systems not diagnostics library so there's actually a whole contract namespace that has things like contract that requires you can say like x not equal null and it'll throw an exception if that's it's false and so it sounds like there's a lot of stuff kind of built in it's just not called assert okay well no no in the in the um system dot diagnostics namespace there's also a debug dot assert so you can do these assertions in your code but because this was actually something i was going to bring up was that um you know in this

in this chapter he doesn't really specify if this would be in your production code or in your debug versionary code. But when we talk about unit test, then we kind of imply like, okay, well, that's not going out into production, right? But, you know, in the debug.assert method, that gets excluded from your release build. So if you were planning on something, you know, failing and aborting the process because some assertion wasn't met, you know, that's not going to happen in the release because it doesn't get included. Interesting. And they're actually saying right here,

all methods called within a contract must be pure. So basically not updating any preexisting state. So all this stuff is kind of tying in together. It's just kind of funny to see since I haven't heard this terminology in a long time. Well, kind of where I was going with that though, in terms of a deeper conversation was, is it, which one would be better than like, would it be better to use a debug dot assert? Because then, you know, you're fine from a, you know a debug version of your code while you're testing and developing and things like that. You can see things fail, but are you safer to have something like in an if check or something,

some other similar construct that's going to remain in your release version? So where do you draw the line as to how important that assertion is that you want it in your production code? Yeah, yeah, I was gonna say exactly. If you're a big bank, right? You don't want a single penny to be lost, right? But it's like, say you're a triple A game studio. And you know, something accidentally clips through a wall, like, you may be able to just let it go. it'll kind of fix itself. Right. I want to try your game. Yeah, no, you don't. Uh, all right. So, um, one of the things that he says here is you want to try and use models with similar concepts, which help him for the intended assertion. And I think all he's saying is when you're doing domain-driven design, you want to try and group things together

that make sense together because then it's easier for the developer and even the other people that are talking about it to make sense out of what they're seeing. If you're talking about unit tests, you have your preconditions that exist in the test setup. I know, Outlaw, you've talked about it. There's

setup. No, it's the AAA pattern. Yeah. Go ahead. The arrange, the act, and the assert. So the arrange is your setup in that case. And then your act is doing the procedure and then your assertions at the end. So yeah. And I mean, these follow these patterns that we've talked about before. Your post conditions are your search. That's the last day in the AAA. And that's, what's verifying everything came out the way it wasn't expected to be. Um, and it may seem sort of weird to say this, but looking at the unit tests and seeing the inputs and seeing the outputs and seeing that those things actually successfully were asserted, they help you understand what the procedure is doing without actually digging through the code, right?

Like you don't necessarily want to go look at a hundred line algorithm to figure out what's going on. But if you can see that, hey, I put this in and I got this out and you're guaranteed that that's going to happen every time that helps you as a developer know what's happening there. So nothing else you get to kind of trim out things to think about like you have some sort of bug say happening in a refund condition in a shopping cart site and at the top you've got an assert that says like um you know assert that order is completed before you refund it right you don't want to refund a pending order right so it's nice if you're kind of trying to track something down

that you can see that a certain be like okay this you know this is something i know about the state of my application when i'm when i'm here nope totally this next statement that i pulled out of the book i i'm gonna back up in a second and talk about the reason why i think this one's important so he says that combining intention revealingrevealing interfaces, side-effect-free functions, which were both from last episode, and then assertions make encapsulation and abstraction safe. Now, the reason why this is important, and I didn't include it earlier because I wanted to talk about it here, is when you talk about polymorphism, right? If you just have a calculate method that doesn't tell you anything right if you have a class that does multiplication you have another class that does powers you have another class that does division this calculate thing they might always take in

two numbers but you have no idea what's going on and so while you have this nice you know inheritance thing and and this set of methods that can be called consistently, there's no way for you to reason about it. And so what he was saying is, as you get these levels of abstraction and inheritance goes on, sure, the computer can reason about it, but it's really hard for a person's mind to wrap their head around all these different methods and follow the chain down, right? Without literally tracing through the code. And so when you create these interfaces, these functions, and these assertions, it helps a person understand the flow of what's going on as opposed to just what the raw inheritance

would be. You ever see, you ever trace something down into like the bowels of like a JavaScript framework? And when you get down to the very bottom most call, the one that actually threw the error, it's like, it doesn't even make sense. It's not even like programming language anymore. It's just like, if this dot object apply call parent self, you're like, what? What?

I might've written some of that. But I mean, it's, you know's core parts of the framework that are so generic because they do a lot of different things and use a lot of different ways. By the time you get it, it just can't reason anything about it. So you just kind of have to keep going back and be like, well, I don't know why it's null. Let me see what the parent call did. Yeah, totally.

I don't understand. All I did was write some JSON for this JavaScript framework. Why didn't it work yeah i didn't write anything procedural it looks like it should have worked yeah i mean it's just really interesting to think about having unit tests or any type of assertions there to help you understand we've talked about how commenting your code to tell what your code is going to do is kind of a bad idea but but having a unit test there to sort of assist you in the understanding sort of makes sense because instead of it trying to describe what's going on it's telling you if you give me these

inputs you can expect that this will be true at the end of it and that makes a lot of sense because if that method ever changes unlike a comment to where we said, one of the problems with commenting a method is people never go back and update it, right? They go in and they, they got the entire method, but they don't update that comment. You can't necessarily do that with a unit test, right? Like if somebody goes in and literally rips out everything that was in a method and then it doesn't fulfill that same test requirement they don't really have an option unless they just turn off their unit test running which is always possible but you know what i'm saying if only there was a way for me to tell the computer what i wanted and not what i wanted it to do if there was only some style of programming that focused on declaring the things that i i wanted i feel like you're leading into something here

oh so well kind of similar to this whole talk about the unit test and everything um i had i don't know if i would call it an epiphany, but I had this thought that kind of occurred to me where it was like, um, this somewhat kind of related, related to like a lot of, I've had recently several times where people have been like, Oh, there was some code that I wrote and they're like, you know, Hey, how do I use this thing? Which I guess was kind of bad. Cause it's like, Oh man, they got to ask me. That's a shame. But at the same time, I was just like, Oh, well, here's a simple, you know, uh, you know, you know seven line unit test or you know five line unit test go look at that right and then it was like a documented example of how to use this thing or like all the various ways that you could use this thing and then but not only was it documentation but it was also you know provided

value and functionality because you know you could just use it to validate, is this thing still work, right? Right. So I thought that was kind of a neat way to consider unit tests. Yeah, it's actual code that's proven out, right? That's beautiful. Go copy and paste this. It works. Watch, run the unit test. You know, that's kind of nice. Um, so I did want to get into in the book and we don't talk a lot about the examples in the book because, you know, that wouldn't really be fair to tell you the entire book. Um, we're not trying to take money out of the author's pocket, but there was an example in there that I thought was really interesting is they were going through this paint mixing example. And imagine you have

a paint class and you have this mix in method to where you can bring in another paint. So you're mixing paint into this method. So one of the interesting things he called out is you want side effect free functions, right? But think about this. You have two cans of paint one's got one's got some color in it and you're going to pour it into this other can of paint well let's say that you poured in a liter right you just increase the one that you're pouring into by a liter what should happen to this other one so what he was saying is currently the way that they were doing it in the example, that one that was being mixed into the other one, they weren't modifying the volume of it. And a lot of times you don't really expect it to, right?

If you call a mix-in thing, you take something and you pour it in there, are you going to modify that argument that was being used so that paint that was getting mixed in, are you going to say, okay, decrease that thing by a liter? What are you guys' thoughts on that? Well, he actually had an opinion on this that they said in the book that changing an argument is a risky side effect and a bad practice. Those were two different statements that he made in different paragraphs of the same section. So it resonated strongly with him that it was enough to like, I need to say this twice. So along those lines then, what would you do? So if you did something like that, let's just hypothetically say that you were going to write some code like this.

Oh. And you wanted that secondary, the other paint paint to be decremented by whatever volume was being poured into the other one how would you typically go about doing that yeah i mean i'll go ahead yeah sorry i just love this answer so much because i i'm always preaching about this i love breaking up the calculate and the modify into two different steps and it's useful for so many different scenarios you figure out what you need to do and then you have something to actually take that that design or that the command and actually execute it okay so tell me this though so you take this thing that's going to calculate it right so you're going to basically say you're going to increase this one

by one liter and you're going to decrease this one by one liter right that's what you're talking about this is the the formula of what's going to happen and so then the dew what are you going to do pass both those buckets of paint into this dew method or are you going to call it sequentially like what's the uh like how are you going to maintain the state on this thing to make sure that it doesn't get out of whack so you get a paint mixer class and uh it takes uh takes in you know the empty can and the full can whatever and it kind of squirts some from one the other and it's in charge of maintaining that relationship but how do you do it without actually modifying you return the results right

so you have some sort of uh result object that says like this should change to this is change that and not only is it um is it well more complicated to read when you're actually coding which is annoying but um it's so much more flexible i think because you can do things like predict what's going to happen and it's not such a big deal for paint but sometimes it's a really complex interaction do you see you want to see what would happen if i tried to do this and you may not you know choose to go ahead you may use it as like a validation and and the one of my other favorite points about it is it's so easy to test because you can say like hey what would happen if i did this you get those results back and you can verify that and you're it's like you're verifying

a blueprint and then you know you sometimes that um the actual execute step does things in the real world like you know mixing paint and so those things are hard to test, but you can test the parts that you can without dipping your toe into the integration waters. Interesting. Yeah, I like that approach. Nobody's got time for that. We'll just put an out variable or out keyword on it, on that argument.

That's the 17th argument. The example that always comes to mind that I absolutely hate that's in the framework about this is the try-parse, it you want to parse an int for example so it'd be int dot try parse and you know you pass in your string and then it's out and an int that you're passing in I hate that and so you're right Joe like doing what you were describing would be way more useful because then you could like chain things together, right? Because it's based off of whatever the result is. You can't chain methods when you're using, you know,

out as your way of returning back information. Yep. And one of the things I'd like to say with what Joe talked about there a second ago that I really like, and if you're following this domain- driven design and any of it's sinking in at this point, one of the things you could do is when you had this, this mixed paint class or whatever, it could actually return you back an object that could be a value object that could be used to replace those other paint cans, right? So keep in mind, as you're going through domain driven design, as much as you possibly can, you want to try and turn things into value objects

so that you're not constantly mutating the state of something, but you can literally just replace pieces of it. Because the more that you can do like that, the easier it is to control your invariance. And I think that was pretty much it. Were there any more? Did you guys have anything else on the assertion section? No, I think we pretty much wrapped that up.

Cool. I wasn't in the mic. Yeah, I'm a big fan of assertions, so I definitely like that section. I thought it was really good, and I really like the reasons behind it, so those are things that I care about a lot. There are definitely things in programming

that I care more about, and assertions is higher on that list than a lot of other things. Very cool. All right, so the next section that we're going to jump into. Just wait until we get to the logging section. I love logs. He does love him some logs.

Conceptual contours. So this one's kind of interesting, and I'm hoping I can do a decent enough job on bringing this out. I think in a nutshell, before I get into it, really it's just trying to find how something feels like it's right. Like when you start finding things in your code and in the business logic and you start creating something that feels like it's coming together. That's what it seemed to be like with this conceptual contours. And, and hopefully we'll prove that out here in a second. I did like one of the quotes from this particular section, which is cookbook rules don't work

for programming. So what they were getting into was a lot of times when people are developing, they will try and say, okay, we're going to keep everything at this level of granularity, right? It, for whatever reason that this is their application, they want everything to kind of be at this, this level of detail. And if that's too high, then it makes the code very hard to reason about, or you end up getting a ton of duplicate code, right? If you go too detailed, then you get lost in the weeds of it when you're actually trying to work in the code. So that's what they were talking about is it's not a one size fits all thing. And especially domain driven design, because you're trying to break down business domains, as opposed to just, you know, various different layers

and architecture for an application. So I thought that was really cool. And it, it makes a lot of sense to me because I've definitely seen things where people would be like, well, I want to go down to the level of detail that's like at a column or as an attribute. If you do that, then you lose that whole functionality piece. So I thought that was really interesting. Well, actually the paint mixer example we talked about before, you know, if you just got one method, it's nice and simple, right?

But you can't tell what's going on by that method. If you just have mixed paints, you don't know whether it's decrementing the source, you know, but if you've got what it sounds like to me, it's like, if you've got like a nice API, yes, it may be more complicated to kind of put these things together and do it. But it's also more um easy to see like what's really going on and the things that you're really interested in which also kind of ties into the um what do they call it the interface um self describing interfaces what was the term yep that's pretty much it um oh crap intention revealing interfaces i believe is what it was called. Yes. Something along that. And this is something that clicked for me a little bit later in the book,

which we'll talk about again here. But they showed some code, and I was like, oh, this first example is like a one-liner. It's like really expressive. It's really nice. And then, of course, by then we broke it out. It was like three different objects, and it was definitely more complicated. I was like, ah, this kind of sucks.

But I get why we did it. But as I kind of read on and went on to say, yeah but in this more complicated example you know it is more complicated but you actually get to see what's happening there's no question in your mind about how the sexual process breaks down and this actually maps to how people think about this process so when you read this it's so much more clear what's going on than this simple one-liner. Yep. Awesome. But there is a fine line there though, right? Like there's the, you shouldn't have to know all the intricacies of the different objects,

like how everything's supposed to work together, right? He did comment on that and I don't remember if it was this section or the next one, but to that end, he did comment on that. And I don't remember if it was this section or the next one, but to that end, it needs to sort of follow the ubiquitous language that goes with it. So if, if people who are talking about the particular class in that domain or whatever business problem you're working on, if they typically talk about it in that fashion,

then maybe it makes sense to break it down into that fashion whereas if you're trying to go too deep and break it down too far and you can't communicate that back up then maybe you've gone too far if you try to make it too general but the ubiquitous language is a little bit more detailed then maybe you need to keep flushing it out a little bit yeah i'm really bad about like if you ask me to design like a dll like a library then i'm gonna return more often than not a library it's like oh it's really easy all you got to do is you create this service and you pass a config object and the config object has an importer strategy and exporter strategy and you can just pass null but you can also pass in this you know these various settings here and you just got to configure all this stuff and by the time you're done you're just like well okay

well i just newed up 11 objects and i'm just trying to do the simple like you know get by id and oh well yeah 11 objects last one is most important because this is where you pass in your credit card number exactly right and make sure you put that cvcc or cvvc number on there um yeah but i think this was this section, though, where it was referring to the goal being to have simple interfaces that can combine logically to make sensible statements that follow along with the ubiquitous language. Yeah, okay, so that was here. Cool. Yeah, and then there was, because there was later on where he's talking about, like, you know, if all your refactoring efforts tend to be localized, then that's an indication that your model is fit. But if you start doing requirements or adding a new... Let me rephrase that. If you start adding a new requirements or you're doing refactorings that are spread across

multiple parts within your model, then that's an indication that you're missing something and then it's the overall domain that needs to be that needs refinement right okay so i'm doing it right i'm just not doing a very good job of it is what you're saying maybe we'll have to see your code put it in pull request oh so that along the lines of what mike just said a second ago, as new concepts are introduced into the model. So you start adding more and more to your domain. You might have to keep refactoring this stuff. And as you keep refactoring it out and you start shaping it, this is where the whole term of conceptual contours comes into play. It's what

happens when you, when you are refining that model and you start seeing these patterns and things start coming together a little bit better. So that's pretty much what it is. So that name made sense to you then? Cause it didn't for me. It didn't initially. I mean, I literally had to read the entire section and let it sort of soak in. So, and so that's why I say it's more of almost, it's, it's almost like a feeling, right? Cause contours means the shape of it. And so as you're refining this thing down, I almost see it like, like working on a sculpture or something, right? Like you just keep chipping away at it until you finally get this thing that is, Hey, this is what I want it to look like. This, this makes sense. Everything

sort of fits in here. And so it's really looking for, I don't know if patterns more, more along the lines of concepts when, when they start fitting together and you have a fairly, I don't want to say simple, but understandable model, then that's when you get these conceptual contours. Like one example I can kind of think of is like, you know, let's say you're working on some sort of e-commerce website and there's some rule that if the order is over 90 days, any refunds have to go on a gift card, right? So if you go to add this code or change this code in order to enable this condition and you find yourself working in like 17 different vials, and they're all over the place. There's some on the front end, there's some on the back end, there's some, you know,

they're just all over the place scattered. Then that's kind of an example that you're doing something wrong, and there's no real conceptual contour there. Like what you want to find there is you want to find like the order service and like the refund classes, and you want to be able to kind of drill into those and see how the payment methods work and you know there's this um conceptual model you've gotten in your mind of how this process works and it's whether or rather i guess just say how closely the code actually models your conceptual model based on the ubiquitous language yep agreed it it should sort of fit right and that's that's the key It shouldn't be spread out and scatterbrained.

You shouldn't have to redesign everything. It should sort of all just sort of fit together. Yeah, and it can be too abstract too. Like you can go down to the order service and see a refund method, right? And it takes order ID. And that's not granular enough, right? Because there's, you know,

it's going to be a 10,000 line method. It's going to have all sorts of, you know, private methods and all sorts of stuff, but just going in there is gonna be kind of confusing. So ideally, you'd want to be able to pass some more stuff in there to kind of configure that refund, because it's just a slightly bigger conceptual concept. Yep. And so one of the things he says here going along these lines to maybe further solidify what we're trying to get at is he said that when you find that conceptual unit of functionality it'll lead to more flexible and understandable designs so so you as a developer when you go in there and you look at it you'll be like oh okay

this makes sense it's all in this class you're not going into the front end you're not going into the back end you're not going into 10 different libraries. Again, this is probably counter to how a lot of people do applications, right? When they start from the database first and then they just start coding around it. A lot of times that stuff is scattered all over the place in different models. We're talking about a particular domain, right? So like your, your refund thing, that's probably going to be in an order domain or something like that. and so it should sort of make sense and you should be able to look at it and see what's going on i'm thinking of the word plumbing here i kind of feel like if you're using the word plumbing a lot

then maybe your conceptual contour is a little bit too too granular right because it sounds like you're kind of passing like one-off information around rather than more abstract objects it's it's funny as as i've dug into this thing a bit more one of the concepts that sticks in my head that i've seen so much and for whatever reason for years it never really bothered me was this whole notion of dto's getting passed around and you know you just modify the things on them you know somebody says do a refund, okay, modify the amount, modify this, modify this, and then send it back out, right? The problem with that is everybody has their hands in it, and that makes it very fragile.

Whereas if it's all baked into an object, a domain object, or whatever you want to call it, a smarter object, then you can control those things. You make those, those properties not settable by anybody. They're only settable by the behaviors on the object or something that can modify that object. And it really does help bring things down a little bit. Okay. How about this? If you're talking about plumbing, then maybe things are actually pretty good because it sounds like the majority of your work is in routing,

which means that maybe the other work is kind of trivial because you've got things set up in a good way and you're able to do the work that you need to once you get the information available. Maybe. Depends on how people are talking about plumbing, right? Yeah. You were about to say something, Mike? Well, it sounds like you want more POCOs instead of DTOs then. That's a fine line. All right, so moving on here. So decompose the elements into units.

Basically, your operations, your interfaces, your classes, aggregates. And this is where they say, again, using your intuition. So what you've learned from the domain experts, you need to sort of shape this thing and try and fit it together. I mean, we've all done it. Like I know the three of us definitely have, you know, you get somebody and they want to add a new feature and you're like, well, we know that the database tables need to look like this. We know that we're going to need calls to go do this. It's the same type thing, except now you're trying to fit it into a logical unit in your application code so that it can make sense in a coherent way. So it's not about storage. It's about behavior and functionality and how they all tie together. And God help us if they don't

already have a good name for it. We'll spend three days just trying to get on with a good one. Or even worse, we won't. Right. Just call it label and move on. That's the danger right there is you finally just give up. Oh, man. Helper class manager. So one of the things here that I thought that is so key and I think will help a lot of people is this all only happens through constant refactoring.

So basically, even as much domain knowledge as what we might all have, depending on what the subject is, we're not going to sit down in our first go and create the perfect domain model. It's just not going to happen because as new use cases come in, you're going to be like, oh, well, I need to, I need to change this a little bit, or I need to refactor that. And so it's this constant molding of this code before you can get to these conceptual contours or even to a place to where it all fits. That code definitely grows some mold. Yeah, because the reality is we're going to write that code today. We're going to want to refactor it, but it's going to be six months to a year before we actually get the opportunity to come back to it. So we're going to have plenty of time to think about all the things we did wrong

the first time and how we might want to change it. Well, how about this though? Maybe refactoring is so scary and gets put off so often because we can't do it reliably and quickly. You know, so maybe the reason that managers are so afraid of the R word is that every time a dev brings it up, they disappear for three days and they come back with a, you know, they come back with bugs three months later that were, you know, you're still finding. So, um, finding. So maybe if we worked on making... Yeah, exactly. And if you can't TD, why can't you TDD? Well, see, I would even say, though, that that doesn't fix the problem

because TDD, if you say that you're going to approach it from that perspective, that implies that you're still going to get it right the first time, right? Well, no, but if you have tests already, we've talked about this before that it kind of like gives you some courage to go and make changes to at least know, well, I haven't made it any worse. It does, except for, so let's get into the example that they showed here at the end of this particular section, which was this accounting example and and i don't remember all the exact details of it but it had something to do with payments and like late fees or interest charges and various different things but here's basically the accrual schedule that was like this

light that got uh turned on as they were going through the model was the accrual schedule determined how to calculate different fees for different purposes. So here was the interesting thing, though, is they created this model and it mostly worked for what they wanted. But then there was something else added and they were like, oh, man, well, this doesn't fit my model at all. So even with TDD, your existing tests wouldn't work considering what they ended up doing is they ended up moving complete pieces of functionality to other classes and rearranging things. So you're basically going to trash a lot of those tests that you had originally. So I guess what I'm getting at here is TDD doesn't solve all the problems. You can still approach it in the TDD manner to where you're creating

your test first to verify that everything's going to work. And all the failing tests, you probably end up throwing away because they're not even valid anymore because those methods got moved to new objects, right? Well, as part of their refactoring though, you could just be renaming those too, right? Or moving those around as appropriate. Possibly, yeah, possibly. But I guess what I'm getting at here, though, is it's not like the TDD can give you more courage and it could definitely make it to where some of your testing and your regressions get reduced. But I think the key is I think too many times developers and even managers and product managers,

they try and do everything perfect the first time. And we've talked about this before. What's perfect today is very quickly not perfect tomorrow, right? They come with a new requirement and your beautiful code now has to be hacked because it didn't work with this particular situation they want to do. So instead of worrying about that, constantly be working towards getting that thing into a good state and don't be afraid to change it along the way, which TDD would help with. But I guess that was what I was getting at more than anything else is that this comes from constant just knowing that

you need to shape this thing over time right and that's really the key by shape you mean add a bit field eighth argument default to you know some something thanks for dropping some reality reality check writing tomorrow's legacy code today oh man yeah i mean unfortunately though what you're talking about is the reality of what typically happens but in a domain driven design type of application or section of code that's not what you're going to worry about right because you don't care about bit flags you care about behaviors You care about actions that are being taken on an object and then how that gets translated later. Yeah, sure. Maybe it puts it on a DTO somewhere, but the actual domain itself, you're not going to have that problem. And that's one of the things that I really like about it is that you're really

focused on what is the outcome of this thing. So anyways, uh, the last thing that I had here was having these conceptual contours come out and stabilize the model and make unit tests easier to create and understand. So this whole thing is if you can start peeling it apart and you can see how this stuff fits together, these conceptual contours, then it can actually help developers understand the code better and it will help them communicate better with the people that are giving the or using the ubiquitous language between. This episode is sponsored by Airbrake. Hey listeners, do you hate spending time checking logs, running ad hoc queries, or searching your emails for clues on production support issues, it's especially bad

when the customer tells you about the problem. If so, then you should take a look at airbrake.io. It's a service for alerting and monitoring so you can proactively address issues and spend less time playing catch up. Airbrakesupports.net and all the major programming languages and platforms which you can see on their GitHub page. There's a free trial, which thanks to your feedback, no longer requires a credit card number, so you can check it out risk-free at getairbrake.com slash CB. That's getairbrake, A-I-R-B-R-A-K-E dot com slash CB. All right, and we're back with standalone classes. You want to tell me a little bit about that, Alan?

All right. So I think this last section I've got here. So basically, the key takeaway of this thing is as you add more dependencies to code, the more complex it becomes, the harder it is for a person to reason about. Because keeping track of all those dependencies and relationships, our human brains just aren't good at keeping up with that stuff. So the key here is what they want to do is you want to start reducing the sake of reducing the the dependencies rather it's to boil it down to what is necessary to that particular class or model or that section of objects so um one of the things that they said was implicit dependencies or references they are actually harder for us to understand than explicit ones right like ones that are called out, because it's just something additional that you have to add on so that your brain can even cope

with it. Well, let's back up for a minute, because when we talk, it's easy to think when we talk about dependencies that we're thinking about, like third-party libraries that you're bringing in and things of that nature, things that are mostly other libraries, right? But in this particular kind of example, we're just talking about like, here's your class that you're currently looking at, you're currently reading, you're currently trying to understand whatever it is, right? And if that class has any kind of dependency on some other class, right? That's what we're referring to as a dependency, at least for the topic of this this conversation And so he's saying he has a statement in here where he's saying if you have though

You know if you bring in one additional dependency now you have two classes that you have to Think about and know and understand their relationship while you're trying to read the first class, right? If you have two dependencies in this first class, now you have three things that you're trying to keep up with, right? And as you bring in the third dependency, this whole thing just starts to snowball out of control because now you have those three objects to think about and understand all their dependencies, and it gets out of hand quick. Yep. And going back to the paint example in this particular section, if you follow the code through the entire chapter or even the book, they keep building on this stuff. And he does a really good job of trying to point out some of the problems with these things.

But the paint, the way that it started was there was literally three integers in there, right? Red, green, actually it wasn't red, green, blue. Yellow. Yeah, it was magenta. It was the pigment color type stuff. So at any rate, there were three integers, right? And the problem is, is that was literally just, okay, that's numbers. Who's going to understand this stuff? And so what

they ended up doing is they refactored that into a pigment class that had red, green, and yellow colors. And then that way, at least conceptually, it was easier for a person to understand. So they took the implicit numbers that were there that were red green and yellow and then they change that into an explicit one by calling it out in a pigment class and so it's easier for our brains to cope with that because now it's something that we can make sense about this not just a bunch of numbers um so here's one of the things they say is every dependency in a class is suspect until it's proven as essential by that class. So like what Outlaw was talking about a second ago, you know, as you add more and more dependencies,

it's really hard to reason about. I mean, we've talked about e-commerce things and if you think about it from just an order, right, an order could have a dependency or a relationship to a customer. It also have a relationship to line items. Those line items are going to have associations to products. And then there's going to be associations to costs. Like it just goes on and on and on. And that's somewhat easy to reason about in your mind, just because you can sort of understand

a shopping flow but as these things get really deep and you start tracing it through code it is really difficult really difficult to go down the entire line oh yeah especially i'm sure you've seen code that kind of gathers like different bits of information from different places as things kind of go down so like you start here and it like grabs from the database you go into the next call it picks up a few config settings from say the environment you go down a little further get some more stuff from the database and as you keep going along it just kind of picks up more and more stuff and like the variables just start exploding like your future will self will thank you so much if

you could just gather that stuff to a config object or even have one method that like goes out and fetches everything it needs and then passes it to you know some sort of class that does the decision so you separate the gathering of your dependencies from the actual work, man, it's, it's so much better. And I don't do it. Going back to this, this example that, uh, Alan was calling about the pigment color though, was that, you know, in that section, in that portion of it though, he, he says that, you know, these implicit concepts count just as much as the explicit references and that we can generally ignore the dependencies on these primitive values, such as integers or strings, but we can't ignore what they represent.

The concept, right. And that's what's, that's, what's key there is that we can't ignore what this number represents. And so that's why bringing it out into the pigment class, uh, or the pigment color class that he did in this example made it so much more expressive and easier to understand. And you know, you can understand like what that number represents suddenly, right? It's not just a number. Exactly. Um, so here's what was really cool is often if you scrutinize these dependencies, a lot of times you can get rid of most of them, if not all of them. And when, when you can, you eliminate all other concepts except for the ones that are

crucial to that class. And this is something that we're all somewhat, uh, I would say guilty of, right? Is you have an order item and you're like, okay, well you need to be able to navigate to the customer or you need to be able to navigate to this. Do you really? That is the key question, especially in domain driven design. Maybe not if you've been doing things differently in your own applications, but if you're talking about working in a specific domain, do you really need to navigate away from your class to another object? Does it really need that dependency?

Or is having a reference to that dependency that can be acted on somewhere else good enough? So that is key right there is, do you need it? Is it crucial to the class? If it's not, you can probably get rid of it and greatly simplify your design. Yeah, it's nice to say that. It's nice to pass objects too, but

we talked a little bit about the interface segregation principle and the idea of passing in just a minimum amount of information. When you take in these big objects, like you take in a whole product when you need the product ID or you take in a whole user when you need an email address, you're really increasing that cognitive load on yourself

because you're just bringing in all these factors. If you can just take one simple object that kind of brings that stuff together, like say an email address or a product email or something like that that kind of logically associates those things so you can deal with them as a unit, you can really make your life easier. Yeah, I think a lot of times we try and make our code representative of, of how we know it's stored and how we know it's used. And the problem is it does make it way too complicated.

It just incredibly complex, right? Like everything has things that you can do to it. That customer has things you can do to it. That, you know, that order line item the product like there's so much stuff that can happen on every single thing that when you start trying to bake it all into your one little section it's unmanageable right and that's how you start getting your spaghetti code and things that are impossible to follow and incredibly difficult to troubleshoot yep and that's kind of like the opposite of the domain different design is kind of

basing your code around your technology stack, which happens a lot of times with database. I think that's why they kind of warn you, like, you know, focus on behaviors, focus on behaviors, focus on behaviors. It's because you really don't want to violate that language. You want to build that up. You want to create these domains, and you want to treat these domains as if they're real behaviors.

You don't want to organize around what's easier, what can be done with the technology. Well, I couldn't help but think, and Alan, you may not have intended it this way, but as you were talking about the order object and being able to navigate to the customer, and then kind of similar to what you were just saying there, I couldn't help but think of examples

where it's an entity framework-driven application, and so you're using what entity framework has provided as your model right yeah that's where your capability of like oh i have a reference to this older object and because i have that and i'm using an entity framework i can now drive to this other thing so you kind of the point there is that like what this what this book is getting at though is you know that entity framework should be hidden away in a layer that's not part of the model per se. The model might know about how to get to it, but you're not getting to that directly. Absolutely.

Absolutely. So one of the key parts of this, as you remove these dependencies and you start chopping it away and you get down to what that class really is, this makes it to where it's something that's very easy to understand and it's self-contained, right? Like this is something that can be used because it doesn't have all these dependencies and potential side effects. And at that point, it'll also be more testable. So one of the things that I do want to point out here is the goal is not to eliminate all the dependencies, just to eliminate the ones that are not essential to the class itself. That's, that's very key. If you can get rid of all of them, awesome.

If not, and you've got some ones that have to be there, that's fine, but you want to reduce them as much as possible. Um, I mean, kind of going building along that example, though, by reducing those dependencies, so like rather than taking some kind of object in, but instead you just have, you know, you get the, you know, Joe mentioned the example where all you wanted was an email address, right? So if you just let somebody set the email address inside of that, you increase the reusability of it as well. So now, for example, if maybe you were relying on like whatever your HTTP context is to have like some kind of user ID, for example, but really you didn't need the whole context, right? You just

needed that ID. If you let that ID get set, passed in and set, you know, whatever it is, rather than having this dependency now on HTTP context, then you increase the reasonable ability of it to be outside of a web application, for example, definitely, which could become valuable later on. That actually brings up something else. So there was a comment. I might have been on episode 63. I can't remember now. I apologize. But it was somebody wrote in and they said something finally clicked for them during the episode. We were talking about DDD and, you know, various different layers. And this is really important, I think, if you don't understand it. you start talking about different layers and abstractions and applications,

inversion or dependency injection becomes very key to being able to do some of these things in a reasonable way. So like what you were talking about, the HTTP context just kind of made it spring up in my mind is that's an architectural or some sort of technical thing that you're having to deal with there. Dependency injection allows you to say, bring in this piece that I need and bring in this piece I need. So if you did want to reuse that somewhere else, you could bring in HTTP context. Or if you had another system that had something that was better, then you could bring that in. So just know that anytime you're dealing with multiple layers and interfaces, dependency injection can be a real lifesaver. And it's kind of the way that it makes some of these things. It's sort of the glue that brings it all together. That was Brad Chigger, by the way.

Thank you very much, Brad. Okay, cool. And it was in episode 63. Excellent, excellent. So thank you for the comment, by the way. It was excellent. And it was in episode 63. Excellent, excellent. So thank you for the comment, by the way. It was excellent, and I don't remember if I replied to it or not. I definitely read it, but if I didn't reply, I was on my phone, and I hate typing on my phone, so I apologize.

So let's see. What else have I got? Oh, this was another thing. So any kind of intricate computations or algorithms, they should be tried to be factored out into value objects. And I know we've kind of beat this one to death, but as much as possible in domain-driven design, if it can be a value object, turn it into one. Because then you don't have to worry about maintaining invariance with mutable states, right? If you can just toss away the object and bring in a new one, then it's a whole lot easier and all the logic can just exist inside that value object.

And now that entity doesn't have to control all of it. And then there's only a couple more here. So low coupling reduces conceptual overload. So this is again, this is just the mental thing here. If you can reduce the dependencies it's easier to understand and standalone classes things that have no dependencies whatsoever they are the definition of low coupling there's nothing that links them to and from anything else and so i lied i have one more section go ahead i was just gonna say standalone versus singleton

any thoughts so when i first saw this section i kind of like saw saw standalone and i think Go ahead. I was just going to say standalone versus singleton. Any thoughts? So when I first saw this section, I kind of like saw standalone, and I think about the word alone and standalone classes, and I immediately thought singleton. But then we're talking about minimizing dependencies, and I think of the downsides of singletons as being, if there are any, are being that they tend to touch dependencies. But this has nothing to do with singletons. Right.

This would just be like a simple class. Just think of like a simple POCO class, for example, that doesn't use any other classes. I'm making like the most extreme example that I can think of, right? It doesn't use any other classes. All of its behaviors are just, for example, like primitives, right? Right. That would be an extreme example

of a standalone yeah basically just no dependencies right right okay yeah yeah i just thought the name kind of sounded similar but like in a lot of ways is really opposite of singleton so just i was kind of yeah don't don't go picking on my boy singleton now i see what you're trying to do meet me outside i see what you're trying to do uh all right so the last one that i have and this one's actually pretty simple and and i thought was kind of interesting was they called it closure of operations i'm going to go back to what i said before the part about ddd that kind of drives me crazy is all the wordiness about everything the ubiquitous language the closer of operate like it's seriously like it's so much um but basically what it boils down

to is where it fits and i think i even took this as a quote where it fits define an operation whose return type is the same as arguments so think about. If you had that paint class, if you're passing in paint as one of the arguments, then the return type of the class itself should also be paint. So that's all we're saying is, and the reason why they like this is because if you follow this particular pattern, then you're not introducing any other concepts or dependencies there. If you're only working with paint, then you know that you're getting back paint, then you don't have anything else that's coming into play. And they do say this is typically used with a value object, which makes a lot of sense.

I think we talked about in the past, one of the examples was if you had a money object, right? Money has to have a unit so that you know whether it's US dollars or euros or whatever, and then a value. And you can just basically replace the whole thing. You don't change the value of $20. You say that, oh, now it's 50. You throw away the 20 and you have the 50 now. So that's how that's done. I mean, what they mean by the closure of the operations, though, was coming from a math concept related to real numbers that any operation on a real number, if you multiply one real number by another real number, you're going to get a real number. So it's closed within that set of real numbers, right? So a way to think about this, he gave an example of XML in the book, but I think to me, an example that seems easier that everyone can relate to is strings. If you

string plus string, you get a string, right? Yeah. And it better not change my original string. I mean, that definitely happens sometimes with some methods, but that's not something I like. There's definitely been a lot of problems that I've seen because you don't realize that you're mutating, or rather you think that you're mutating when you're actually returning something. Right. I do think that kind of having this closure of operations, right,

basically returning the same type, it does kind of discourage mutating. So, yeah, like I remember remember i think about jquery too you used to like everyone used to like i can't remember the methods right now but you would you know dot something and then dot something dot something so it kind of looked fluent and you would just kind of keep chaining these methods and you could do that because it always returned the type that you passed in the jquQuery object type every single time. I hate jQuery. It somehow all worked. It was magic.

So one of the things that was interesting here is they say that this is typically not used with an entity object. And if you remember right, the entity object are things that actually have to maintain invariance and that kind of thing. And they have identifiers. They can be retrieved. They have some sort of storage that they have ways to be identified. And the reason is, is because they're not replaceable objects. They're usually things that have mutators on them. You're changing

state of the object. You're not changing, you know, the entire object at once. Um, they also say constantly look for ways to reduce interdependence and increase cohesion. So by doing one, you're doing the other. And, um, the other thing they say that also is helpful here is by using this closure of operation, it helps because you are not increasing mental complexity. And they also say, do it with standard types. So your ends, your strings, your, um, you know, your standard types, because it's something your brain already has space for. And so it makes sense. Now he did go into a conclusion and, or, or an example in the book that was using something similar to like SQL.

It's a, what was it? Smart talk. I can't, I can't even remember what it was, but at any rate, he was using this collection thing that was standard to the language. So what he's getting at is the standard types. If it's something that's implicit to the language that people are just used to

using, then that doesn't, that doesn't add mental complexity because it's something are just used to using, then that doesn't add mental complexity because it's something you're used to using. So as long as you're working with one of the built-in types, you're probably in good shape. This episode is sponsored by Linode. Linode has 10 data centers around the world with plans starting at just $5 per month for 1GB of RAM and 20GB of SSD storage and can go all the way up to 200GB of RAM and 16 cores for your heavy computing needs. And all of this can be done in under a minute. Linode uses hourly billing with a monthly cap on plans and add-on services ensuring you'll never

get in over your head. You have full control of your VMs, so go ahead and add Docker, encrypted disks, VPNs, and more. To get a promotional credit of $20 towards your Linode hosting fees, go to www.codingblocks.net slash Linode, that's L-I-N-O-D-E, and enter CodingBlocks17 to get started today. It's like you're getting your first four months on us. All right. Well, let's take a moment here. Uh, first of all, if you have already taken the time to leave us a review, uh, we greatly appreciate that you took that time. We, I can't describe it. We put such a smile on our face when we read those reviews we really do appreciate it Alan might

be a little obsessed he might check them hourly so just know that he's going to see it real quick after you write it but we really do appreciate and if you haven't yet we would greatly appreciate it if you would head to www.codingblocks.net

Slash review And there you can find Links to the major aggregators And you could say what you got to say about us And we would be forever in your debt Yes, thank you very much And I might check it every two hours Maybe

Okay, I was close What did I say, every hour? I was close Some days more than others other i don't know yeah i mean by the time you average it out it's probably an hour you're probably pretty close we'll call it we'll agree to just split the difference we'll call it an hour and a half there it is all right and with that we head into my favorite portion of the show survey says all right so our most important ever question that we asked last episode is how many monitors do you use and your choices are Just one, two is the minimum, three, like a boss, or lastly, more than three, because if it's worth doing, it's worth overdoing.

All right. So, Joe, I'm going to let you go first since you weren't able to play along with us last time, last episode. So one, two, three, or more. I know everybody listening to this podcast is a boss, but I also know that we say how many monitors do you use, not how many do you have. So I'm going to go with just one. What? Wow, that's some pretty interesting logic.

I like where you went with that. I just converted, too. I'm running one in most cases. What? Yeah. I don't use more than one screen right now. It's so nice to have the desk space back. I don't care anymore.

I can alt-tab like a boss. I can't talk to you anymore. It's a big one. What's the percentage there? Oh, 26%. 26% for one monitor. All right. Man, I'm torn on this one.

So I've definitely worked at places where they only give you one. And then you quit., and then you quit. Yeah. Then you quit. Like a boss where they like people. Uh, I'm going to, I don't think that's the answer.

I think one's probably the winner. I'm going to say two and I'm going to go with 30%. All right. And survey says, well, Alan wins. Woo-hoo. Two was the top answer, and you came in under the percentage for the double win. Wow. Which was how much?

Two took the lead at 47. Wow. Oh, wow. Okay. Yeah. What. Wow. Okay. Yeah. Well, a second, uh,

three. Really? That one was surprising. I did not see that coming. I really thought that two was just going to run away with it. And then it would be like, you know, everything else would just,

you know, one I thought would be the number, you know, the second best answer. You know what i think though i bet that the reason why two is so high is it's probably most people working off laptops with one other one that would be my guess but that counts it does it does so yeah man that's the that's reassuring having two monitors is excellent but i don't understand this one thing joe i don't get it yeah i just like the the desk space i mean just like i'm surrounded by stuff right now i got

drinks and cables and get a bigger desk dude i don't i don't understand the problem here i do have an absurd amount of flat services to put stuff on right it's never enough joe just doesn't like himself very much. He likes the pain. You know what though, Mike? And I know you'll agree with this. And this is so true and it seems so ridiculous. But if you'll invest in one of those Ergotron stands for your monitors, it's amazing how much desk space you actually get back

just by having that thing raised up off the desk. I don't know. I like my plywood special monitor stand I built here. It still looks terrible. I just did a picture just because it's so terrible. I understand where you, I understand. I'm with you in spirit on that, Alan, but unfortunately I can't, just because of the way my monitor is set up.

Yeah. You know, I have the one monitor that's on it turned on in. So it's just so that I have, I can read like an entire webpage all at one time. And that one is actually flush to the desk. So yeah, I kind of, I want to be with you in spirit and yet that heavy monitor won't let me. Yeah.

All right. But i will say though for those that are rocking three so we've seen these we've and we've talked about curved monitors and how awesome that is and everything and like you know there's some amazing ones out there there's that um new 49 inch curved one that we're waiting on Alan's review of. Cause let's be honest. We know he's going to buy it. He's surprised he isn't already, but you know, the curved monitor trend, I just never got behind.

I never really, I was like, Oh, whatever. You know, I just, I just, the value of it just didn't sink in

until for some reason this thought had never crossed my mind until I was at DreamHack. And one of the companies there, Scepter, had out one of their new monitors, and they had an arrangement of three. And if you've ever had, for those that have triple monitor setups, they'll know you just have flat surface and then, oh, sharp angle, another flat surface.

But if you have three beautifully curved monitors just wrapping around you, it's so immersive and amazing. Now I'm sold. I'm convinced I got to have it. I can now have an Excel spreadsheet that just completely wraps around me. Yeah, I was going to say, I don't know what you're looking at, but I don't want the stuff on my screen surrounding me. Imagine how amazing my variable names could be.

They can be totally expressive now. Yeah. I like being able to look away from this stuff. This value should only be true if the customer is, is from Georgia. I'm going to need dual 10 80 TIs to run these things. Cause I'm going to need three of those Samsung's right. I'm seeing like every,

every direction I look is outlook. Like it sounds like a nightmare. That's horrible. Now I know why you're back on one monitor. All right. Every company wide email is just one line, but it wraps all the way around you. Yeah. Imagine like VR nightmare, right?

It's like everywhere you look, it's just work, work, work. You know, the one thing though, so, so it was a beautiful setup but sadly though is this was a gaming convention and like all the games that they were demoing on it weren't really taking advantage at all of it like i could imagine that the the best gaming experience where having that three monitor curved monitor setup would be the most amazing experience ever would be a racing simulation where you might be able to see you know somebody coming up to pass you on on one side or the other but uh yeah unfortunately the games they were demoing with it it they they weren't really showcasing one of the games're like, you had a turret. And so all you see on one monitor was just like the turret that's like right at your shoulder.

And then the other monitor is the barrel of it. It was like, wait, that's an entire waste of a monitor right there. Oh, dude, this actually made me remember something only because this is super important because people love this. We're all mostly nerds that do this kind of stuff there is a show called brain games that is on netflix and go watch it it's amazing watch it with your significant other or your boyfriend girlfriend whatever it is awesome because what made me think about this is we were talking about the monitors and surrounding you, right? They go into an episode on peripheral vision and how bad humans' peripheral vision actually is. It is shocking how terrible your peripheral is.

So definitely go watch the show. Oh, yeah. I'll have to find a link to it for it's actually a national geographic show yes it's available on netflix so just in case if you wanted to watch it live yeah record it dvr it whatever it is it has done so well it's fun it's and you'll learn a lot but yes totally you'll you'll be shocked at how messed up your brain is and how many things it just makes up for you. Oh, well, speaking of how messed up the brain is, or at least how messed up my brain is, that's a great segue.

So, you know, there were a lot of VR technologies that were being showcased at the event this weekend. And one of them, Intel, had a booth there. And this was pretty impressive. They had one machine that was running a core i9 processor, but it was controlling three different monitors for you to be able to, you know, for viewing, for the people to view. But then that one machine was also controlling

two player VRs concurrently right and it was it was it was the most beautiful setup if you actually saw it was all liquid cold and you know different color liquids for like the cpu versus the video cards and everything and you get to see the the transfer of the fluids, but it was amazing. But, uh, one of the, one of the VR simulations they had, I was like, all right, I want to give this a shot. Right. Cause it's been a bit since I had tried some, uh, the VR technologies and I don't know why, but my dumb brain didn't even like think about it. So like, as we're, you know, he, he hands me the headset to put on and i put the headset on and i'm and and my first thought was like i started looking around like well when's he going to turn it on and then i'm like oh wait dummy no this is it i'm looking into this virtual

reality world already there it is on that's funny That's how impressive it was. Wow. I totally want to buy one. It's going to be a little while. I just can't. It was sick. I can't plug down the cash for it. Yeah. So it's been a bit since the three of us have been around, so I think we're due for some Google Feud.

We do. We need some. So I've got a few for you and first up is why does visual studio verify model okay so wow alan's going for the jugular. What was yours, Joe? Why is it verifying the models in my database? Or whatever that stupid thing is. It takes forever.

So we're just going to say, why does it take so long? Sure. Yes. Which would be the top answer. That's ridiculous. Keep freezing, which is really close to what you were getting at, Alan, is number two. Rounding out the top five, Always Rebuild. Why does Visual Studio need admin rights?

And lastly, why does Visual Studio cost so much? It kind of doesn't anymore. Yeah, if you get the – well, nowadays, you can get the community edition, right? And you can do almost everything edition right and you can do almost everything that you would want to do yep you know i had a thought uh yesterday maybe it was or the day before like do you remember when there was no visual studio every language had its own ide within within the framework if you wanted to do C++, there was a Visual Studio for you. If you wanted to do BASIC, there was a Visual Studio for you.

I don't miss that. Let's try another one, another Google feud here. Why is Python... Huh. Why is Python... So crazy about the white space? No, man, this has got something to do with the snake. Why is Python... Man, I don't know.

Hungry. You're both wrong. Your top five choices are, why is Python used? Which I thought is so unfair. That's so unfair. Why is Python so slow? Also not fair. Why is Python called Python? Which is a legitimate concern.

Right? Why is Python so popular? Which is a legitimate concern Right Why is Python so popular? That's what I was just thinking now And why is Python used for machine learning? Alright, why is PHP? I feel like we should do this one Oh boy, do you want to go there? Well, that's not

I had another one But we could do We could do that one If you want to do PHP Alright, so I'm going to do this one You tell me what you think, Outlaw Oh wait wait i wasn't supposed to type in php then oh did you already do it i thought well i'm sorry well i cheated all right we're skipping this one what was your other one okay let's go let's go to my last one i'm sorry i didn't i misunderstood now you'll never why is C++?

So hard. That's what I was thinking. Why is C++? Yeah, so hard. I'm going with the same thing. All right. Well, you're both in number two. The first up, why is C++ used for games?

For me, it was so hard. I searched it right after i said it and it's like oh my gosh yeah well for me that was number two three is faster than java why is number four why is c++ so fast and lastly why is c++ called c++? Yep. Excellent stuff. I like this game. You know what game I like? Survey Says. Well, I mean, today's survey. So I got an explainer one for you guys today.

There's a little backstory involved. Imagine you get four identical job applications, quadruplets, and you've got these four applications and they've already been interviewed and they've all been scored exactly the same. They're identical in every way, except one person graduated from a six-week boot camp.

One got a bachelor's degree from a state university, one had three years of similar job experience, and one was a frequent committer to prestigious open-source projects. Everything else is equal. You even have the same names. Who do you hire? Are you going to tell us yours? Or we can wait

I don't know No let's not Let's not Don't Don't Don't mess with jury poll No tainting jury poll Alright got it

Yeah That wouldn't be right I can tell you which one's more expensive Yeah, that wouldn't be right. I can tell you which one's more expensive. Yeah. Doesn't it feel like there ought to be like a census or some, you know, organization like doing studies like this? Like, I don't know, it seems important. It does sound kind of important. I think there is one and they call it the stack overflow

yearly questionnaire right well doesn't it kind of drive you nuts that like every other day you know like there's some article and some science article telling you like whether coffee is good or bad for you but there's never like articles talking about the tough questions i guess that's why you need cutting blocks right that's right he asked the tough questions. I guess that's why you need cutting blocks, right? That's right. We ask the tough questions. If there were quadruplets, which one would you hire? All right, so you're doing the lead in. All right.

I made a note because I was kind of coughing while you were reading that, that you could mute my, uh, my mic. And there was one time, uh, during that too, where were we talking about something that were brought up a website? Uh,

I think it was during the monitor thing. Uh, let me say mute. Like, I think it was during the monitor thing. Let me say mute. Like random website music play. If you can even hear it. Oh, I didn't hear that. I didn't hear it. Yeah, there was something one of you guys said.

I was like, oh, let me go to that website. And then I did and it started to play music. And I was like, oh, let me go to that website. And then I did, and it started to play music. And I'm like, oh, fuck. Bow wow. This is awkward. This is like the World Series. I didn't tell you. I was in broadcasting.

You guys don't remember what I'm talking about? I have no idea. It was like a Dodgers World Series that famously, like one of the guys that was working at broadcasting accidentally, like he, I guess, was watching porn in the booth, and he accidentally like went live with the porn. No. That's what was broadcast live on air.

Well, oops. I was going to say it was like a 97 World Series or something like well i say it was like a 97 world series or something like that maybe it's like 87 world series i don't know oops um okay so i see that uh we're into the d1 section and that's already been moved there's not a whole lot to talk about so yeah that's fine let's go with my stuff too it's pretty short so okay but we're we're definitely deep into this episode so yeah we're 135 according to my my clock nope all right all right now on to declarative design. Yeah, so first a definition that was from the DDD community.

Declarative design is a form of programming in which a precise description of properties actually controls the software and executable specification. And so that last part is going to be really key to, to a lot of this portion of the, of this chapter, because to be honest with you, this chapter threw me off guard because the first part of it, I kind of expected like,

okay, we're talking about declarative design i was thinking like declarative kind of programming like you know if you're any kind of javascript framework for example where uh you know the framework is mostly declarative for like the views the view portion of it right that's what i was thinking of at first and i'm like but i'm pretty sure that's not where he's going with it. So where's he going with it? And then there is this portion where he's talking about using domain specific languages and that domain specific languages could be declarative. And if you recall back in the episode 40, while we were doing the, how to be a programmer series by Robert L. Reed. And in the How to Be an Advanced Programmer, episode 40,

he mentioned using, I forget how he worded it, it was embedded languages, I think is what he said, in that you should create an embedded language in your program, right? Basically, so for example, if you had a program that just took in some kind of simple query, rather than actually allowing your user to enter in a SQL statement, you would have your own syntax, right, that you would use for that. And he called it an embedded language, right? So, as I was reading this portion, that's what I was initially thinking of, is that, like, that's where we're going.

That's what he's referring to as declarative, right? Is, you know, coming up with our own embedded language. And so, Colin, you were talking about how I was confused last time about the specification pattern. Because then it kind of steered into, okay, we're going to use a specification pattern to create a domain-specific language, this embedded specification language. Am I making sense? So it kind of was talking about using uh an embedded language but using the specification pattern to do it okay so it but it was still kind of weird to me because like it felt like a a lot of it was definitely focused on specification pattern. So that kind of makes sense only from the perspective that by doing the specification pattern, I guess they were talking about doing ands and ors and basically doing property

checks like that? I mean, yeah, for most of, a lot of the examples were like that. I mean, he did get into later on in this particular chapter chapter and this wasn't a very long chapter by any means but you know he was talking about you know if you had to get anything more complicated than um you know simple like there was this one quote that like this was probably my favorite quote of the entire book and he was talking about you know using these creating the specification patterns and where you might do things like creating an and and ors and not in your, in your interface. But he says, you know, if you're using, using a pattern doesn't mean building features you don't need. And I thought that's an, that's a great quote, right? I just,

I loved that quote. And specifically as he meant it in this portion of the book was that like, okay, if we're going to create this, um, this, this new language using the specification patterns, then we can, and all you're ever going to use are ands, then that's all you need to create. Like in your interface, just specify that, you know, the and has to be implemented and then in every other method, it'll just create an and and you're done, right? You don't have to create ors and nots. And then if it gets more complicated, where I forget how he how he worded the complicated one. Not this assumes, but think maybe it was, this assumes where it's like, if this is true and this is true, then, uh, if a, if a and B are true, then B is true because a and B are true. Uh, but when

you get into like more complicated examples where you would have to use like a and B and not C, then he was like, you try to stay away from this kind of examples but here's the problem that i had with this this section though just being frank is that it kind of didn't sound like we're talking about declarative in any of this none of this really felt like the way and maybe maybe this is the difference between i mean what was the copyright on this book i think it was like sometime in like 2007 or something if i remember right so so maybe it's just the difference between, I mean, what was the copyright on this book? I think it was like sometime in like 2007 or something, if I remember right. So maybe it's just the difference of, you know, had we gone over, had Coding Box done this in 2007, we would have a different understanding or, you know, different meaning, current meaning for what we would mean by declarative programming or

declarative design than what my mindset was that when I read that today or, you know, 2017. Does that make sense? Yeah. Yeah, absolutely. Because using the specification pattern just doesn't seem declarative. No, it seems, it looks really obtuse to me, but I mean, just looking at like the first sentence in this section, it starts off sounding exactly like i expect you know we're talking about intention really revealing interfaces side effect free functions and assertions and you're edging into declarative territory many of the benefits of declarative design are obtained

once you have combinable elements that communicate their meaning and have characterized or obvious effects or no effects at all that to me is like sounds okay i'm on board and then it goes on into specification land and yeah just not what i expect at all yeah i i think you're you like going back to the statement you made about like the j the JavaScript, a declarative thing is just a blob of JSON. There's no procedural or imperative code there. And specifications all look like procedural code to a certain extent. And I think that's what you're getting at. I think the reason why they might have been saying declarative back at the time was because it's very simple you have and or not predicates right and i think that

might be again i think you hit on something with the time of when this was written versus now like we truly have very declarative ways of doing things in some languages and this is definitely not what it looks like but i know yeah because in oh sorry joe oh god i was saying that declarative languages are nothing new you know like sequel's been around for a long time now so just kind of interesting to see such a a word i have such strong connotations of being used differently yeah you know he he says that uh there was this one quote in here that i like where he's like you know it's such a language referring to the domain specific language and again when i'm reading that i'm thinking of robert l reed's you know embedded language definition which could be you know wrong on my part but in such a language programs can be extremely expressive

and make the strongest connection with the ubiquitous language. So I was really kind of excited getting into this chapter. And then I got totally lost on like, well, I don't understand why we're suddenly spending so much time talking about specification pattern here. But it kind of made me kind of chuckle in my head, too, because I was like, oh, it's extremely expressive. And then I was like, oh, wait a minute. JSON is extremely expressive, I guess. Yeah, all of those are disappointed. It kind of makes sense to me to have a section here

on declarative design and using well-defined components and rearranging them and having those rules kind of play out in different ways. So you're kind of reorganizing or composing your business rules into bigger things like declaratively that that made sense to me so i guess i just kind of rejected my own thoughts on what things should be in this section yeah i it almost seems like if the if they're trying to go down the path of specifications for it instead of calling it declarative, it would almost be more like expressive, right?

Because it's easy to see if you define your spec and you name it in a way that makes sense, then it's easy to say, Hey, user can do this dot and user can do that dot. And you know, you know what I'm saying? Like that's expressive,

but definitely not declarative so i think it's just semantically it's stated wrong yeah well no one one of these days we should talk about declarative programming and the advantages of it and the challenges of it yeah totally yeah all right well moving on to angles of attack so we talked about a lot of different ways we talked about um a lot of different concepts and um i think the question you all are surely asking yourselves right now is how do we get there and so um you know realistically i i don't know any numbers but i i think that most projects we're all working on have all been in existence for at least six months, which is long enough to be a hot mess, right, of code. That's a lot of time to just pile on the crap.

So I think it's safe to say that most of us are working in big code bases with a lot of stuff going on and so the question then is how do we apply the things that we're talking about to that code and how do we kind of carve off little sections of it in order to well i guess i just answered the question how do we how do we get there and um the uh the this whole kind of section was all built on the idea of starting somewhere small and starting with something easy to pull out. So basically the opposite of rewriting from scratch. And the first thing I recommend is carving off subdomains that are easy. So if you've got some math functionality, pull it out to a library.

If you've got some complex rules, pull them out and make them declarative. Now I'm kind of questioning what they meant by declarative because i should have uh read the chapters in order um because i definitely interpreted differently and so that's kind of boggling in my mind still um but uh one um the really strong advantage here that i really like that they mentioned here is that the new sub domains are cleaned so when you're pulling out that math library or that accounting library or i shouldn't say library those sub domains then know, theoretically the new code is good, is clean. And the old code that you're pulling it out of is cleaner than it used to be. And it's easier

to refactor. It's easier to test. It's just better. Right? So it's a pretty good spot. And it makes sense to me then that you would start with something that's easier to pull out because as you pull things out that original code is getting easier and easier to work on we've talked about this a little bit with mean testing you know where do you start and we talked about identifying easy areas that were easy but also identifying places that had the most problems and this is kind of saying you know it's not specifically talking about testing but it's saying just start out with the easy stuff and things will kind of snowball and get easier as you go along and there was another question here i thought i thought it was interesting i wanted to get

your guys opinions on um said it's more useful to make a big impact on one area than it is to spread your efforts thin. What do you think about that? That's tough. I agree. We've actually been talking about similar things unrelated recently. When you have so many different, oops, when you have so many different pieces that are all spread out and everybody's doing things slightly differently, you start getting this divergence, right? And that almost creates more

problems. So maybe it makes a lot of sense to clean up one section and get it done really well and then try and propagate that throughout. So I guess i think i can get behind this but i do feel like there is there is a problem when it starts going the other way too but so i think maybe if you attack it one at a time you get really good in that one area and then you're able to move it through yeah i think that's a good i think that's a good strategy well i'm a little i'm a little torn as to exactly what is meant here. Because if you were to take, for example, like, okay, I'm going to change the way my big impact is is going to be the way logging is done,

and I'm going to refactor every... I'm going to introduce this new change to every place where logging was already done to introduce this new change to every place where the fact where logging was already done to be this new and improved version. So, so the bulk of the work was in, you know, the actual logging piece, but now I'm just changing a bunch of, I'm sprinkling the, you know, the new method calls or the new signatures throughout. Right. Um, you know, so, so it's still a big change, but it is kind of sprinkled around or, yeah, I don't know, man.

I'm kind of, I'm kind of torn as to exactly how that, like, what's an example of spreading your effort thin versus an impact in one big area, I guess, is kind of like in my mind where I was getting stuck. Yeah, well, I think that logging is a fair example. And I kind of, the way I took it to mean is basically like, you know, yeah, it's logging is one of the easier things to pull out. So that's good. But one downside is that the benefit has been diffused throughout your code. So the various areas of your code have only improved point oh five percent or point seven percent. And so it's not like a big noticeable improvement you know the other stuff hasn't really

gotten that much cleaner so it's good it's just not necessarily as good as like rewriting um some you know some bigger subdomain or some more focused domain like say accounting or customer service or something so i mean you're just kind of spreading it out and so you know okay so the logging would be the spread the spread effort versus like an entire domain of like you know hey i'm going to fix everything in the customer uh service namespace that would be one big area that's my interpretation just because those benefits are kind of diffuse you know it doesn't really make it a huge difference to those classes you know they don't feel a whole lot cleaner you know like you're probably just replacing one line with one other line so it's not and that's tough to agree with him on that one

then because because then in that in that regard changing you know doing the big refactoring on just a customer service namespace versus the effects of sprinkling the new logging love around through all your code, that's having an impact on all kinds of little pieces that you're going to benefit from. I've got to assume that I'm misinterpreting what he means. Well, how much are you really benefiting by swapping out, you know, one like logging namespace for a logging subdomain? I don't even know that logging deserves its own subdomain, but you know, it's an example. Well, maybe it's not a fair example. Well, they do. One thing that they mentioned is similar. It's like having a specific math library that does things like, say, calculate interest or that does just the kind of math operations that are common in your particular business

and using that as a separate class. And so rather than having all these little times 100s to make percents or whatever, if you have specific math rules to pull that out, that's kind of an example where you pull out the math, that's probably going to be scattered throughout your code. So it's kind of an example where you pull out the math, like that's probably going to be scattered throughout your code.

So it's kind of an example of spreading your efforts. Yeah, I think if you're going from that particular angle, I think that it does make sense to concentrate it in one area, right? Because now everything can benefit from that one particular update yeah i mean i mean yeah so now now i can now i understand what you're saying and i would i would go with a bigger example because as you were saying that i was thinking like okay so if you have if you're working in a web app that makes a bunch of ajax calls and you want to have consistent timeouts, some developers might be like, well, I don't know.

How many, if it's measured in milliseconds, would that be, how many milliseconds is it going to take to get to five minutes? So I'm just going to be lazy and write the math formula out and then it'll just happen at runtime versus, because that's kind of like the math formula that you just gave as the example from the book, right? And so that's why that one just popped into my head. Although I will say that's not lazy. In that case, that would have little impact on the overall end state

of the application if you were to like, oh, I refactored this into like a new timeout constant or whatever, right? Like who cares? Well, it kind of depends too. Like you might have a use case where you say, I want configurable timeouts. And in which case you get a lot of benefit from consolidating that stuff into a subdomain at that time

rather than kind of spreading that crap out all over the place. But if you're just pulling it out to just pull it out, then you're not necessarily getting a lot of benefit out of it. Then again, if you're going to be carving out subdomdomains then maybe logging is one of the first ones to do because otherwise you're going to be kind of carving this stuff out and it's going to have this old logging stuff and so you're just kind of making more work for yourself so uh you know i think it's debatable i think you've got to take everything with a grain of salt but i just thought it's kind of interesting to see that they said to focus on one big area if you can and rewrite the whole thing from scratch yeah

definitely that that was in between the lines everywhere and they never came out and said it but i'm just kidding they did not say that at all so carve out subdomains that are easy and the second uh point they wanted to emphasize is um another tip is to look for established formalisms which is a fancy way of saying um concepts that you're already familiar with. We mentioned accounting or math or customer service. These are organizations that have been around since people started talking and farming. Customer service is not a new concept. Accounting is not a new concept accounting is not a new concept yeah you know accounting ledgers are not a new concept accounts receivable all that

sort of stuff payments refunds those are all things that have a long long long history and have terminology that's familiar to just about everybody and so you can pull that stuff out and not get kind of hung up on the weeds talking about how things should be organized because everyone's got a pretty good understanding of how that works already so it's it's a good thing to kind of go for first but it all comes back to kind of targeting the things that are easy to pull out first hey out of curiosity there was like the accounting was that just an example that you had or was that one that he had mentioned yeah it was the book it was in the book and uh said he it goes back

centuries which i thought was kind of interesting kind of blew my mind to think like oh yeah i guess we we really have been uh you know like counting things on cave walls or whatever since a long time. But one of the things that they also mentioned in this particular chapter in chapter 10 was even though, and I think the accounting one was one, even though those things have been around for centuries and the concepts aren't brand new, the use for your particular domain may be different than another use, right? Like when they went into the paint examples, that's actually what it was. When they went into that, if you're just mixing paint and you got a machine that's mixing paint, you might have a very simple use case. If you are a scientist who is trying to figure out which pigment colors will make which precise other colors, that's a different domain. You're going to have more

exacting type of definitions for things that are happening. So this is all very specific to which particular domain you're working in, right? Yeah. Well, this is the reason why I asked if the accounting was the example from the book or if that was just one that you thought of. Because in one of the previous sections or chapters of the book that we discussed previously, there was a, I remember reading where he was talking about like, in some, you know, sometimes you're going to be lucky enough to work in a situation or an environment where the domain is something well-known and established, and you don't need to be reinventing the wheel. And accounting was the example that he used, was that these concepts aren't changing. Why would you try to reinvent this? right so go out and and get a book on accounting read about accounting like or you know it you

know that's assuming that you don't have access to a domain expert that you could talk to about this and pick this up but yeah he was definitely suggesting not to um to reinvent it right and we're not talking about remaining but just uh as a good place to kind of start pulling those principles out of existing code and so i think the the contrast here is that you said you don't often get to create something completely new. Like let's say you're writing software for asteroid mining satellites or something, spaceships. Even there, you're still talking about drilling. You're talking about mining. You're talking about resources.

These are all things that humans have been dealing with for a long time. And so you can bet that a lot of those things are going to be still talked about and still in common. So those core concepts are things that you might want to kind of start with rather than starting with like laser calibration or something that maybe is a little bit more just different or novel. And then the rest of the chapter, it was a pretty long example there. We kind of did some refactoring, but I kind of broke out the major three steps that I saw. And the first was separating the query from the modifier,

which is, we talked about earlier, something I'm definitely a big fan of, and emphasizing commands and side effect free functions but i just kind of talked about breaking up the calculations from the actual thing that did the work and so um what was the concept called the uh contour something yes conceptual contour yes there you go so even though it was more lines of code it improved the contextual contour because you were able to actually see what was going on it was also unambiguous and so it was in a way a lot nicer and i kind of that made sense to me to be able to see this couple lines there and even though it was longer and you know so part of me kind of um balked at breaking out that way i did like that i did know more about what was going on

without getting distracted by the details hey just for clarity there when in that when you mentioned about the commands and splitting out the commands though i mean i'm assuming that we're referring to like the command uh inquiry responsibility uh segregation yeah yeah and when i'm talking about commands here i'm like literally thinking about like the command pattern where you've got some sort of action encoded as data you can take that data and then execute it or replay it or in some cases undo it you know stuff like that um second uh the part of the root factor was actually making implicit concepts explicit. They started out by doing everything in one function, right, then they

separated the query from the modifier. So now we've got a function that calculates and a function that does. And then they were kind of talking back and forth between those two functions with a hash map, or hash table. And so like, you know what, we've got this kind of talking back and forth between those two functions with a hash map or hash table. And so like, you know what, we've got this kind of concept here that's kind of hiding in plain sight. Really, we're not dealing with, I don't want to get too involved in the example here, but we're really dealing with a collection of objects. And so let's make a class that represents that collection and take those individual objects and convert them to value objects.

And so it just kind of made things so much more clear. That was kind of the big eye-opening step to me, is just by kind of renaming things a little bit, now we're not dealing with hash maps, we're dealing with orders. Except in this example, the actual object was called a sharePy, which I thought was hilarious. And also, still kind of blows my mind, I can't tell you what a share pie, which I thought was hilarious. And also like still like kind of blows my mind. Like I can't tell you what a share pie is, but it sounds like it's a class full of carbs.

Yeah. Sounds delicious. I don't want to share. And then step three was basically just sub up the code. So they talked about encasting some logic, minimizing some side effects and minimizing dependencies, which are all things we kind of talked about. So that was just kind of nice, but it's kind of cool to kind of walk through those steps. And,

and particularly the step one is something I'm always blabbing about, but separating the, the data from the action and everything just kind of fall from there. So that was really nice. And one thing I thought was kind of interesting is, you know, we talked about the logging and even in the counting, but I kind of thought like, you know, like a real practical sense, like when you pull pull out that subdomain where does that subdomain go is that a new library is that a new namespace a couple classes yeah that's a tough one right like so in the in the specification example that i just did i created a patterns github project and I put the specification pattern inside there because

I feel like there's lots of patterns that can be reused. And so that kind of makes sense to create that. If you're doing something that is mathy or, or some sort of, God, I hate to call it, but like some sort of ER class, right? Like some sort of utility type thing. A lot of times it does make sense to have that in one spot, you know, bring it out into a separate project, make it a NuGet package or an NPM or whatever your preferred package library is. That sort of makes sense, right?

Yeah, I guess so. Well, I think it's going to matter. I think it's going to depend on how generic is it. Like, you're moving it out, but how reusable is it for other things, right? If it's not, then just making a new namespace within the same project that you're already in, whether it be a sub namespace or a peer namespace or whatever but um you know it because there's some cohesion there right yeah but if you're able to extract something that's truly generic that can that has more reuse that's when you would start to say like, okay, fine, I could break this out

into a separate project. And then whether you go far enough to push that out to some kind of a packaging system, whether it be like a Nougat or an NPM or whatever, that's more extreme. Because I kind of feel like in the examples that we're talking about you're not extracting something that's that generic i don't think but maybe but then going to the the last example that you gave with the web service example seems that seems the same level of extreme as like the npm or you know the nougat like that kind of package. At least it feels that way. Yeah, and I definitely like the idea of how the code is going to be used, kind of dictating that. So if it's going to be shared or if it can be used in isolation,

then definitely pop it out. Otherwise, don't muddy the waters, right? Yeah. One other thing I wanted to mention about the code example, still trying to not dive into too much, but in the original most simple example, I was kind of thinking like, okay, what if I had to make a change? Like, what's a change here that makes sense to make? And in the code, the example, it was talking about applying a payment to some sort of loan where there's multiple kind of loan shareholders so like let's say i'm opening taco bell and alan lends me three hundred thousand outlaw uh loans me five hundred thousand dollars to it's like really expensive it's a nice taco bell the nicest taco bell you've ever walked in super nice super nice like they got pumps for the hot sauce. That nice, the good kind. And this isn't a future where every restaurant is Taco Bell.

Yeah. And they all have pumps for hot sauce. So we're talking about my version of heaven here. So I owe you guys both monies, but I owe different amounts and maybe, you know, maybe I borrowed from outlaw first and, you know, and then Alan, I suck from outlaw first and, you know,

and then Alan, I suckered in a little bit later. So I've got a payment methods here. So I pay a hundred dollars, right? And it figures, you know what? Outlaw gets more of that payment because he let me more money and Alan gets a little bit less. And so if I wanted to change that code, the first example was one line where it's basically like make payment it took a dollar amount like if I were going to change that and say well you know what um Alan's charging me higher interest so I actually want to pay more towards uh him even though it's a lesser amount I should have that option right my first thought was like well I would change to take some sort of config object that would take the payment amount and also the breakdown like okay so you know that's that's fine

that's all right and then i thought about new code that was kind of more broken out and it had a couple different classes and when i saw the new code and thought about how i'd make the change it really changed how i thought about it and i think it was because of that contextual contour i was able to see exactly how things worked in like three lines and so how i thought about the problem changed and so i rather than thinking oh i'm going to pass in a config object and i'm going to if it somewhere in this big function now what i'm going to do is i'm going to create a different repayment strategy and i'm'm going to be able to take, you know, some sort of flag or take the strategy itself. It says either prorate it this way or prorate it that way. And just by having the problem broken down a little bit more, so I could actually see, have some insight and kind of see the skeleton of what's really happening beneath the covers there.

It changed how I wanted to make that code i think would have made it better so i thought that was really interesting yeah i like that i i that's that's one of the things you get by looking at this book is the evolution of the code and so i think one of the things i want to point out from this is while the book is kind of wordy, like just being straight opinionated here. So what? Kind of. Yeah. It can be extremely wordy at times.

If you can get past that, he's taken some real world examples that aren't easy problems, right? And that's what I really like about it is it's not like he just said, Hey, let me come up with these fabricated things that I can just cram into my domain driven design box and show how it can be perfectly done. He actually takes the opposite approach in some situations like, Hey, this is kind of a hard problem, right? And this is how you can solve it that meets all of what you need with this few of the bad things to come along for the ride. And that's kind of going with what you're saying, right? As you see this, you look at it, you're like, oh, okay, I get it. That makes

sense, right? And it will at least open up your mind into a different way of thinking. So the strategy pattern as opposed to passing in a config object, right? And maybe there's other ways that you can go about it. Like this whole specification pattern. I mentioned it previously, like I'm actually using it in some of the software I'm writing now, because I like the fact that it takes different entities in and I can make business decisions off of it in a way that makes sense. And it's easy for people to look at and say, Oh, I get it. Right. Like I can, I can see how this, this works. So yeah, I agree. I like that. I like the fact that, that it's a different approach that makes sense because you can visualize it. You can see it and you're like, okay, that, that, yeah, I get it. Yeah. Especially since we've been reading the book for a couple months now it has been a while

i mean you know the crazy part is it's not like we're alone in this because we've gotten a ton of feedback from people who are like man i'm i'm really digging the clean code series i'm really digging this domain driven design series and it's because i think that's the part that a lot of people miss right like you start coding you're coding and coding and you're like, man, this just feels wrong, but I don't know how to, to make it feel better, you know, because you're just used to those same old patterns. Okay. Here's the database.

Here's the code. Here's the whatever. And so I think, I think that's why people are really liking this is because you can start thinking about the problems different, right? Instead of it just being a bag of properties that are hooked up to a database you can think hey what are the behaviors we want to do here and then how does that relate so absolutely yes it's been a while so we're gonna have a i think that's pretty much it for the show. That's it for the angles of attack.

So now we're going to have a list of resources we like on the show notes. Don't think there's anything new here specific for this episode. We've got the Pearl's Eye video, the book, a couple other things, some really nice websites for you to check out. So Outlaw. I guess that takes us into Alan's favorite portion of the show.

It's the tip of the week. Yeah, baby. And I think Joe's going first this time, right? Yeah, I've been talking too much this episode. I'm getting a little hoarse. You parched. You need some water. Need some water.

So my tip of the week is kind of crappy. I apologize. But, you know, so i'm down to one monitor now i'm trying to get down to no monitors and uh part of um write your code on paper with my mind dictate siri google glass v2 that's what you've got right there we go yes i i cannot imagine how many bugs you're going to have if you're going to use Siri to dictate your code. Well, I'm not going to fix my own bugs. So there you go. Yeah, that's for the plebs. But so I try not to check my email too often, especially if you've got a lot of automated notifications from like a ticketing system or something.

I mean, you can just get buried in email after email. And the problem with not checking an email too often is sometimes you miss really important things. And it's like three hours later, you're like, oh crap, I broke the build or whatever it is and didn't realize it. And so that can be a problem. And so actually I wanted to recommend something

that a lot of people forget about, which is just the VIP settings on your phone. So you can make your boss a VIP so that when he sends an email or she sends an email, it actually pops up on your phone. And that way, you can even keep Outlook closed and set a little tickler in your calendar to remind you to check it two or three times a day or whatever is important for you. But you can also have those VIP settings alerting when you ever get, you know, the CEO emailing you or whatever. And so just kind of my DNA, you hear that little buzz buzz, you know, and you know, it's either a CTO or the, you know, your significant other.

And either way you're in trouble. So better answer. Another, not alternative, but another way that you could possibly implement that too, that I've done is that, uh, we've talked about, um, I'm pretty sure it was Hanselman that had like, Hey, you know, create this, these set of rules for outlook. And it was like, uh, if you, if you're the, in the two address, then it goes into your inbox. If you're in the CC, then it goes into your CC, et cetera. And one of the things that I did for the to, not only is the email to me, does it go into the inbox,

but if it's in any part of my management chain, that stays in the inbox. And that way I see the things that are directly to me or directly from my management chain which is kind of what you're describing yeah i do something very similar and with the way i check too is like i check the inbox constantly like i don't even know how many times a day i look at the inbox but i don't look at the ticket notifications multiple times a day you know that'll be like once in the morning, once around lunch, once in the evening, the CC folder,

same kind of deal every couple hours. But that inbox, I'm, I'm pretty much on top of it, but I can only do that because I filter all the other stuff out. I filter all the stuff in. Drink it from the fire hose. Yes,

sir. All right. So I don't know why I went crazy on this one, but I've got three. So the first is I'm using for when I did the little specification project, I'm using Visual Studio for Mac. I figured, why not? So this is just kind of a reminder that if you've got a Mac, you can actually download Visual Studio, not Visual Studio code, but Visual Studio and write C sharp applications and use the compiler and all that. So what I've written so far with the specification

example thing that is actually using Visual Studio for Mac and I'm doing a console application. And when it executes, it actually brings up a terminal window and I'm doing a console application. And when it executes, it actually brings up a terminal window and spits out the output there. So it's, it's kind of cool. It was kind of a way to force me to play with the new ID and see what's going on. So that's one, we've got a link to that here. Um, number two, this one's actually from Andrew diamond. So when we met up that night and we all went out to dinner, I asked him, I was like, Hey, what other podcasts are you listening to? Because you know, he, he's kind of got a list of things that he likes to do.

And there's one that he introduced me to and I started listening to, and it's called masters of scale. The sites here is masters of scale.com. And I started listening to the interview with Mark Zuckerberg from Facebook and it's excellent stuff. Like it's really good. I highly recommend going and listening to that. It's the only episode I've listened to so far, but I mean, if the other content is that good, then I'm truly excited about it. So that was one. And then my third one is some of the comments that Joe and

I've gotten when we've done videos for YouTube is, Hey, could you increase the size of the font? You know, I can't see this. I'm trying to watch it on my phone. I can't see the text or whatever. And so I was messing around with it the other day. And, and it's funny how you have to sort of, you know, how you were talking about the code and you saw it in a different way. You have to force your mind to think about things differently. So I was so used to, Hey, is there a plugin or how do I increase the font size in the IDE? Or how can I do this stuff quickly? Well, there's a problem with that. You increase the font size in the IDE and your, your solution Explorer is still tiny. Your, your debug output is still tiny.

Drop the resolution of your computer down to a smaller resolution and then work within that. So if you plan on doing any kind of video tutorials or code tutorials or anything like that, and you want to be able to share it on something that people will be able to see. Maybe you're thinking about doing a plural site course or some, some coding on YouTube or Twitch or any of those things. Do that. Drop your resolution down to, I don't know, 1024 by 768 or maybe even smaller and record your screen at that. Then it comes across nice and big. People will be able to watch on their phones or computers, everything. So that's just a little tip for anybody that wants to also give back to the community and share with code. And hopefully that'll help you out. Yep. So, uh, I got a, I got a couple

interesting ones for you that are kind of really simple. So just throw them out real quick. One is it never dawned on me that I know Alan, I don't know about you, Joe, but I know Alan, you do this a lot too, as do I, where on your Mac, let's say you want to open up terminal, you just command space, start typing in terminal, enter, boom, terminals open, right? Whatever the program might be. And then you can take it a step further and you could, you know, also do the same thing for finding files. Uh, like all the time, my number one guilty pleasure for that is a command space. And I'll type in like some math formula, whatever I want to know off the top of my head and boom, there it is. You know, spotlight just tells me that. Right. And then one day I was like, you know, I do that all the time for, for decades now on the Mac, on, on my computer, but I have the same spotlight capability on my phone and I've never really used it for that. And so then I was like,

well, let me start trying. So yeah, you could do the same thing and I'm like why didn't why did this never occur to me before right and I was actually I actually had planned on doing this one as a um as a tip for the last episode and then like right around that same time there was this like reddit thing going around where it was like oh there's like a you know using the calculator oh your mind's this way. And then, you know, you use the spotlight functionality on your phone to do the calculation functionality. And all of a sudden, like your mind's exploding. And yeah, so it was kind of discouraging at the same time. But I was like, oh, this is I can't I got to share this because it actually is kind of cool that that

I found myself using it even for like oh hey let me let me get to my twitch app and instead of like actually scrolling through all the different screens I'm just like you know what I don't have time to like I don't care where the where the icon is I'm just gonna like let me see twitch boom there's twitch right or let me you know whatever the math I can't I don't feel like doing in my head is let me find that. There it is. Right. Uh, so stupid little reminder, you know, PSA that you, you could do that. But then here's an interesting one too, though, that, um, that's really iPhone specific. But if you like to use any of the widgets on the, whatever the, I don't know what they call that main screen. Uh, it's not the series

suggestion but the one where you know you see it on your lock screen and then there's a screen where it shows you like your today overview and then you can see all your widgets listed there right which every android user is probably like they gotta have a different name for it that's what we call them um but but there's this cool capability that it never done to me like because i'm always like oh which which apps are going to have a widget that i actually care about and what is that widget going to look like like because maybe i don't want to waste my time and it's such a hassle to like go and edit the screen to like see and i know this especially is true for me on android where it's like oh this looks like it might be a cool widget. Then I added, I'm like, no, that looks stupid. I don't want it. But on, if you have a, uh, what was the

first iPhone that included force touch or the 3d touch? I think it was like the six S maybe. So on the six S, if you, um, if you want to see what that app looks like it one you want to see does that app even offer any kind of a widget and b what does that widget look like to know if this is something even of interest to you you can just force touch the icon and you'll go ahead and get a preview of what the widget is going to look like as well as all of its other capabilities. So I thought that was a pretty cool, you know, little tidbit that might be worth, you know, you might find worth sharing. And then lastly, the other one that I wanted to share was this article that was on the MSDN blogs about seven lesser known hacks for debugging in Visual Studio. And I call this out because specifically, I don't know when they snuck this in to Visual Studio.

The part of me wants to just believe that it had to be in 2017 that it got brought in because I don't recall ever seeing it before. But if you ever, when you're debugging, do you ever, Alan Joe, do the attach to process and then you get the window when you're debugging, do you ever, Alan, Joe, do the attach to process and then you get the window and you're like, okay, let me attach to my IIS instance. And, you know, now I have a debugger attached, right? And then, you know, you're like, okay, this is great, but I can't edit the code. I got to like stop the debugging process and then change whatever I wanted to change.

And now let me reattach it. Right. And, and before it was a hassle, cause you'd have to go back through that whole attached process. The window comes up, you got to find the EXE process that you want to, uh, attach the debugger to. Well, at some point along the way, Microsoft snuck in this reattach to process option. This is right there. a shortcut to just reattach to whatever the last thing is that you were attached to and i'm like until i saw this article uh about the seven lesser known hacks i didn't even really i hadn't i just kept glossing over it because the keystrokes for going to the attach to process were so ingrained in my head it was

just like i i wasn't doing it the easy way. Yeah, you don't look at the menu anymore, right? No. Yeah, same here. So that's the show in a nutshell. All right. And tonight we talked about supple design, finished up what we started last episode,

talking about assertions, conceptual contours, standalone classes, closure of operations, declarative design, which, and you know, also what that wasn't, and angles of attack. We're not opinionated folk at all.

Alright, well, with that, you know, if you're listening to this because a friend pointed to the side or he's letting you he or she's letting you use their device listen to it you can find us on itunes stitcher more using your favorite podcast apps and uh be sure to head to www.coding blocks.net slash review to leave us a review. And while you're up there, check out all our show notes, our examples, discussions, and more, and send your feedback, questions, and rants to the

Slack channel at codingblocks.slack.com. It's not so easy, is it? Joe, you take it away. Alright, be sure to follow us on Twitter at CodingBlocks or head over to codingblocks.net where We can find our show soon. Links at the top of the page. So seal.

Whatever. Whatever that difficult word is. Yes. That was a wrap.