Coding Blocks - Software Architecture – The Domain in Domain Driven Design

Episode Date: May 29, 2017

We continue our Domain Driven Design conversation this week as Allen is indecisive, Michael decides for him, and Joe can't handle the night life.

What do you call someone thrown out of a bar in Prague? I'm not sure where Prague is. Wait, let me tell you. No. A bounced check. C-Z-E-C-H. Now I know. Yeah, there you go.

All right. That was actually sent in from Chuck O'Halloran. That made me giggle, so I had to go in. We've actually had problems with figuring out where Prague was before an episode. That's why I made the joke that, like, oh, let me tell you. But then I was like, oh, wait, no, I still don't know. Oh, man. I just want to point out for international listeners

that we are actually in the upper tiers of geography understanding for our country. So while you may think we're idiots, we're actually in probably the top 5% of geography knowledge for Americans. That's amazing. I know where all the major continents are. I might know how many there are. Oh, nice. All right.

You're listening to Coding Blocks, episode 60. Subscribe to us and leave us a review on iTunes, Stitcher, and more using your favorite podcast app. Visit us at codingblocks.net. We can find show notes, examples, discussion, and more. Send your feedback, questions, and rants to comments at codingblocks.net. Follow us on Twitter at Coding Blocks or head to www.codingblocks.net and find all our social links there at the top of the page.

And with that, I'm Alan Underwood. I'm Joe Zach. And I'm Michael Outlaw. All right, so first up, a bit of news. I want to say a big thank you to the reviewers. We can't actually look up our Stitcher reviews right now. The site's down. But for iTunes, we've got E-Lichtictman that's it andreas rizberg uh i'm pretty sure

i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry i'm sorry chris b777 martin rocket hegel uh ashy larry t zuza 1985 lecathorne and basically steve sorry about all that those are pretty good i think you did i think you did an admirable job there the one time i could say the stitcher reviews easily joe takes it from me i did it's got your name and everything i apologize yeah they're done

for like what you said like seven or eight hours now, right? Uh, yeah, yeah. It was seven hours. We'll ask checks. So by now it's probably like eight hours.

So that it's been down. So if you're listening to this on stitcher, we're sorry that you missed that on your commute today. Cause that was probably rough. So yeah, go ahead. Yeah. We've got the full show notes available on,

uh, coming boss. Don't it slash episode 60 yep so with a little bit of news um there are certain things that you want to buy that really bother you like you just can't get enough time in the store like a laptop is a perfect example so i've kind of i need to upgrade i have have a 2011 MacBook Pro and it's been a really good machine. It's getting a little long in the tooth now and things are starting to run a little bit slower on it.

So I was like, you know what? I want to start looking. The equivalent of mine in today's price is about $2,800. And I'm not a huge fan of the touch bar and the keyboard feels atrocious to me. Some people say that you get used to it, but I can't stand it.

Oh, because it's got the new butterfly switches. Yeah, they don't feel like chiclets anymore, like that amazing feel on our MacBooks. It's gone. It's a really dead sort of feeling. But people say you get used to it, but still, $ 2,800 bucks is a hard pill to swallow for something that you cannot upgrade. You can't swap out anything in it.

So I'm kind of like, man. So I started looking at some two-in-one convertibles. Cause I was like, you know what? I don't want to carry around an iPad. I don't really care for one, but I would like something that I can flip around and use, you know, like as, as a tablet when I'm, you know, just kind of sitting there and want to read on the couch or something. Well, there were two I've had my eyes on. One's the HP Spectre X360 15 inch and the other is the Lenovo Mix 720, both convertibles, both pretty amazing devices. And I went to play with them in the store and the HP was out on repair because somebody dropped it and broke the screen on it. And little Nova was sitting there. I was like,

man, I can't just buy one of these things and not know what it's going to fit. So I got them both. So the plan is though, I have like 14 days to, to use them with the return policy and all that. So I'm hoping to make a decision between one or two of them and take the other one back. But if I don't love either one of them all that much, then I'll just take them both

back. And, but, but the gist of it here is I'm doing all this. I will post some reviews. I'm going to create some YouTube videos on each one of these. I'll do them individually. And then I'll compare them both because I'm actually treating this as a developer machine that I'll use as a secondary, like, you know, kind of browsing device as well. Now, in fairness though, on these, you can replace the hard drive. You can, but not the memory. You can. Oh really? Yeah. So in the Lenovo, it ships with an eight gig chip in one slot and then you can fill up the other slot if you want, if it didn't come with it. So both the ones that I've got are pretty massively spec'd out. Wait, no, I thought they both had 16 gigs of RAM. They do. They do. So base configuration. So in the Lenovo, you actually can access the memory on both of them, and you can access the

SSDs, which are both M.2 SSDs and they're both the faster ones. So, uh, yeah, I mean, they're both highly spec machines. They're both core, uh, or they're both I sevens. They both have 512 gig SSDs. They both have 16 gigs of Ram. The primary differences between them other than aesthetics and feeling all that is the guts. The Lenovo mix seven 20 is the first, as far as I know, convertible that has one of the higher end GTX and video graphics cards in it. It has a 10 50 with two gigs of Ram. So it can actually do some decent video processing type stuff. Um, the, and it has a quad core I seven, The HP, on the other hand, has a dual core i7 and it's running, it does have a dedicated GPU, but it's the 940 MX. So it's way less powerful, still better than

the built-in Intel Iris stuff. But, you know, the way I'm looking at it is if I wanted to use this thing for video editing, you know, awesome. I could, I could throw on Adobe Premiere and do that leverage the GT, uh, the GPU. Um, or if I want to use it for development, I can do that. Or if I want to kick back and just do some browsing or watching some Netflix or whatever, you know, it's, it's like the perfect all in one, I think for a developer. So, so it sounds like you already talked yourself into the yoga then, man. I mean, based off of your comment, you just said about being able to use the gpu to do any video editing well the the 940 also has cuda cores in it so it will in theory be able to do it it's just not going to be as fast so i mean there's going to be a lot of things that come into

play here the and the other thing i mean let's let's get down to brass tacks here hold on let me stop you right there because because this is what it ultimately comes down to. You have one machine that on paper, the specs of it are amazing. Yep. And then you have one machine that when you set it on top of paper, it looks amazing. Yep. That's really what it is. Because that HP looks gorgeous.

It's every bit as nice as oh dude it's every bit as nice as any apple product you've ever held it's it might even be prettier right it looks amazing it's gorgeous like it's straight up and to see pictures of it it's the hp spectre s-p-e-c-t-r-e x360 and you'll want to make sure you're looking at the newest one. You'll know in the picture, if it has a stylist in the picture with it, it's gorgeous, dude. It's, it's, it's almost like a bronze look to it. It's amazing. And it feels great. Like the keyboard on it is, I just, it feels great. Like it's similar to my Mac bookbook pro which i love the keyboard on this thing it feels like the uh the surface um uh not surface uh the microsoft ergo sculpt ergo like it has that feel

to it uh again i'm going to hold on my total review because i i'm literally taking one night i'll use one for the evening then the next day i'll switch to the other one so i'm trying to give them both a fair shake he's already decided man it's it's difficult but they're both they're both excellent machines like and here's the kicker so joe this is the part that absolutely killed me so i mentioned that the macbook is 2800 bucks for the model. I want basically the same specs, the I seven, the 16 gigs of Ram, the five 12 SSD. I bought both of these for that same price. Yeah. Both of them. That's ridiculous. Um, I will say the one thing that I would do if I bought these, cause I tried to use visual Studio 2017 with the Docker stuff.

You can't do Docker, Windows Docker on Windows Home. You have to install the Docker toolkit and it doesn't work the same. So I would totally wipe it, install Windows Pro and do that. But yeah, so I do want to approach this from the developer standpoint, from the value standpoint, for the hardware that you're getting all that so we will have some reviews up on our coding blocks youtube channel here in the very near future and like i said i plan on having three one for each of them and then one comparing the two and then you know ultimately what my decision would be he's gonna go man it's hard to argue with specs but dude the dude, the feel of that HP is, like I said, it is every bit as good. I'm not even, I can't stress to you how nice that thing is.

I mean, Mike even picked it up. He was like, wow. Let me tell you why he's going to pick the Yoga. Because that Yoga, those specs are going to matter. They do. And if you're talking about like buying this one laptop and then keeping it for some period of time, that period of time is going to be longer on the Yoga than it's going to be on the HP. I'll tell you one thing that kind of detracts from that a little

bit though. That quad core generates a little bit more heat, so the fans kick in a little bit more. And you notice that a little bit more. It's's not the huge it's not the biggest thing ever but that gtx also that 1050 it can put out some heat so depending on what you're doing like i mean it's definitely an interesting thing fans may be the deciding choices as much as apple liked to talk about how they redesigned fans oh yeah on the macbook pro at a selling point i've never once considered that as i guess you'd have to have like a really obnoxious fan you would consider it i will say this if you took the guts that i7 and the gtx out of that one there's no question you would get the hp if you could put those if you could transfer those two components over it's not even a question because that hp is just the build quality on it

and the fit and finish is just gorgeous right so yeah it is a very nice machine to look at no it's funny i think like just a couple years ago you know we all kind of came down the side of macbook pros and just with a few little changes it seems like everyone's kind of abandoning them in droves at least talking about it. Yeah, but I mean, they changed like the one thing that was... Okay, go back to the early days of iPhone, right? What was one of the things that was touted as being the critical success of the iPhone was the fact that they got the keyboard right on the iPhone, right? Here's the company that you would think they should have learned, right?

They should have known better than anyone else, right? Input matters. would think they should have learned right they should have known better than anyone else right input matters and then and then you know what's the number one thing that alan didn't like about the new one the keyboard the feel of it yeah i'll be honest like i the touch bar i i've i've really come down hard on it before i'd even really used it i didn't hate it like it it wasn't as polarizing a user experience as what I thought it would be. Like you definitely lose that touch feel, but I didn't hate it. Like it looks like it has some uses and it's got some utility. However, it's not a selling point for me.

Like it's not a feature that I really care about. It's not going to tip the balance one way or the other, but that keyboard feels horrible. Without knowing how that would work in boot camp, though, I really have a hard time saying that. My gut says it's probably not a great experience in boot camp. Yeah, you probably have to have it default to just that top row of function keys that you would typically expect, right? It depends on what their support is for the touch bar driver in boot camp, right? Yeah.

So it's interesting. I mean, I wanted to throw it out there. I know a lot of people are constantly looking for, hey, what's a good laptop to do for this or whatever. And I think these are kind of the best of all. And oh, by the way, that's an expensive proposition that we're talking about that too.

Like to try that touch bar in boot camp, right? To even just to try it, you're talking about spending a good chunk of cash just to see like oh how does this thing work oh i hate it well now guess what i'm stuck with right because not only you have the hardware but you also got to pay for a version of windows install that like yeah but i mean i feel like the cost of license of windows is like the least of your concerns at that point yeah you're just pushing up past three grand it's i mean it's kind of ludicrous what

it's getting to i mean a license for windows home these days is like what maybe 130 bucks yeah a little over on you know if you go go shopping for it on amazon yep so is there a restocking fee for these guys no so that's interesting and i don't want anybody to think that i'm trying to abuse the system or buck the system or anything totally abusing the system oh but like how else can you really know so so that's the thing that's that's oh man i could totally parallel this to getting married wait what like that was random like you know religion dictates that you can't live with the person whatever man you can't marry somebody you haven't woke up next to one day right like you don't know what that's going to be like. So wait a minute.

What was the other wife like? Because you're suggesting that you married two wives. So you're like, one of you I'm going to keep. Oh boy. Oh boy. So anyways. Yeah. But no, I agree.

It's that whole thing. Like when you, if it's a $50 thing, whatever you buy it and you're like, okay, I didn't like it that I'll get another mouse. Right. But when you're talking about a laptop it and you're like, okay, I didn't like it. I'll get another mouse, right? But when you're talking about a laptop, you're looking at over $1,000. You don't want to buy something that you're going to hate. So Best Buy actually has a return policy that if you bring it back within 14 days

in the original box with all the original stuff, that's it. You bring it back. That's it. I was thinking I would pay pay over stocking fee like if they even just let me rental like just flat out like laptop rentals i would love to do that to really try some of these things out yeah get your hands on something i mean i was kind of just curious if the two in one would even be something that i would like and i was shocked that i like

it more than i expected are you gonna take it back with Ubuntu installed? No, I'm trying to be really good and try and keep it as close to, you know, bare bones stock. Although I have installed Visual Studio, I've installed a bunch of Adobe stuff. I've installed, you know, a lot of things. I've got Docker running on one of them. So, yeah, I mean, it's going to get wiped before I take it back. But, you know, it's definitely an interesting thing. So, updates to come. Yeah, let mean, it's going to get wiped before I take it back, but it's definitely an interesting thing. So updates to come. Yeah, let us know.

Well, so it wouldn't be a topic without talking about Git, right? So Microsoft released an article about the largest Git repo on the planet, right? I think we recently talked about their effort to improve the scalability of Git, and they were going to introduce GVFS, which was going to be a virtual file system for Git. And so they posted some of their findings on this, and it's awesome to see this thing. We'll have a link to the, to the article, but just to keep this thing in check, like what we're

talking about is we're talking about, imagine a repository where just alone in it. Okay. You have 3.5 million files in it. Okay. The files alone are over 300 gig just before you include introduce any kind of change history on top of that. Right. And now imagine you have 4,000 developers or engineers working in that thing regularly. Okay. We're talking about massive scalability problems here. They were saying that, uh, when they, when they first started to, when they first tried to make their, uh, migration to get, uh, you would issue a command and it would be anywhere from 30 minutes to hours before it would respond just due to the massive size of the, uh, the repository that they have have here i'm trying to find the specific one um dang it but i can't find it now so um but they did they did have put out some good metrics though like now that they

have added in uh gvsfs to it they've said that now it's like for some command for the some of those same commands that used to take 30 minutes to hours, it's like 20 seconds now, which is still, you know, they admit that's not, you know, the most, you know, that's not great. You know, if you're the guy who's like issuing that command and you're like, let me wait 20 seconds before I can issue another one, right? But, you know, down from hours, that's awesome. Right. So here's some of the metrics that they have going on. Right. So they, so they've been using this thing for four months, 250,000 reachable commits. All right. They're getting over 8,400 pushes a day on average. On average. All right?

2,500 pull requests with over 6,600 reviewers per workday on average. 2,500 pull requests. Have you seen them? We've all had merge conflicts imagine 2500 pull requests a day over like almost 4400 branches inside there's only 8600 seconds in a day it's like pull requests every four seconds that's insane and then they have over 1700 official builds per day off of this repository. And there was another number that they had in this article where they were quoting like, that's just the official builds. So if you, for those that use Visual Studio Team Services, you might have noticed this, or if you haven't, you'll be happy to learn this, that Visual Studio Team Services introduced a feature a while back

where when you submit a pull request, part of the build automation can be that the pull request cannot be merged in until it passes a build and passes unit testing. So they mentioned that 1,700 official builds per day did not include the pull request validation builds. Wow. Well, that's what they were calling them, pull request validation builds. That's not included. There were thousands of those pull request validation builds that aren't included in that. So, I mean, we're talking about like massive scale

of this repository that's happening here. So, you know, hopefully it's only going to get better. And anyone who's looked into mon uh, mono repo type solutions, especially at scale. Google had an amazing presentation. Um, I can't remember the, the name of the woman that gave the presentation,

but she had a, uh, an amazing presentation on, the scale of Google and, and trying to solve, uh, you know, their type of developer environment problems that they have.

And, you know, now that with the introduction of, of, uh, GVFS, their type of developer environment problems that they have. And now that with the introduction of GVFS, it's only going to get better to continue using Git in these environments. So I'll include the link. There's some amazing numbers in this thing, though. It's a really neat article. That's super cool. That really is.

Yeah, and actually, you just reminded me of something. I went to a recent meetup, and one of the developers was talking about moving from Perforce to Git and trying to figure out if it was worth keeping a history. And he said, you know, I think we're probably just going to ditch it because it's just not that important to us right now. And I told him that he should consider having a national, well, it's not national, he should consider having a Code Forgiveness not national he should consider having a code forgiveness day

so it's like if you decide we're going to move to a new source control and we're not going to track the history you should give people a couple days maybe a week to do whatever they want and just let it happen it's like the purge right

what would I check in if I knew no one could ever trace it back to me? You could hide some comments. You could fix something you've always wanted to fix. Bad. Do you guys think this is a terrible idea? It's a crazy idea. Well, I guess I kind of got hung up up though on like why you wouldn't want to include the um the history there though yeah just because it doesn't always transfer very well like uh

that's it you know i know there are tools and stuff that you could do it but just you know it definitely is a hassle and sometimes things come across weird especially if you try to keep like branches and stuff you know so there's something nice about the idea of just starting over yeah i agree with that that's uh so you modeled this after after the email debt forgiveness yeah exactly i was thinking about repile the the national email forgiveness day i think it's in april where you can respond to any email on that day no matter how late and how long you've been putting it off and like no one can say anything you just get it for free yeah that's excellent all right so the last one that we had in the news this actually came up from a dinner conversation

that outlaw myself had is i had said a while i had said about something that i had done it quick and dirty like one of the things that i had put in our code base was quick and dirty. And you brought up a question. I don't even remember how you phrased it. I just remember phrasing it like, so you said you did this thing and you did this thing. At the time you said that you did it, it was quick and dirty. And there were two words that in this explanation that you gave of this thing that that like sat with me quick and dirty i think i say beep and beep so it's funny it brought up the topic of if it's quick is it good like if you did it quickly

that that sort of implies good maybe maybe it doesn't maybe it does but usually if you can get it in there quickly that that might mean that it wasn't too terrible and the dirty parts of one that scares you right you're about to say no i was gonna say the opposite i was gonna say i do quick and dirty stuff all the time i don't feel bad because quick and dirty is better than correct or perfect and never done. That's a great point, actually. And there's all sorts of things. It's like, oh, man, I really should refactor this stuff.

I'm going to extract this stuff. That's going to take me three days of work. And this is something I need to get done today. And it's just not that important. Yeah, totally. Joe just made me feel a lot better about my code. Yeah, totally. Joe just made me feel a lot better about my code. Yeah, man.

So, I mean, that's kind of what happened with the situation we were talking about was the quick part was, you know, I didn't spend a lot of time, you know, trying to make sure that every single edge piece of it needed to be done. Right. Like I just, I got in what needed to happen. The dirty part is there were some things because of the way it was designed to where I sort of had to fake some other garbage to make it work properly. But ultimately I feel like we were trying to step towards a better situation, right? Like taking this one step in this direction, set up the path to where further down the road we can iterate on a little bit more. And the code wasn't terrible, you know, the approach wasn't terrible, but there's definitely some things that were left undone. And so that was kind of the dirty part, right? Like you can't just go in and this is going to

be something that's beautiful and easy to do through the UI, it doesn't exist yet. So it just brought up the topic of sometimes it's worth taking those steps, not doing it perfectly to your point and getting it in place, laying the path out so that the next step's not so hard to take, right? And then the one after that can help build upon it. And so that's kind of the path that was taken. And it's not always an easy choice, right? Like sometimes you're like, man, I don't really want to go down this road because I know it's undone. It's not finished, but at least it sets us up for some future success, right? And it works for right now. So that's, I thought that was an interesting thing. I guess the part that kind of like threw me though was the, I was like, well,

if it's quick, then that's better, right fact the fact that you're able to get something to market faster automatically means that that's better right sometimes more agile it's more agile but it might not be as developer friendly right like in the thing that i did i basically borrowed a piece of of a system and i made it work somewhere else where it wasn't really intended to work right so i kind of had to adapt it and that was the quick and so that was the dirty that was the dirty the quick is that you reused something i got it done quickly right but yeah the dirty was I had to sort of adapt it without filling in all the pieces. So yes, but people that come in and see that code where it was done, they're not going to totally understand it unless they knew that other part of the system. Right.

So I don't know the quick part. I don't know if that necessarily strikes a good thing internally when I hear it or, or bad, I don't know if warning bells go off or what happens i feel like most managers i've worked with like if you come back to him and say i can do this checkbox in an hour or i can do this checkbox in three weeks and it's good or not three weeks like say three days and it's going to be much better much more resilient much more maintainable and sets us up for future success. Every manager in the world is going to say, do one hour, and if we need all that other stuff you're talking about, it could be a problem, we can revisit. Yeah, that is almost always the path that's taken.

But now you multiply that by 1,000 tickets, and you're up the creek for that battle. And that's the problem, right? You can't, as some people put it, you can't kick that can down the road every single time, because when you finally catch up to that pile of cans, it's insurmountable. Right. And that's the problem. Like you can, you can do that sometimes, but there, there are definitely times that you need to not kick that can down the road and at least try and address certain aspects of whatever the problem was.

Maybe not make it perfect, but at least get some of it done. But let's call this can what it is, though, because you're kind of implying that this can is technical debt. Right. But it might not actually be technical debt just because you did it in a dirty way. Agreed. Agreed. Yeah, it might not be.

I mean, let's say that that checkbox. Like if you don't have an interface to, I'm trying to think, I'm sorry to interrupt you. No, you're good. And just because like you don't have an interface in say like another part of your UI that allows you to edit or manage something else, that doesn't necessarily mean that

because you added in this new feature, it's automatically dirty. No, agreed, agreed. That's a really good point. Just because something was the one-hour approach doesn't mean it was the bad approach, right? It could have very well been the perfect approach for what was needed, and it may never need to be revisited. But however, that checkbox might be something that you had planned on putting in 20 different places in your app, and instead of having a reusable component now, you basically have to copy and paste that code everywhere in a one hour change.

Right. And then if anything ever needs to change, you now have 20 places you have to update. So those are the kinds of things you have taken into consideration. Are you ever going to need it in 20 places? You don't know, right? Today's story is you needed them one, but tomorrow's story might be that it gets out of 20 or it may never happen. I mean, we talk about the MVP a lot, though, but now we're talking about, it's almost like we're talking about the MVP, but on a much more micro scale, right? Because now we're not talking about the MVP

as it being the entire application, but we're talking about it as being like a feature. Right. A small new feature component, whatever you want to call it like that. Yep. Just getting that thing out. Yeah. it as being like a feature right a small a small new feature component where everyone caught like that yep you know just getting that thing out yeah and you know we think about them the windows uh get repo that we talked about like i don't think they're kicking many cans you know some things yes but when you've got a project that it gets to a certain point like there's no room for people to

be doing that kind of stuff and so you know your situation's a little bit different if we're talking about say like a startup or a new product or something where you've got some room to take on debt, then I think that's a different scenario. And so it really does matter what situation you're in. Yeah, fully agree. I mean, gets a little bit, it's been around for a while, right? And what they were trying to do was enable mass scale on it. Oh, which by the way, this is, this is completely going back to something that you said that maybe we discuss in a later episode, but the whole concept of a mono repo versus, you know, multiple repos, I think that's worth bringing up because there's a lot of pain points that we've experienced and might be helpful to share and maybe even get some feedback on. So

we'll talk about that in a later one, cause we don't have any time slotted for it for tonight, but something interesting. So I think with that, let's jump back into sort of what we started, not last episode, but the one before. Yeah, episode 58. Yep, episode 58. We started in on domain-driven design, and it's a huge topic. And what we want to do is we still want to continue going through the overview. And at some point we will jump down

into the weeds, but like I even already answered some questions on the episode 58 comment section down at the bottom where, you know, just being introduced to this topic, there's so much information and it will kick off so many thoughts in your head like, well, how would you do this? Or how do you handle that? Or does this mean I'm going to create a bunch of classes to do this? And that's the thing. There really are so many pieces that we want to go through it conceptually first because it's too much to consume, right? We've said the whole thing of drinking through a fire hose and that's about what this is like. So anyways, continuing with that, let's talk about the domain layer itself.

And it's the first D in the DDD. So the big part here is really what you're trying to do is you're trying to represent the concepts of the business. You're not trying to think in terms of software and how you typically write software, bags of properties and all this kind of stuff that gets pushed to a storage or something. You want to think about what the business needs are and more specifically, the behaviors of the business. So when you say a domain layer, like what are some other kinds of layers? Like where does this fit into the whole scheme of things? Okay. So the domain layer, this would actually be a potentially a project in, in your solution.

Okay. So that would be your domain layer. You would have a UI layer. You would have an infrastructure layer. Uh, you would probably even have, um you would have an infrastructure layer, you probably even have domain service layer, you could have repository layer, like the problem is it could grow out of control, right? But the domain layer is specific to this department you're looking at, right? Or this particular business case that you're working on. So you might have multiple domain layers. You might have one for your accounting department. You might have one for your shipping department. You might have one for your customer service. So it's truly a layer that's going to contain your business entities for whatever that use case is. Okay, so if I had a rule like

refunds over five hundred dollars require manager approval that's the kind of thinking and the kind of decisions that live in the domain model correct and that would probably be when you're doing something like that that would probably be in your customer service uh you know business domain okay so from the book itself this is the layer that is responsible for representing concepts of the business information about the business situation and business rules. Correct. And, and it's interesting because I think, I think the big thing that they pull out here is it, let's talk about what, what these domain models are first is you can have a domain

model and we've seen them. It sometimes are kind of like DTOs that just have properties on them. And it's more about the state that you're transferring from one place to another. That's called an anemic domain model. And it's typically frowned upon in domain driven design. What you want is you want the rich domain model, which focuses more on the behavior. It's not that it doesn't care about the attributes and the properties, but those are there to facilitate the behavior of that model. So my first kind of thought there is why not anemic models? If we keep things anemic, then we can reuse stuff more easily. So for example, if you have rules around, say, creating an order,

then those rules might be different for like a customer service agent or a website or a user or something, you know? Um, yeah, go ahead. Sorry. So just saying like in, in that case, I'm just kind of playing devil's advocate. Like, aren't I a little bit smaller to try and create these domain models that are a little lighter weight? If we go back to part of our conversation from last time in episode 58, we talked about the possibility of having a customer object or class, let's say, that was in multiple namespaces. And in each of those namespaces, it was relevant to that particular purpose, right?

So a customer object, as it would relate to a customer service namespace, might have different functionality than a customer object that would relate to order fulfillment. So there was a key word that I said there, and that was the functionality. And so the whole point is that in this case,

we're trying to focus this on the behaviors. We're not trying to focus on the attributes. If we focus on the attributes, they're going to get caught up in like trying to pass around this massive object that's going to contain more than it's going to need a lot of the time. Right? Yep. That's perfect. Does that make sense? Yep. Okay. So in that case, would we keep like our data model at a lower layer? It's in a different layer. So if you think about it, and this is actually the question that was asked, let me go up to episode 58.

This is the exact question that was asked was, well, wait, what are you saying? Are you saying that you're going to have like almost duplicates of this? Like, what does this mean? How do you move this in and out of the data? And actually, I think it was Joe recursion, Joe, who asked the question, hold on one second. Let me find it. Yeah, so it was Joe recursion, Joe. So he says this, I'm actually going to read this because I think this is incredibly valuable. And it goes to your question. So could you elaborate on something using your example, if accounting calls someone a customer, then the UI would use the term

customer ID and customer name. And the backend database would also use the term customer ID name when accessing the data. In another department in the organization, they called them user, but had to reference the same database. Then the UI for the second department would say user ID username, but the referencing customer ID and name in the data, which would make for some confusion or am I not understanding it correctly? What would you use a design pattern to transpose the customer to user? So here's the thing, and we'll be catching up to this in a future episode,

but I want to go ahead and cover it now because it's very relevant to what you just said. There is a translation layer in domain driven design. So let's see first. Thank you. So yes. Okay. The short answer is you have a translation layer called the anti-corruption layer in DDD terms. So basically what happens is this, you'll probably, if you're using an ORM, let's say, right? You know you have your database tables that have the word customer in them, right? You're probably going to have, let's say that you're using an entity framework or Hibernate or whatever you're using in whatever language that you have, but you've got this mapping. So you've got this customer that's going to have all the attributes that

map to the table in your database or whatever your storage facility is. Now from your domain layer, you're going to have these anti-corruption things that will basically move data from your domain model into your data model and vice versa. If you need to load up one of those things to bring it back into your domain to use somewhere, then it'll take it out of your data model, whatever it was, and push it back into your domain model. So it's a translation layer is all it is. Okay, so I think, so yes, you will get many of these things, right? Like depending on how many departments you have, you will likely have a translation layer for each one, right? Assuming it doesn't map over one to

one, which it probably shouldn't because the whole purpose of this domain driven design is give people what they need, not anything more. Don't let them mess up the state of an object just because they have access to it, right? They, if they don't need your first name and your last name, all they need is your address to ship. Then they shouldn't have access to your first name and your last name, all they need is your address to ship, then they shouldn't have access to your first name and your last name, right? It shouldn't be there. So in order to get that stuff, you might call your repository.

It will load up your data object and then it will translate it over to your business object. Okay. I was trying to think of some examples in the open source world where i'm happy to see kind of some like real world code um i'm not really having much luck though so if you're listening this episode and you know an open source project that that kind of does this then we'd love to see it i was kind of thinking maybe magento it's kind of an

open source like cms kind of thing that also does some shopping and some other stuff i thought that might be a good example but um i don't know. I'd love to see some. So here's an interesting thing. So I will say, and I want to plug the Pluralsight course on this because it was kind of an inspiration for the flow of this because they did a really good job laying it out. And I'm sure they spent a lot of time doing this. So the Pluralsight course with Julie Lehrman and Steve Smith, they go over this and they actually create an application. And if you are one of the, you know, I don't know what tier it is, but if you're a subscriber, you actually get access to the source code and you can take a look at it and see exactly how they did it. Another thing I want to point out is the book that we bought, the domain... Domain Driven Design by Eric Evans.

By Eric Evans, yes. Literally just Domain Driven Design. He even says when he's doing the book that he tried to purposely do applications that weren't perfect to where you run into these difficult questions. So I believe he goes into a lot of detail and code in the book. We haven't actually gotten that deep into it yet. So I can't, I can't really say that much, but he did say in an interview that, you know, he wanted to do something that was more real to life to where you run into these problems that are like, oh man, what do you do here? And so it's not a perfect world scenario. So, so I would imagine that he's probably got some code that goes along with the

book that might help demonstrate this as well i'm thinking like firefox right there's kind of only one domain user there like what i'm really looking for is like some sort of software that kind of caters to these different domains so i can kind of see the intermingling in one spot i don't know we'll think about it yeah i'll to, I'll have to see if I can find something for that. Cause it's interesting. It definitely helps to be able to see this stuff too, because I mean, talking about it,

I think hopefully we'll be able to portray the concepts, but it is definitely hard to get your head wrapped around all of it. Like when we go into onion architecture in the future, like unless you actually see that thing, it's, it's hard to actually, you know, conceptualize all of it.

You know, tweet Eric Evans about it. There we go. Wish me luck. There we go. Maybe he'll come back and be like, check out this repo. Yeah. So one of the other things here is this is not where you want to store the technical details necessarily of everything. So this is where I was saying that you don't want a bag of attributes on a class.

That belongs in your infrastructure layer. That's what's actually going to save to the database and do all that kind of stuff. This is literally where what you said, you want to focus on the functionality of whatever that model is supposed to be doing. The behavior. The behavior. Probably the better word that I should have used. What can you do?

Not necessarily what are the attributes that belong to you. Right. So moving on. Okay, so this brings us to one of the first topics of this. Well, just to illustrate that too, that last statement that you made, is that like, you know, what can you do, not how do you do it or what do you have in order to do it. But like, you know, an order object should be able to charge, an order should be able to charge a payment mechanism.

Yep. Right? But I don't need to know what data it has internally in order to make that happen. Correct. I don't want to care about that. Right. I just want to focus on that behavior, that it should be able to get paid. Yep, totally. Yeah, and it's kind of foreign too, right?

Like when you think about this, because a lot of applications that we've probably traditionally programmed in, you have this object that has all these properties on it. Well, let's go back to episode 57. And we were talking about like, where do you start? Where have we typically started first, right? And so often the case was like, okay, well, this is what the database looks like. So I'm going to create an object that represents a row in this table. And then I'm going to start building out from there. And so, yeah, we're always thinking of like, oh, these are all the attributes that I have available to me at this time. Yep. And you know, the funny part is, and Joe, you'll remember this. You remember working on

tax things with orders, right? And it's funny because initially you're like, well, having all these properties here makes things easier. But as you start getting deeper and deeper, it actually makes it so complicated because you have all these, well, if this, then this, if that, then this, and it just turns into this mess to where you can't even make heads or tails of it anymore because all that data is being operated on in one place, right? Yeah, so much easier to just kind of have a separate system that does that and then you interact with that than trying to build all that stuff and if-thens around everything you've already got going. And that's perfect. What you

just said is really the key is there's another system. There's this other business domain that handles this piece. You call that business domain and you say, I want you to calculate taxes, right? And it will do it. And so you start breaking these things out into domains and it makes it easier for you to reason about your application. And actually it helps you test it. It's like the whole thing we talked about with global variables in the past. You don't use them because you can't isolate their changes, right? If you have these domains, you know exactly how that thing works.

Well, this would be a service in domain-driven design speak. Yeah. Right? So you might have a tax-calculating service. Yeah. Right? So you might have a tax calculating service. Yep. Right? And you pass in your objects and then it would just give you back,

here's the result. And it will use its own domain models to make that stuff happen. Yep. And you know, there's so much metadata. Like a lot of people think taxes, like you just kind of, you know, ship the amount.

But if you're doing it right, then you need to know things as far as far down as like um the street address uh for for the order and also um you know what types of items like buttons aren't text in pennsylvania and you know and there's all sorts of crazy stuff you start getting into value-added text international oh yeah like we're scissors i don't remember uh they were last year what about this year i don't know you know all that stuff changes so you have to know a huge amount of metadata so it's so nice to be able to kind of keep that stuff separated and so yeah maybe a big part of domain is um domain driven design is just recognizing those domains and uh figure out when to kind of intelligently break them apart into

services and knowing when and how to share stuff yeah it's like we said in the previous episode if all you're doing is cred type operations domain, domain-driven design is complete overkill. You don't need it. If all you need is something that's here's a form, update this in the database, this is totally out of the realm of anything you need to worry about. But if you need to worry about complex business needs, this is where this comes in. So one of the key parts of domain- driven design in the domain layer are entities. And this whole part kind of messed my brain up a little bit when I first got into it,

not because of this one, but because of what they should contain and what you should strive to use. So an entity is basically an object that has an identity. So if you are coming from the database world, this is something to where you're going to have an ID in your database and you'll be able to look it up. That's like, that's the easiest way that I can portray that to anybody.

Is it something that you can, you need to be able to reference by some sort of property somewhere, or maybe set of properties. That's an entity and it's mutable. It can change. It has state that can change over time. And this is where things get a little bit crazy. So did either of you guys ever mess with Angular 1.3?

I did, but yeah, it was a long time ago there. Okay, so one of the key... The funny thing, I just said a funny statement. A long time ago. But... Yeah, I was talking to someone just that day. I was talking about how long ago Angular 1 was. And I was like, wait a second.

As we speak, I'm RDP'd into, I think it was 2003. Right. And it didn't seem that old. So it's just funny the different expectations you have for different types of technologies. Well, JavaScript does move at the speed of light. So that's not quite the same. Angular, you seem that old. So it's just funny the different expectations you have for different types of technologies. Well, JavaScript does move at the speed of light, so that's not quite the same. Angular, you're so old.

Yep. Angular's like my grandfather's language. Oh, dude. Or framework. What is it now? Angular 4 or 5? What's that? Is it 4?

I thought we were on 17. It might be. Didn't they drop the number? I don't know. Angular 1, 2, 4, Angular. Angular 95? Oh, man. So Angular ME?

One of the key things of Angular, and I think even if we're talking about MVC, is this whole idea of binding, right? And it's usually two-way binding. If you update the UI, it'll go to the model. If you update the model, it'll go to the UI if you update the model it'll go to the ui and that all sounds awesome until you start getting this nest of things that you can't figure out what updated what and why it triggered something else to change and it gets really

confusing and we've talked about why react.js is so sweet when used with something like redux or flux or one of those is it's the single way flow of data. So it's very easy to reason about what's changing and what's happening. You can actually follow it. One of the same concepts applies to entities and it comes to with associating entities. So think about in a order system, you have an order. Well, that order has a customer. That order also has order items. When you go down to the order item, should you be able to reverse your way back up to the order? If you're at the customer, should you be able to reverse your way back up to the customer orders? So if you have this two-way flow, you greatly complicate your model because the navigational

properties on it alone are going to be a bit of a pain to work with. And so one of the key elements that is talked about is, do you need that bi-directional flow? If you don't, don't build it in. Always start with a single way flow. Start with whatever your top entity is, and then just associate it to the next one maybe buy an id right and then that way you have a single way navigation throughout and it kind of makes sense it's more simple or it's simpler i should say is the proper way to say that i was thinking like um it would kind of stink if you had like customers and they're each customer had a cart object for their current cart but then if you say import a customer list or something or import something from a new system or somewhere where carts just don't even make sense,

now you've got this kind of dead weight hanging off. And so it makes it harder to reuse entities. And it's interesting because if you think about it again from the ORM standpoint, a lot of times you can reverse navigate your way through things. That's not how you want to be thinking in your domain model. You want to be thinking about what do I need on this entity? If I need to just link up this other entity, then I can put an ID down there, but you don't necessarily, you might not need the person's name. You may not need their address. You may not need any of that. You just need to know that it's that person. And so you might just keep that ID. So you really want to think about what do you need? Not what will you possibly want to use

at some point? What do you need to make the behavior work? So that's one. And I already said, start with the, with the one way associations. It, it greatly simplifies things and it makes sense, right? Like if you've only got one way to go. Yeah, as I was going through this, I had a note that was kind of similar to this where it was that DDD prefers unidirectional relationships. And I wrote a note for myself. Was it the, I don't know how to pronounce it, the Y-N-G-N-I?

Oh, Yagni. You ain't going to need it. Yeah, you ain't going to need it. Perfect. Does it prefer direction? Up seems pretty awkward. Down. Well, I was just saying like prefer, you know,

DDD prefers the interdirectional, and if you only went that way, you're probably not going to need the bidirectional, and that's kind of why I wrote that note for myself. Yep. Uh-huh. uh, bi-directional. And that's kind of why I wrote that note for myself. Yep. Uh huh. But also I had some other notes here too, that was kind of interesting as it related to entity objects. But now I'm like,

you ever look back at some of your notes, you're like, why did I write that? Yeah. Cause it was like, you know, I wrote that entity objects shouldn't have an equal operator. Oh,

and I'm like, yeah that okay i do remember but i don't remember so it's interesting because the whole purpose of that is and we'll get into this in value objects we should bring it back up actually we should make a note in the show notes for this the reason is is because an entity object has an ID. It has some sort of identifier. So there should never be this notion of is it equal. You have a reference to

what that object is. That's why you should never have does this equal this. Is it okay to say does this ID equal that ID? But at that point, I mean yeah i guess you could really what you're asking are these the twos are these the same reference is really all you should be asking right well it felt weird though because like there was this um okay so because you kind of hinted on the value objects, and we're definitely going to be getting into value objects here more, but in order to talk about entity objects,

we do have to, at least at a cursory level, talk about the value objects. And so another one of the notes that I made was that it was an orchestrator of the value objects. But to say that the entity object shouldn shouldn't have an equal operator my immediate response was like oh so that implies that the value object should yes yes yes but you know i didn't see anything that like came out and clearly express that we'll hit that we'll hit that after the break here okay and then but then, but then I also had

another note for myself that was like, you know, the entity object, the methods on the, on this thing are high level methods that read like,

uh, use case level type communication. Yep. Right. Um, you know, so,

so they're not very cryptic. Correct. It's like order.cancel. Is that a good one? That, I suppose, could be one. Ship order, fulfill order might be one. But it's not going to be, I'm trying to think what my cryptic one might be in relation to our e-commerce example here that we're going along with.

Maybe you've drawn a copy order so i imagine like in code what this might look like is get hash code i would uh i would ask the service i would say something like um get me order i would pass it in id right and it gives me an order entity and i could say order.ship right or order.cancel or order.clone oh oh no here's here's probably a legitimate one then like uh you know i mean i mentioned the hash code one as an as a joke about like you know if you're if you were doing uh equal operators but um i mean you probably wouldn't want you probably wouldn't need a method like get order id right right because that that's not like a use case level type event, but you know, fulfill order or ship order like those are high level type communication.

Do something. Yeah. Yeah. Yeah. All right. So before we do get into value, obviously I do want to take a moment to ask you that if you haven't yet left us a review, we would super duper appreciate it if you would head to www.codingblocks.net slash review. And from there, you can find links to Stitcher and iTunes. And please take the time to leave us a review. We will be forever grateful if you did that. And if you have already done it, we super appreciate you taking that time out of your busy day to do that. It really does put a smile on our face when we read those.

And so with that, let's take a brief break here and let's get into my favorite portion of the show survey says all right so the uh i i guess we should just call it like the the coding blocks feud from now on oh yeah um so in our last survey we asked how cool is your company and your choices were extremely cool they pay for my conferences very cool they give me time off for conferences and lastly they suck i'm lucky if i get my time off approved all right so i'm gonna pick one of you guys to go first i think joe went first last time, maybe. I don't remember. So I'm going to go with Alan. You get to go first this time. I'm going to say very cool, middle of the road with 32.35%. 30.25%.

32.35%. Oh, 32.35%. Oh, my gosh. How could I mess that up? 32.35 32.35 percent oh my gosh how could i mess that up 30 32.35 well let me write that down thank you for making my life complicated um all right joe all right i'm looking right now i'm trying to actually search uh search slack and see what slack had to say about it i've been kind of absent the last couple of weeks. I was trying to log in and look at the poll. So you're trying to cheat is what you're saying. I'm trying to research.

Right. Yep. I'm gathering evidence. It's just like me back in college. You're doing it the night of. That's no good. I'm going to say what Alan said plus.001. Come on, man.

32.351%. I can't imagine a company not giving off time for conferences. I mean, they may eat up your PTO or something, but I imagine them being pretty happy with that as far as things go. So I'm going to say that with 40%. Wait, which one did you pick then because same one oh you literally picked the same one yeah he just he just upped me to 40 i'd like to change mine to one dollar please really yes i wish you guys would like make this more fun you can't pick the same

one but we're both right aren't we all right so so extremely cool very core they suck and you're both picking very cool uh alan at 32.35 percent of the vote and joe at 32.36 percent of the vote thanks joe uh well by price is right rules you're both wrong you both lose really did we go over really uh you both went over and that wasn't the most popular one either extremely cool okay extremely cool that's awesome that's great yeah yeah so we should do a conference yeah it won it took 40 percent and actually um you guys were were extra wrong because very cool was the last. How bad was they suck? 34.5% of the vote for

lucky to get your time off approved. Ouch, man. If you're in the third that can't get the time off, now you know there's a third out there that would love to send you to a conference. There's another place to be. Get that resume polished up and link us in yeah wow so with that that takes us into

our survey for this episode where we ask what's your headphone style of choice while coding and your choices are on ear great sound in a compact shape or my preference over ear sweet pillows of sound or in ear i need all the sound in my head or earbuds because the pain is worth it pain i feel like this is biased sweet pillows of sound or because the pain is worth it well what he's got on his head right now are truly sweet pillows these are amazing but but i will say sweating just looking on the earbuds and the in-ears let's just make sure we understand what these are in-ears actually go in your ear canal the earbuds think back to the iphone three days where you got this big speaker that you kind of crammed into your ear and it just sort of sat there on the lip of it waiting to fall out those

were earbuds but you're wearing earbuds now right you've got like some sort of like kind of squishy something or other and it just kind of sticks in there in here these are in ears so these go down in so yeah they've got the uh they've got the little foam things on them. You squish them down real nice. We don't have in-ear on the list, though. We have on-ear. No, in-ear. No, we have in-ear.

It's the third one. Oh, yeah. Okay. Okay, yeah. In-ear, that's an option. So that's the winner. Yeah. We don't have any biases at this table here.

Right. Hey. Earbuds are terrible. That's the worst. They are. They're horrible, man. So I do have like one little wrench to throw into the works here, though. Uh-oh.

A new thing that I heard about. I don't know if you guys have heard this yet, but have you heard of – so we're playing this based off of like the old family feud style kind of thing, right? I heard of this new thing called Google Feud. Have you heard about this? No, but that's exciting. So we're going to play a quick game of it. Okay.

Oh, boy. And instead of it being like the old school, you know, like we surveyed 100 people, and these are the top choices. I'm going to give you a statement, and you're going to try to guess the top search results or suggestions that Google's coming back with as you're typing it. Can we keep it PG-13? You can't type it, so hands off the keyboard. Okay. Hands off the keyboard.

Let's do some hands there. Hands up. Hands up. Hands off the keyboard. Let's do some hands there. Hands up. Hands up. Hands. All right. So programming is, and give me what you think the top choice is going to be. Oh, man. Do we have to buzz in?

No, you can each just give me your own choice. You said hard? Yep. Wow, I'm having a blank. Yeah. Programming is fun. Okay. Well, Alan, I hate to be the bearer of bad news, but you're one. Okay. Well,

Alan, I hate to be the bearer of bad news, but you're one. Is that number one? Number one choice is hard. Number two is fun. Programming is easy as the third one and then programming is too hard is the fourth choice. Programming is easy.

What jerk said that? It must be true. Google came back as the fourth choice. Pro is easy. What jerk said that? Somebody who does the program. It must be true. Google came back as the third result. It really, really is hard. Do we actually have to finish? I kind of want to play this game some more. Okay, let's see.

Let's do... Okay, wait a bit. How about if I say... Singletons? Anti-pattern. Okay, wait a bit How about if I say Singletons? Anti-patterns Okay, fine Oh, yeah, that's not going to be fair That's what it's going to be

He's already going to know that one No, I haven't done it I bet that I haven't typed it But you know he's going to know it, though Did you do it? Every once in a while I just do the search just to laugh Actually, I don't think any one of us would have got this

All right, fine So pick something else Because I just Oh, you did Yeah, I did search just to laugh actually i don't think any one of us would have got this all right fine uh so pick something else because i just oh you did okay okay um let me think here let's say design patterns okay i was gonna go with that one but all right fine big o notation all right so design patterns are what do you think the number one suggestion from Google? Hard. I was going to say the same thing. Easy. I feel like that's just, you guys are just reusing your answers from before huh bad

bad is the number one bad missing language features are the number two suggestion and overrated is the third wow that's a good one all right okay yeah so about the ddd domain driven development oh man don't don't do that to me we're in this episode what if it comes back Okay. What about DDD? Domain Driven Development. Oh, man. Don't do that to me. We're in this episode. What if it comes back something bad? And I'm like, oh, man. It comes back with something slightly unexpected.

What's with the overkill? Well, I mean, now we can't because you already did it. No. I can do another one. No. What's another one? Actually, we should move on. All right, now I want to see it.

Now I really want to know. Jeez. Thinking like programmers. All right. Well, the other one that I was going to go with just as a joke, because sometimes we've joked about picking on other languages, right? So I was going to pick something like JavaScript or Java. So which one of those languages would you like me to?

JavaScript. JavaScript. JavaScript. Okay. So JavaScript is, what do you think? I'll go ahead and tell you, neither of you are going to get this. I was going to say everywhere. Is everywhere.

All right. That's a good one. Joe. Sorry. I've been looking at the complicated stuff you guys are talking about. I don't want to talk about it. What was the question? JavaScript is in our Google feud.

Oh, JavaScript is terrible. Oh, come on, man. Show some love. It's probably the thing I spend the most time with so obviously I don't hate it but I hate it yeah you would have never gotten this one the top result is is array and it makes sense

is it an array man alright that about sums up my experiences with them the top three for javascript are really awful is array is numeric easy for me to say, is null. Is NAND.

Is NAND, yeah, there we go. Oh, man. All right, well, that'll be fun. That is fun. I like that. That needs to be another part of the show. Until everybody's like, man, you guys need to cut that out. You play too many games.

Right. All right, so on to what we alluded to a minute ago value objects this is the part that messed me up is basically what it is is it's an object that measures quantifies or describes a thing in the domain its identity is the composition of its values. It does not carry an identity field. It has, you can't reference it. You can't look it up anywhere. It doesn't exist like that. And it's immutable. You can't change it. You throw it away. If you change it, it's a new object. That's all there is to it. And the equality thing that you brought up earlier, the way that you do it is you compare all its values. And that kind of makes sense because the whole purpose of a value object is

it's only a value object because it's composed of certain properties or values and it can't go ahead. The last thing you can't have side effects. Okay. I was going to throw out some examples. Like I initially thought money, I see that one's in the list here as like a good example. it can't have side effects okay i was gonna throw some examples like i initially thought money i see that one's in the list here as like a good example um i was also thinking like if you've got like a

temperature or something then you might want to bound that like you know into you know you don't want to allow temperatures of 3 000 or something you also want to say like you know 100 is equal to 100.1 or something but those aren't composite no they are. It's perfect. So a temperature. So the reason why money matters is because if you say I have 50,000, what do you have 50,000 of? Ruples? Dollars? Cents? Like they're all completely different meanings without the unit.

Same thing with the temperature. It's 15 degrees outside. Well, if what are you talking about? Celsius? Fahrenheit, Kelvin, like, so you actually need like even, even a Scoville, right. On a, on a temperature scale for foods. So there's, there's so many different things that the value object itself only has meaning when you combine all those properties. So 100 degrees Fahrenheit is way different than 100 degrees Celsius, right? That would be a value object.

Now, here's the interesting thing. A value object, like a temperature one, you could add a method to it saying convert to, and then you could tell it the type that you want to convert it to. So if it was stored in Fahrenheit, then maybe you convert it to Celsius or centigrade or whatever you want to call it. So, so that's what a value object brings you. It's immutable. Once you set something to a hundred degrees Fahrenheit, that is the value of that thing. If you want to change it to 99, it's no longer the same object. You toss that old one, you create a new one. So if you think about it, like, uh, let's say that, let's say that a house is your, is your class, right? You have a

house, you have an inside temperature is a type of temperature value object. Then you have an outside temperature. That would be an outside temperature value object, right? It's using a temperature value object, but you can store those two things and on their own, you know, they don't have an identity. You can't go look it up in the database, say, Hey, give me where ID temperature was this, right? It's not like that. It was stored on your house object okay so the one thing that i kept okay so so okay where to start i i understand conceptually where they were going with this right like what what the um the idea was here right and and some some examples of value objects. But when I was trying to relate this back to a real world, and you mentioned like money being a great example, I'm like, okay,

yeah, I see your point about that being a value object. Now, tell me the last time in an e-commerce system, for example, where you created a whole separate type for money and you didn't just use like a double. And that's the problem. So it is the problem. And that's why this totally just messed with my mind. Cause I was, cause what they say, and let's back into it. What they say is you should prefer value objects over entities. When you can compose all your entities of nothing but value objects, if you could do that. And so backing into this, let's go back to that tax example that we talked about. Dude, there were so many things that were frustrating.

Because like you said, sometimes it mattered about the zip. Sometimes it mattered about the product. Sometimes it mattered about whatever. If you weren't using us dollars, if you didn't have that specified and you were shipping overseas, now all of a sudden your logic was really dirty, right? Because you had to say, Oh, well this was 50 us dollars, even though you might not have specified it properly, like because it was two different fields on in your class, right? You would have some sort of if statement, hey, if this was in US dollars, then do this calculation. If it was in Australia and do this. So you get into that whole world of things. If you have a value object that has those things in it, you can control all

those things in one spot you're no longer doing all these if if scenarios you could literally kind of put it in one place for it to be done so the key is your money has no value without its unit it doesn't mean anything saying a hundred thousand i want a hundred thousand i just want to put this out there. If your money has no value, you can hand it to me. I'll just hold it for you. Well, people probably would have done that with Bitcoins a long time ago.

$2,000. You just won $2,000. $2,000 now? Yeah, when I bought mine, they were $40. I sold them. You sold them? Man. I remember you buying those. I remember talking to you about it years ago. That's why it's so sad now. I know.

I should have hung on. Dude, you'd have been worth millions. So I got an idea for a value object here that's kind of bigger. A box. A box can have a weight. It can have a length and a width. And let's say if you're an Amazon or something like that, then you've got all these values that are immutable.

They don't change. And you can say, you know, are these two boxes the same? And you say, well, are they the same size or the same weight? Are they the same, you know, say strength of cardboard? Oh, that's true. That's a great, great, great analogy. You don't care about that particular box. You care about the properties of the box right you're not gonna

go look it up and say i need box id one two three four five right that's not it you want i want a box that's 12 inches long but 12 inches wide but 12 inches tall and is you know built of whatever strength cardboard which by the way there's a great podcast episode on that if you guys haven't heard of it have you ever heard of no oh man come on what's the uh i'm gonna have to look it up hey i was gonna say this is the part where he asks us the name of the title of the podcast he's trying to remember man uh surprisingly awesome surprisingly awesome is the name of the podcast they have one on cardboard the episode was surprisingly awesome like i didn't know that I could care that much about cardboard. It was amazing. Wow. So at any rate, yes, that's

a perfect example of something that is not an entity. You never need to look it up. You never need to be able to change it over time. It is an immutable object that you can have thousands of them, right? And you can compare them by saying, hey, if you can hash these values, right, get hash code on the entire object, does it match this hash code? Well, it's the same thing. It's the same box. Okay. And another idea too, is that we've mostly talked about custom value objects, but they don't have to be custom, right? Like an integer is a value object or a decimal or a, you know, these are simple values that you can compare. They're immutable. You know, you can say this four equal four. Um, so I think I understand

what you're saying. So let's say that if you wanted a, the range was something that you mentioned earlier, let's say that you had a number. I don't know, maybe it was a score, you know, like a grade on a paper, right? It's bounded. You have zero and a hundred. That could be a value object, right? Like you have a bounded range, a score or something. So the properties are, this is your value and these are the ranges you have to stay within. So that could be your value object. So it has to be bounded in order to be considered a value? No, no. I'm saying if you wanted to use a simple thing like an integer as what your thing is, there has to be a reason.

Just saying something's an integer doesn't really make it a value object. It's not an object. It's just a property. Yeah, but value object in the way that it's being used in DDD though, integer wouldn't count. Right. Because you can change the value of the integer.

Right. Well, you can't change a 4 into a 3. You can set whatever variable to a 4. But whatever that variable is, though, yeah, but that's the same variable, though, versus if you changed a string, you're actually getting back a point or two, a new piece of memory. I guess the point is, though, an integer on its own isn't an object. It's not inherently anything that has any kind of value to it, right? Like, there's no collection of properties that make this thing up. So I think that's probably really the point is, it's two or more things that compose this

value, I think, from my reading. Two or more things that compose this value. I think. I mean, I guess the point I was trying to make is don't confuse, like in past episodes we've talked about like reference objects versus value objects. And let's not confuse that terminology here when we talk about value objects in the world of domain-driven design. Right, it's not a function of the language. It's a function of what it is.

Like you can't change a temperature from 100 to 99. It's a new temperature, right? So I think that's kind of what they're getting at. Like you can't change the value of the number 19. Well, no, no. Let's get away from the number examples because that's kind of what they're getting at like that you can never like you can't change the value of the number 19 well let's get away from the number examples because that that's getting weird let's go back to your box example i can't make this box a bigger box it either is big or it's not if i need a new box that is bigger i have to get a new object right right so i can have i can have an object that points to a box. And if I need a bigger box, it's a whole different object, right? You replace it with that new bigger box, right? I had to

physically replace the box. Yep. So a value object is typically just, just so that we're on the same page here, it's typically going to be an object type. So let's say that you have a class house, you have a, let's do, let's do Amazon. You're shipping, right? You, you have a class house, you have, uh, let's do, let's do Amazon. You're shipping, right? You, you have a shipment and then on that shipment, there's going to be a box where things are going to get packed into. So you might have a property on that shipment class. It's like, you know, shipment box, and then it's going to have a value object with the length, width, height, you know, strength, all that kind of stuff. That's it. It's literally, it's almost the whole composition approach of designing a class. So if you do need a new box, you're going to throw away that old one and replace it with a new one.

Okay. So let's skip into services. We kind of hinted on this before, but these are the core of your application, right? So we talked about a tax as an example, a tax service as an example of it, right? Being able to properly tax, anyone in the accounting department of your company is going to agree. Like, you know,

if you're not taxing correctly, then, you know, you're up the creek, right? So that's a core part of your business, right? Yep. Yep. It's another layer, right? It interacts with your domain. So like you said, tax.charge tax or, orService.chargeTaxesForOrder will then know how to interact with the proper domain entities or models or whatever it is and carry out those. And that's going back to that whole layer thing that you were talking about earlier, where you're going to have your infrastructure, your domain services, your domain models, all that. So it's another slice in there that typically is going to be more than likely if you're doing it properly, it's probably going to be a bunch of interfaces and get injected through, you know,

some sort of IOC type thing. So that's generally what you're going to do. So this is functionality that isn't a part of your entity objects or value objects wouldn't have any functionality. So there's not a part of your entity objects. Right. It might even need to interact with multiple entities, and so it doesn't really belong on one entity. I think is really what it boils down to is if it doesn't fit neatly in one of your domain entity objects,

then, then you probably move it out into a service. Although we're good, we're not getting into it this show, but that'll bring up the topic of aggregate roots in the next one. And that brings in a whole nother layer of, oh, well, this is where you do a lot of things. So, but yeah, generally speaking,

if it doesn't fit well on the domain model itself, then you probably extract it out into a service. So these are stateless. This is where you can get into functional programming within your application, right? So you could have, these are just stateless parts. There's no side effects on it. It's just going to like calculate something

or do some action and then whatever you requested and then come back. It's not modifying your entity. Well, no, it can. It can have side effects. The service itself is stateless, but it can totally have side effects the service itself is stateless but it can totally have side effects on whatever it's interacting with okay so it can modify yeah it can modify but it itself is stateless the service will have no properties you can reference anymore

but but it can totally jack up any properties on what it's using well this is what i was thinking of is like uh an example and maybe this is what I was thinking of is like an example. And maybe this is where I got messed up in my head when I said that then was that like logging as an example of a, of a service that might be in your application. It's core to your application, being able to log things properly. Maybe there's like customer sensitive information. We keep talking about, you know, e-commerce examples. Maybe there's sensitive information that you don't want logged or maybe the way in which you log it or the place that

you log it like that that's core especially if you're trying to debug any problems or uh for auditing purposes you know that you might have some reasons there but it's not specific to like a line item on an order but you you've got to be careful. You've got to be careful. So that actually falls into a different aspect of domain-driven design or a different layer, I should say. That's usually in your infrastructure layer because this is where you're not really taking... Yeah, but this is a service in the infrastructure layer. Yeah, you're right.

The logging would be. Yeah. But a domain service would be something like place order or, you know, do something like that. It's a behavioral type thing as opposed to a system type, you know, you're trying to deal with storage, you're trying to get information out over here and put it on disk somewhere. So there is a difference. One is based off the business behavior and the other is based off what your software needs are and that that's your infrastructure well what i'm saying is like there's services across these layers though

right like there's not it's not like there's just domain service and that's the only one no correct there's other services across the layers and infrastructure is one of the layers one of yes yeah yes and that's where your logging will probably go. So because that's what's going to be interacting with, is it logging to disk? Is it logging to a database? Is it logging to Azure, AWS? Whatever the case may be.

And that's why. So again, that's why those are typically interfaces, right? So in your domain layer, let's say that you did need to log something, whether it be through an aspect or you just baked it in, it's going to use an iLogging, you know, service that's going to be your infrastructure layer that probably gets injected in and then it will log wherever it is set up to go. So I know it gets complicated talking about things and that's why domain-driven design isn't for a CRUD application. This is when

you start getting into enterprise-y type level of things, right? Like it can get complicated in terms of how it's laid out, but it simplifies your programming and makes it more maintainable over time. Yeah. Yeah, it's definitely, there are definitely some complications there.

Well, so with that, we have reached the end of that topic, at least for tonight's purposes. But we will have plenty of links for resources that we like related to this topic. So we will include some links to Pluralsight. There's some great courses out there on this topic as well. We'll have a link to the book. And then there's the community around DDD as well

in dddcommunity.org and domainlanguage.com, which are both great resources as it relates to this topic. And now, yeah, so let's get into Alan's favorite portion of the show. It's the tip of the week. All right. And I'm up here.

I'm staying awake. You may be on your morning commute, but it's like 10 o'clock at night here. I'm fade. It's 11 dude. Oh yeah. Terrible. Tell me about it so this week i'm stealing a tip idea from uh hubb dave i hope i said that right on twitter and um he ran into a problem with a project he was working on and uh said something about twitter on it. And, um,

I just kind of clicked the link, just kind of looking. And I noticed that he had his code on GitHub and, uh, he had a ticket for it that kind of described the issue. And he even said like, uh, it had a tag for help wanted. It was like,

it made it so easy for me to like clone. I was like the clone buttons right there. So like a lot of times we get, um, emails or tweets or people asking for help. It made it so easy for me to clone. The clone button is right there. A lot of times we get emails or tweets or people asking for help. And they start to kind of describe the problem. And it's so hard to even just figure out what the problem is. Because they kind of take things for granted. They have to explain what the app is doing.

There's all this weird stuff. They can't really share the code. And a lot of times, if it's a business thing, you can't. But my tip was basically, if you're gonna um ask for help on something and that could even be you know literally getting contributors for your project then make it easy put your code somewhere where people can see it create a readme with instructions on how to build and run it and even if it's trivial you know you think you can just kind of download the project and build it and it's obvious if it's so trivial then just write it up you know make it dead simple and create a little ticket in there you know have

something that you can show people that um you know give them an example and make it easier to get people to help you and so i thought that was really clever really smart of him to uh to kind of have all that stuff and make it easier for other people to see his code and see his project he's even got a screenshot in the readme, which is fantastic for showing people exactly what it is. Because what you may think is like a clear name for your project isn't necessarily what other people might be expecting. And so by having all that information there, boom, on one click, it's so much easier to get helper contributors.

Did you help? I tried to, but I wasn't, I had a hard time reducing the problem. So actually I went to the stab of it. So if I may, I want to reward, reword Joe's tip of the week because I loved his tip of the week. If you want Joe to help you with your code,

this is from the, you know the the developer mind that's already been like you know you know that's tired burnt out or whatever so if you want joe to help you with your code put this stuff up on github send me a read me with detailed instructions on the problem and how to run it and how to build it and then send me a ticket to the issue that needs to be fixed and then joe will fix it that's what it sounds like if you send me a ticket to the issue that needs to be fixed, and then Joe will fix it. That's what it sounds like he's saying. If you send me a ticket for something, I can't help but try and close it. I have spent so much of my life closing tickets.

Yeah, if you send me a ticket, even just knowing that there's a bug, it's going to be like, there's a bug and I'm not sure. I can't help it all. I'm instantly like, cancel the plans for tonight, honey. There's a bug on the internet the sad part is he's not kidding guys

he really isn't Joe is the eternal helper he can't it pains my soul that's what I'm saying that's what I love about this tip of the week is the tip of the week is how to have Joe help you to have a lot of responsibility like hey I assigned you a ticket.

Oh, crap. Let me get on it. It could be literally midnight on Saturday. And he's like, I'm heading back home. Hold on one second. I marked the issue in my private GitHub repository is critical. So I need you to jump on it right now.

Man, I promise you. So before I get him on a tip of the week i actually wanted to give a shout out i met this guy at at a meetup recently and he's awesome mike f robbins if you go to mikefrobbins.com he's kind of known as mr powershell this dude is off the charts good at what he does i didn didn't even know. I'm sure you guys probably did because I never really messed with PowerShell that much. I didn't even know there was like a grid that you could have pop up out of a PowerShell command. Like this was news to me because he, he actually did something to where he, he took our feed from our podcast and had it list out

all the sessions and, and it And it literally popped up a grid and it's like a couple of lines long. So anyways, if you ever have any kind of automation or anything that you need to do and you have a question on PowerShell, go to mikefrobbins.com and check him out. The dude is, he's a super nice guy and just constantly writing useful stuff

and giving it away for free. So, you know, go check that out. We'll have it in the show notes. And now that I am getting back around to what I was originally going to say, um, I go, I go off topic sometimes. Uh, so my tip of the week is it's called remarkable and it's an NPM package that you can load up in your JavaScript projects or any kind of JavaScript thing, whether it's no JS, or if you're using something like a react, this is actually where I found out about it, uh, is you can actually use markup and it will render the HTML for you. So if you're doing something like a react and you do a render and you put some markup in there, it will convert it for you to

your actual html and i thought that was really cool to be able to use it in your code so it's kind of like i guess like a jade template type thing you know you could just basically call this this remarkable dot render and it'll do the thing for you so you're wanting to use markup for your actual html that's kind of cool i don't know that i would typically but yeah you know but that's what you're describing what you're doing yeah you can use your markup and it'll write the html for you so now we've decided that html was too much effort pretty much wait wait well think about it um in some other ways like you can like take some notes and mark down or do some formatting, say, and then convert that to HTML and drop it into an email or into a wiki

or some other format. So it's not necessarily just for making webpages. There's all sorts of places where you can drop HTML. Yeah, it's just so neat. It reminded me of like jade templating and that kind of stuff, where they have their own language where you do it, except this is a well-defined language that wasn't made up that people use all over the place. And it was just like, oh, well, that's kind of cool.

I guess, I mean, I love systems that I can like add Markdown to, and then it'll render it pretty, right? And, and, you know, GitHub is one, Visual Studio Team Services is another one where like you can include like a readme.md or something like that and it'll it'll uh you know do a pretty print on it right but i never thought about oh i should just like always use markdown even for things that i actually want to be html yeah i i mean i don't even know what all use cases we might come up with but it's kind of cool that there's a little library out there that you can, that you can use.

Yeah. And it's got some cool features too. Like I noticed it's got some rules that you can kind of enable or disable like linkify. So you don't have to do the stupid markdown links, which is so arduous to type. Well, I got to say,

Alan, that is remarkable. That is remarkable. And with that, we'll go into my tip of the week uh which is uh we we've talked about a lot of these sites like uh like some of the regex sites you know where you could fiddle your regex um and this one isn't quite like that but if you ever found yourself in a case where you get a blob of j, you're like, man, I just want to see this thing in like a human readable form.

Head over to jsonformatter.org and you can dump that JSON into the left hand pane there and then click on format or beautify and it'll pretty print it over onto the right not quite in your pretty printing at that your markdown uh remarkable uh package did but you can put it into a human readable format there and you can validate it and you can uh if you wanted to go the other direction and you wanted to like take something that was already pretty and you wanted to minify it you could do that if you want to take that json you want to like convert it to XML, you could do that. You could do it to CSV or YAML. So I thought that was a pretty neat little tip because I always find myself, my pattern has been in a situation like this is I'll take that JSON that I want to format,

I go into Sublime and then I paste it and then I'm like, okay, what was the stupid command in Sublime again? I always forget. Control shift P. Oh, yeah. Wait a minute. No, I got to like select it all. Okay. Then I got to go. No, no. I said control shift P. No, no. Yeah. Yeah. Or, or control shift P, but that's going to depend on too, like which package you have installed. Yeah. Dude, this thing is picky though like you can't just put uh without the uh without the quotes so like if you open up an object and just type like i did this is ugly colon one like oh yeah you can't say uh format beautify like it's like oh you expected a string because you can't have a property that's not inside a string uh a literal and it has to be double quotes i think too yeah dude like this is the strict json uh is there like a strict option you can turn off

this is like stressing me out all right fine then fine be that way i got another one for you then you're gonna be like that so then uh hold on see i like this You get two tips because I poo-pooed on this one. Although it looks like a cool tool. Jerk. That's why we can't have nice things, Alan. Matt, like seriously, why are they doing this? They need like a Jason to Jason button. Oh, wait, wait, wait.

No, hold on, hold on. I'll take it back. I'll take it back. Hold on a second. So check it out. Check it out. So if you do this, there's a button right above the text area. The far it's,

it's on the left side, but the right one, it's compact JSON, remove all white spaces, et cetera. It will actually stringify it for you. Life is good. Which one are you talking about?

So there's two buttons just above the text area. The one on the right, it says compact or whatever. Actually, the one on the left might do it too. The one on the right, it says compact or whatever. Actually, the one on the left might do it too. The one on the left does it too. Yeah. Formatting it. Yeah.

No, no. It'll add the strings to it so that when you click format beautify, it'll actually fix it for you. I'd have to see what the example was. Yeah, that's really nice. I don't know if that's intended. It almost seems like a bug, but I like it. It makes it usable. So yeah, if you just do a little object and give it, it doesn't even matter what you call the property.

You can call it name if you want, but don't put it in quotes. And then put your name in there and then close the thing. And then if you just hit format beautify, it's going to throw an error saying, hey, it was expecting a string. However, if you come over here and hit this button, it'll add the strings in there for you. And then you can format and beautify it's going to throw an error saying hey it was expecting a string however if you come over here and hit this button it'll add the strings in there for you and then you can format and beautify it that make any sense oh i think i see what you're saying on the you had to hit the button on the left hand pane though yes so basically the way he's describing is in each pane okay so picture picture the page is divided in half and down the middle of the the

divider is all the action buttons for like minifying and formatting and things like that but on each of that panes on the sides there there's two buttons at the top one of them where you can see uh some lines that look like they're in indented and then another set, the lines on the second button where everything's just concatenated together. There's no spacing. And you're describing that if you typed in, if you just created an object with like, let's say you created a open curly brace person colon one closed curly brace and then you try to click on format beautify then you get the error but if in your left hand pane you click on that first button where it shows the json formatted then it would go ahead and put person in quotes then you could click on

the format beautify and it works which kind of feels like it defeats the purpose but whatever no well i i don't know yeah i mean it almost sort of formats it on the left for you right that's what i'm saying that's what i'm saying but but when you do that you do get these other features here this json to xml the csv the yaml so there's a lot of other features you get if you do that so but but okay this is a useful tool i no longer poo-poo on it. Well, thank you for that strong odor of recommendation. This is risen above the poo-pooing. It is

an excellent tool. Okay, so there's another one then, just because of Alan's poo-poo. You can head to jsonformatter.curiousconcept.com and put that open curly brace, person, colon, one, close curly brace. And on the right-hand side there, you'll see a JSON standard,

and one of the options is do not validate. And then you can click process, and it'll show you. And every attempt that you can click process and it'll it'll show you and like every attempt that you try to process it'll show you all of your uh it'll keep like a running tally of like oh here's where you tried it and it didn't work and here's where you tried again and it didn't work i like this so that one uh just a little shout out here was uh a tip that I heard Complete Developer pass out, the jsonformatter.curiousconcept.com. Very nice. Very nice.

And this one even has collapsing in it, so you can collapse different levels. Yeah, it's pretty. I like it. I thought the other one did too, though. It might have. Oh, no, maybe it didn't. Oh, yeah, no, it did.

The other one had collapsing too. It's just that the formatting of it looks more like what you would see inside of an IDE like a web storm or a visual studio where it's by the the line count the curious concept doesn't include line numbers in the formatting of it but it does have like this pretty little css you know plus minus uh bit both nice looking tools Yep. And we'll have links in the show notes. Two things since Alan had to poo-poo on them. I did. I un-poo-pooed. I un-poo-pooed them.

Now that we've un-poo-pooed. Hey, thanks for listening. Today we talked about the D and domain-driven design in DDD. And we were talking about software D in domain-driven design and DDD. And we were talking about software architecture, domain-driven development, domain layers, models, entities, value objects, and domain services.

So hope you enjoyed. Yes. Say that fast three times. I could barely say it the first time. Can you hear me rubbing my eyes? I can see it. I'm surprised you've kind of propped yourself up this entire time. I am a morning person.

Proud of it. Well, so with that, subscribe to us on iTunes, Stitcher, and more using your favorite podcast app. Be sure to leave us a review by heading to www.codingblocks.net slash review and you know we say check out Stitcher hopefully it's back up by the time you've got this while you're up there at the site check out our show notes

examples discussions and more and it's still down send your feedback questions and rants to the Slack channel codingblocks.slack.com and be sure to follow us on Twitter at codingbox or head over to codingbox.net and find all our social links at the top of the page.

What the hell was that? Is that not the... Oh no, it's not that one No please make that noise again Wait you don't know that song What was that I'm bad to the bone Bad

Bad That's totally going into the episode Bad totally going into the episode okay