Coding Blocks - Why Domain Driven Design

Episode Date: April 24, 2017

This week, Michael asks his customers about their anemic domain model, Allen talks in front of people, and Joe plays Rocket League as we begin our dive into understanding domain driven design. Are you reading this episode’s show notes via your podcast player? You can find this episode’s full show notes at http://www.codingblocks.net/episode58. Become a Part of the […]

Here we go in five, four. You're listening to Coding Blocks, episode 58. Subscribe to us and leave us a review on iTunes, Stitcher, and more using your favorite podcast app. Visit us at codingblocks.net where you can find show notes, examples, discussion, and more. Send your feedback, questions, and rants to comments at codingblocks.net. 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. With that, I'm Alan Underwood. I'm Joe Zak. And I'm Michael Outlaw. You know when your software is bugging out, but you just can't seem to pinpoint what's

causing it? It's always been incredibly frustrating, but our newest sponsor airbrake.io has helped change that. Airbrake groups your errors for you and provides a full stack trace so you can quickly find the issue. That means no more wasted time searching log files and more time writing and shipping great code. Airbrake supports.NET and all major programming languages. Sign up at getairbrake.com slash CB for a free 30-day trial and the chance to win a $500 Amazon gift card. It's a completely free trial, and you'll be shocked by how much time it saves you. Again, that's getairbreak.com slash CB. We'll also have a link in the show notes.

Cool. So let's go ahead and get rolling with the podcast news here. First, we're going to start with the reviews. We have several iTunes reviews, and let me see if I can do these. So I have Tomox, Dr. Kaj, Rumburger, Robbie Diesel, Heberge, Caffeine Slayer, Rgamer, GB Millard, Bob Mintier, WP dev guy, San Justo ease to catch you more deaf DK four five Oh one RCF nine AB squared X general. Yeah. I can't, I can't call that one. How about a WTF? The nickname Zach and Z Durham and Lucas and Rico? No, it's all the nicknames taken. All the nicknames taken.

Yeah. WTF, all the nicknames taken. Zaken. Good point. So, yeah, we got to keep it somewhat PG here. But yes, thank you all for doing that. We had several just awesome ones there and before we get into the stitcher ones i think there was a special guest star stitcher review

this one's excellent go ahead joe all right well the first viewer is uh named joe zach's beard tells me feeling a little conscious right now i mean it's a good beard it's not an amazing beard it's not the kind of beard you would name your stitcher of you after but whatever apparently it's good enough that it was able to reach the keyboard and do some typing yeah all right all right well five stars and yeah we got a couple other from sitcher as well we got mr edba mojo ryzen top swag code joshua kaluba takaman cruise and ssf culture thank you and for the yes we really appreciate it yes amazing amazing stuff like thank you very much for taking the time to write those yeah and for the full show notes, as well as these people's names,

so you can laugh at them, you can go to coding blocks.net slash episode 58. So there was this recent article. I think I saw it on hacker news. I don't know if you guys saw this, the top 10 things which make programmers unhappy. No. Did you see this?

No, no. Okay, great. Because we get to see this? No. Okay, great. Because we get to play a little game. Nice. So just if you had to pick one, what do you think would be the number one choice?

Each of you pick one. Dress code. That's the number one thing you think would make programmers unhappy, dress code. Yep. Have you seen the way we dress? No, that's what I'm saying. I don't think we care. No, programmers have to adhere

to one. Alright. Joe? I've got three. I'm trying to figure out which one's the worst. I'm going to go ahead and say customers. Wow, that's... Too specific? I think I should just go with people, maybe? You trying to tell us something there, Joe?

I'm a people person. Everything I thought was like, is it managers, project managers? Is it co-workers? Is it customers? Okay, well, you guys went to some dark places. I'll go ahead and tell you. But no, the top one, according to this, was top 10 causes of unhappiness.

Number one, being stuck in problem solving. That's what our job is. Yeah, I didn't get that one either. What are you going to do? I don't know. If you're not solving problems, you're not really programming, are you? Yeah, thank you. I didn't understand it now number two

made a lot more sense the rest of them make more sense but i i guess maybe the number what they meant by number one is like if you're trying to solve some problem and you don't know how to do it right like maybe that's what they mean i don't get it i mean that's part of the fun to me anyways but yeah that's the whole reason why you're in here is you like to solve problems. Like puzzles are your thing, right? Logic problems, you're all over that, right? Yep. That's why we got into programming.

But the number two was time pressure. Okay, I could see that. That one made a lot of sense to me. And then number three was bad code quality in coding practice. And that one makes sense. I like it. If you had to be stuck working with like an awful code base. Yeah.

I mean, and especially if you're like powerless to do anything about it. I'm just surprised that's number three, but, but yeah. Well, yeah. And by the way, those three were i mean they they were the top three but the

next seven were like definitely you know some distance away yeah yeah yeah uh just to round out the list though uh number four underperforming colleague. Number five, feel inadequate with work. Six, mundane or repetitive task. Seven, unexplained broken code. Eight, bad decision making. Nine, imposed limitation on development. And lastly, personal issues, not work related. Okay. What's the self-imposed one development issues self-imposed or wait what uh what i think you mentioned one that said something

like um not developing self-imposed and together like number it was number nine i think is the one oh imposed limitation on development. Yeah. What's that? I think that's like, you have to do this language or maybe, maybe, maybe you're constrained by what you're allowed to do.

Like somebody is telling you exactly how to do something. Well, I interpreted that one is like when process gets into the way possibly, right. Where it's like, okay, well let's spend more time on creating tickets and estimating tickets and okay well before we can make this line of change we have to have like everything possibly designed and architected under the sun and you know we're gonna we're gonna big design

up front this whole thing before we even write the first line of code like that's what i took and then micromanage the heck out of it. Yeah. So this is totally off. It's not in our show notes, but I'm curious what you guys think about this because I feel like programming is a very creative practice. And you'll have some people or some managers that want to dictate how things happen or they want to drive exactly what's happening. And if they have a task and they have in their head how it's supposed to work out, they might say it's a day, right? I actually don't feel that way about programming. I would rather somebody take the liberty to explore the problem a little bit more and maybe do it in a particular way because I feel like without that, you get people that don't understand things as well because they don't take the time to dive in. And on top of it, if there's not some sort of magic behind it, like you do have a tendency

to really just lose focus and interest on what you're doing. Like, I'm curious as you guys' thoughts on that. Yeah, definitely. Some, some of the books I've read, uh, really stress the importance of autonomy and feeling like you can make decisions and make a difference and to have a stake in the matter rather than getting things kind of handed down to, um, things like people where,

and I forget where else I've kind of read that, but whenever I hear about motivation, like on any, like, um, say like, uh, hello tech pros or,

uh, like, like motivation is always, um, closely tied to autonomy so i think that sounds about right yeah i mean i definitely feel like it's important to let people explore other patterns and see what else works you know uh we can't assume that we got it right the first time and that that first time that we got it right will be great forever and for all use cases. Yeah.

It's just always been something that's bothered me, right? Like if somebody says that, no, I know that this is how it needs to be done. So you create a ticket that literally specs out exactly how everything's going to work. It kills what enjoyment people get out of it. I'm not saying people need to go down into a hole and program on something for three months. It should take a day, but it was just something that I feel like if you're managing or if you're a developer, you need to figure out how you can hit that happy balance to where,

you know, you are, you're getting enjoyment out of it, but you're also nailing what you need to do at the same time. So, but there are some developers I know I've experienced in the past working with some developers where they just prefer that you spell it out exactly verbatim, exactly what you want from them. They don't want to have to put any extra thought processes into it.

They don't want to think about it. They want you to spell it out. And whether that be from a laziness on their point that they don't want to experiment or think about it it or whether it just be that maybe they got beaten down too many times in the past where it was like no that's not the way i wanted it done and they're just like okay fine i give up right i'll just however you want it is the way i'm going to do it yeah that's true programmers can definitely be a pedantic bunch but uh i just looked up the the white paper that this came from and um saw their example of the imposed limitation on development and it's actually

um the example they give here in the white paper um basically refers to uh having to find workarounds or mess ups mess up otherwise clean code um repeat code on the series basically dealing with crappy frameworks is how i'm reading this but i might put my own spin on it. But some sort of blockage that you feel is like, like shouldn't be there. Interesting. Okay, cool. All right. So, oh, this is from one of my previous tips of the, of the episode. Yeah, the week. It's been a few weeks since we recorded. I had brought up the tip that you can debug store procs and SQL code in SSMS for SQL Server. And Nate the DBA over in Slack was kind enough to say, yeah, be careful with that. You don't necessarily want to do this in a production environment because it can, much like if you wrap a begin transaction around something that you start and you never commit or roll back that transaction, it will actually lock the tables in anything that's trying to access those.

So just know that while you're stepping through your proc thinking that you're just being a good guy checking all your stuff out, you could be bringing down that server. Which is now would probably be a good time for a PSA there to say it's probably a bad idea to debug in production anyways. Man, how else you get a cowboy code? You know? Yeah, it's not the right place to do that kind of stuff. But, you know, I did want to bring it up. Even if you're working in a development environment, right? And everybody else is working off a central server, just know that you could be screwing everybody up. So thank you for that, Nate. And I wanted to share that. The next thing. So the last time I said I was speaking at a, at the Atlanta JavaScript meetup, and I have now spoken at the Atlanta JavaScript meetup. And I got to say it was fun. But what

really sucks is when you follow up a dude who's got one of the most polished presentations you've ever seen with about 40 demos that all went off without a hitch. Like that kind of stinks. Yeah. So here's the thing. So as an audience member, I mean, one, Alan's presentation was great. Oh, well, thank you. Thank you.

And he's not lying. He had a hard presentation to follow up behind. I mean, because he's not joking. He's not exaggerating when he says that that guy had 40 different live code demos that he gave. I think the title of the presentation was JavaScript Everywhere. Is that right? Yeah, JavaScript All the Things or something like that. And it was like, oh, let me show you.

Okay, we all know JavaScript in the browser as Chrome plugins. What about if we natified it to a mac desktop or the mac toolbar or what if we like run it on the iphone natively like what if we hook it up to a google home device what if we what if we show it in virtual reality like dude it was non-stop and you just look at it it was a simple app like all it was was it was a calorie a calorie counter right like if you went over 1500 oh you better slow down that kind of thing stupid simple fantastic for demo purposes but literally he had iot devices he had he had google home like the thing that another part that killed me about his presentation though was that we always talk about like how challenging like like at least for you and I will struggle for like, we want to come up with a, a quote app, right. That we can talk about for whatever the purpose of the demonstration is.

And we're like, well, what would the application, right. We need to create something. We want it to be more than a hell of a world. And then this guy had this like, Hey, what if we come up with this calorie tracker? And I'm like, Oh God, what a great idea. And it was so simple. It was literally up and down, but yeah, man, one of the, if you've ever seen somebody speak and you're like, man, that was a great presentation. Like I'm sitting there watching this thing, knowing that I'm about to follow it up and I'm like, wow, this kind of sucks. It was excellent, but it was fun. I had a good time, you know, but your talk was great though. Don't get me wrong. Like I said, Alan's talk was awesome. It was on a serverless architectures. Yeah. So again, maybe, maybe we'll

do a show here on it in the future. I would like to actually do a series of YouTube videos, like maybe stepping through doing some of this stuff, maybe in various different things, whether it's Azure or AWS Lambda or whatever, but it was fun. It was a nice learning experience and something that I'll try and do a little bit more, but yeah. I think the important takeaway from it though, is it, it sparked a lot of conversation though. Oh, it totally did. So, so, you know, no matter how you felt about your presentation, like there was definitely a lot of conversation and interaction with the audience though, based on that. So I think that's actually like a good thing, right? That's a good measure. Yeah, I agree. There's a lot of, with the way that things are changing nowadays, like, I mean, has there ever been a point in time where it felt

like things were rapidly shifting as much as they are now with the cloud and all the different services out there and all that kind of stuff? I mean, but it's been like this since the internet came out though, hasn't it? Like every three months it's like, oh, there's the new shiny thing. Yeah, that's true. I mean, there's just a lot of questions. Like it brings up the notion of microservices and how do you implement that stuff and what cost does all this stuff add, right?

Like nothing's for free. You know, no matter what you do in programming, if you want to add more scale, then it doesn't come for free. If you want to... So it did. It did spark a lot of really cool conversation and hopefully people got something out of it after that killer intro.

Yeah, and just like we were saying with the everything, wait three months, everything's changing. Just when you thought React would be a great thing and then React Fiber comes along, you're like, oh. Hey hey but wait a second we're on angular too right i think you just said this the other day oh right you know too and then oh no it's like already at four we're on angular four now so right and time flies so i got to see a little sneak preview or not a sneak preview i guess was after the fact but i got to see the uh the talk uh later at work and

i thought it was really great and i wish i I wish I would've been there, but, uh, I think you're probably being too hard on yourself. Um, you know, it's really hard to say and to know, and, you know, I know, uh, I never really know, or I get so nervous ahead of time. Like I don't even care at the end of how, like how it was done. I'm just glad it's over. So, uh, you know, kudos for even having the, the, the grit to get up there. Excellent. I appreciate it. I'm going to try and force myself to do more. So now I've got to come up with a really complicated app to do.

A really complicated one. Yeah. I would love to volunteer you for Orlando Code Camp, which I just attended last weekend. Atlanta has one, too. Just the kind of thing that I don't really know. Is it Microsoft sponsored? It usually is. It usually has really big sponsors.

I don't know if Microsoft does it. For the Atlanta Cook Amp, they are one of the sponsors. Yeah, they're usually one of the big ones, and a lot of the consulting companies around are also in there. So, yeah, there's some great opportunities to speak and also go to. It's usually later in the year here right like in the fall right yeah yeah for the atlanta area but you just had it in orlando though because that's when you try to like go all styling but i think i might have just shown you up there on

that swagger yeah you got a great shirt we have to uh have a link or something in here but uh wearing a single damn shirt yep and jealous advertiser buddy james here james hook it up oh oh i have to i actually want to also give a shout out for anybody that lives in the marietta atlanta-ish area so we talked about the nest and all that kind of stuff previously how i got the ecobee and all that so i ended up getting rid of the ecobee simply because i got rid of my air conditioning units so oh So you just got it. Yeah, man, it really stinks to drop that money and then really not be able to use. But I did want to give a shout out to a company that replaced my air conditioning units and actually put in thermostats that work better.

So if you live in the Atlanta area and you need some AC service or anything, this is literally just me saying that these guys did a great job it's world-class heating and cooling so look them up if you're in the atlanta area you know excellent job really happy with the work they did so very nice but they took away your eco bees but they gave me two new ones that actually work better oh so you still have eco bees but they're just new ones. No, no. So basically, without going too deep into it, I got a two-stage cooling unit. And the EcoBees in the Nest won't actually do that. And they don't do the variable speed air handling quite the same.

So the units that I've got were designed specifically for the AC units I have. So that it knows that if you kick on stage one, then it might run the cooling and it will also dehumidify the air for a longer period of time. Like there's all kinds of crazy stuff built into it. So it's actually smarter thermostats for the equipment I have is what it boils down to. Okay. So yeah. So now I've got two eco be sitting around. Anybody wants to buy buy them, just email me. I'll give them to you for a discount. Here comes the emails.

Yeah. It's the time of year. And speaking of Orlando and locations, I actually just moved to Orlando, which has been very exciting for me. So I'm not on literally a little island isolated from the rest of developing humanity so uh it's fun i've already been to lunch with like real developers it's been great so that's been nice and there's a ton of meetups too congratulations on on coming back into the world yeah and uh speaking of congratulations we've run quite a few contests

um and we've still got the airbrake contest going on so you should go sign up for that trial but um we also we had two great contests where um we had people uh mail in their dev confessions which we won't read on air because some of them were truly horrifying and we got some dev jokes which were also amazing and uh some were too horrible to tell so we'll keep those offline hey what was what was one of the ones that we really liked? It was a play on words. Oh, man. I know my favorite. The jokes? Yeah, the jokes. What was your favorite joke? I'm looking up now

to make sure I get the Well, here's one of the ones that I liked. Yeah. A software tester walks into a bar, orders a beer, orders 10 beers, orders 2.15 billion beers, orders negative one beers, orders a nothing, orders a cat, tried to leave without paying. Oh, that's so awesome. That's fantastic. Oh my gosh. You can't find it. Dog got it.

All right. So play on words. I mean mean there was another one that i really liked too uh an seo expert walks into a bar bars pub in tavern public house irish pub drink drinks beer alcohol yeah those were awesome man i can't i can't oh here i got it okay go ahead why do you call your code beta? Because it's beta than nothing. Yes, that was it. I love that one. So true.

Yeah, I love that one. So thank you, Maria. Yep. So, yeah, thank you all that took the time to write in and actually give us a joke. That was a lot of fun, and congratulations to the winners of that. And Joe, you got some more information on some more contests coming up here. Yeah.

We've got the air break thing still running. We've got some more jet brain stuff going. We've got some post-sharp licenses to give away. So stay tuned and keep watching that mailing list. We've been having, sending out a ton of stuff, so you should definitely join and get stuff and send us jokes. Yeah, totally. And join the mailing list guys go up to www.coding blocks.net. If you're on your phone, you'll probably have scroll down to the bottom of the

page for, and all it is, is your name and your email. If you don't put in a valid email, you're not going to be able to get in there. But if on the regular website, it's just over on the right, sign up, man. Like all we do is give away stuff on that. That's it. Like if we sent out anything other than that. It's honestly got to be one of the better mailing lists out there. Right. I want to get on it.

Because it's literally not a waste of your time. Every time there's an email there, it's worth your time to read it. Yeah, man. Just killer stuff to give away from awesome sponsors and people who are helping out with the show. And speaking of giveaways, we still have our winner for episode 56 to announce. So if I butcher this name, I'm sorry, but Richard Quist? Quist.

Quist? Quist. Or Kissed. Okay. One of those probably got it. If not, we're in the ballpark, but we've already sent you an email. And we look forward to sending that copy of Clean Code to you. Congratulations.

All right. So now with all that behind us. What are we here to talk about? Now we're here to talk about the next step from our adventures of how we coded things poorly to maybe doing things a little bit better. So today we want to start in on the topic of domain driven design. So Joe, have you read up on this at all? Not in the slightest. I've been busy moving to Orlando and, um, you know, play video games and stuff. So I know nothing about it. Excuses, excuses. I've been busy moving to Orlando and, um, you know, play video games and stuff.

So I know nothing about it. Excuses, excuses. I love how the video games were priority there though. There was two priorities. There was moving in video games. Yeah. I love that.

I'm actually playing rocket league as we're recording. Stop it. I need it. I'm going to install steam right now. So, uh, so I guess the first thing is we really kind of need to, this is like one of those buzzwords that you'll see thrown around. If

you're looking at encoding communities and how to do stuff, I guess first, what is the, the domain? Right. Do you want to, do you want to tackle that one? Dub, dub, dub dub or non-dub, dub, dub. It's all so complicated. I think that's where I was going to say. Yeah. Yes. Dub, dub, dub or non-dub, dub, dub. And we decided it's dub, dub, dub. It should be.

Yes. Definitely not. But the thing is, is the domain, and this is where this whole name comes from, is the domain is a particular piece of your business, right? So let's talk about in terms of an e-commerce platform, simply because most people will understand that you're going to have your accounting department, you're going to have your shipping department, you're going to have your customer service, your products, your inventory. There's different departments. Each one of those is a domain. That is where they understand how that

portion of the business works and they know the pieces of that business that need to happen. So when we're talking about domain-driven design, you're talking about approaching it from the business portion of the problem. Well, also within that, the domains as you defined in your e-commerce example there, each one of those different departments are going to have their own lingo. They're going to have their own language, the way they're going to talk about things and refer to things. And in this topic of domain-driven design, language is like the center of this whole entire concept. Everything revolves around everyone talking in the same terms.

And they actually call that something. They call it the ubiquitous language. And it seems counterintuitive to programmers because as a programmer, typically you're like, hey, what are the requirements? What I need to do? Just let me do it. Right. Domain driven design actually focuses just about more on the communication aspect of it than it does on any particular principle, because they want to make sure everybody's on the same page. Because as a developer, if you're a UI guy, you hear the word client, you might be thinking,

oh, is this an Apple iPhone? Is this a web browser? Is this Firefox? Right. And so the point of the ubiquitous language, and we're kind of jumping around, but it's so important because you want to make sure when you're talking with the business owner or the stakeholder in whatever this portion is, that you are on the same page all the time. And so it's so important that you define a set of vocabulary and everybody use that vocabulary. And the key here is if you're talking to somebody in accounting, their particular name for something

like the client may be completely different than what somebody in customer service is, right? Like accounting's client might be the third-party processing systems that they work with. Well, a better example I was thinking of is that like as a developer, you might be thinking of like, okay, there's this many users come into the system and I'm going to have a user that's going to log in with a user ID and a username. And you know, that's the user. And I'm going to like model some objects and tables and whatnot around that concept. And then you go and talk to someone in accounting and they're like, okay, so the customer comes in and you're like, oh, you mean the user? No, no, the customer, when the customer comes in, they're

going to buy these things. Wait, oh, that's, I'm calling that the user. You're calling it a customer. And that's why, you know, getting on board with that common language and common set of terms as early as possible is important. So key because then you're, you know, that means that that's going to translate into your code lining up with the domain that, that you're trying to solve. Totally. Okay. So one thing I'm kind of thinking is when I first started programming, um, I very much programmed and named my functions, named my classes, everything about what I was programming. So I would have classes like game screen or input controller, things like that. And as I kind of grew and would see how other people's code worked, I would start doing things like, no, it's not the screen.

It's the car class or it's the, you know, basically things that are closer to the actual problem I was trying to solve. And that way it was easier to talk about it, but it was also easier to think about it. It wasn't so abstract. It like really felt like I was modeling something in the real world. That's actually the key. What you just said right there is, and this is where things get interesting with domain driven design. And we'll dive into the specifics of it a little bit more later. But you might have what you were just saying. So you were talking about a user, right? You might have a user class when you're talking about somebody checking out on the site.

You might, when you start working in the domain of the accounting, you might have a customer class. They might reference the same storage thing behind the scenes, right? So your user class on one end is referencing your users table in the database. And in your accounting domain, your customer class is referencing that table. But you model your classes based off the domain, the business use, right? The business language. Yeah, so I think, but I think that the idea though, just to be clear,

that both of them will be called customer, right? Because you want to stay, you want to keep the language the same. Only within the domain. It's a customer for that domain, but it's okay that each one could be in its own bounded context and that you could have multiple instances of customer classes that are in different namespaces

that solve the specific business need for that particular namespace. So one of them might be accounting.customer and the other one could be like customerservice.customer, for example. But here's where I think that the big difference is though. If they refer to them as customer and that's truly what they call them, then yes. But if the customer service refers to them as something different, like accounting calls them a client, but customer service refers to them as something different. Like accounting calls them a client, but customer service calls them a customer. Then you should model your classes based off the language for that because then, okay, fair enough. Yeah. So that's, that's the only thing, I just wanted to tie back into the example that I was given with, you know, the, you know,

it referring to it as users and yep, totally. So all that said, said let's let's start talking a little bit why you would use domain driven design at all so like one of the first things is it it defines a set of principles and patterns that solve difficult problems and the key there is difficult you don't necessarily want to go after something simple with this because it's probably just overkill and and joe you even mentioned previously that you were excited about getting into some of these topics because you had talked about the fact that you know we've been talking about clean code and breaking down little pieces of stuff right that you want you want to expand on that a little bit yeah definitely the clean code stuff is is kind of like a microscope to code. You talk about variable names, comments, very kind of micro concepts. But what we thought was kind of interesting is that that's not the stuff that kind of keeps me banging my head against my desk.

It's always the bigger stuff, the interactions, cross-cutting concerns, how to deal with other people's code and how should things be, what's the right way to do stuff. And those are the things that I usually spend more time kind of struggling with and so i was kind of looking forward to getting into bigger topics like these and it sounds like this is exactly what i want to talk about and learn about yeah so instead of like a particular design pattern for doing a piece of code a certain way now we're talking about a design pattern for making and structuring your application as a whole right so it's you you see the same type things, right? Like you build these patterns and then that way everybody can reason about things in a particular way. And

that, that's true all the way from the 10,000 foot view all the way down into the weeds. So that, that's why this is kind of an exciting topic. Well, speaking about the weeds though, in, um, okay. So as it relates to like previous conversations we had there was one where we were talking about like you know how you might structure a table and would you break off into this other table um i don't remember the exact context of it but you know sometimes as developers we might think about like okay i'm going to have this customer object and the customer objects is going to need these attributes i'm going to need a i'm going to need a first name a last name probably going to need a shipping name, a last name, probably going to need a shipping address,

maybe a billing address. You know, I'm going to have all these needs, right? And you start immediately thinking to the ad, to the attributes that you need, but in domain driven design, you really want to start thinking about the behaviors. Like how does this, how does this customer object, how's it supposed to interact with other things? What are the needs that I need it that I, the interactions that I need from from it and once i kind of define what those are then i'll start focusing on like well what attributes am i going to need to get there what what do i need to fulfill that yep that's funny that we've talked about kind of coming from the the opposite end when starting with the database so this is definitely coming the other way around starting

with behaviors first which is something i've always struggled with doing so yeah this is this is interesting stuff which is great because next week we're going to start coming at it from the point of view of like okay you're in photoshop and you want to create a web app what do you make it look like first no just kidding yeah it it's it's definitely a different way of approaching things again with domain drivendriven design, you're really focusing on the business problem you're trying to solve more than anything. Before you even think about writing code, you want to fully understand what the problem is and what the need is. So the next reason for saying that you would want to use something like domain driven design is it allows

you to create clear and testable code that represents the domain because you're building the case for the business from that point. So it's easier to write cleaner code. Um, you have to, or you need to talk to and communicate with the domain experts, right? That is absolutely key. If not, then there's really no reason to even go down this path. You might as well just create apps the same way that we always have, where you create the database tables and go from there. Well, if you're not talking with those domain experts, then how do you know that you have a ubiquitous language that you're using? How do you know that you're building the right thing? Well, there's that, but I mean, again, since, since domain driven design is, you know, the key, the heart of it is focused on the language. How can you even know that you have the same language

to then be building anything? And then to your point, yeah, you're probably not even building the right thing. Yep. I mean, we've all seen that picture, right? Where this is what the people ask for. Like there's a swing on a tree, right? This is what they asked for. This is what we built the first time. This is what they really wanted. Project management wanted. Right. I mean, that's so true. If you're not talking directly to the people that have to work in that problem, you don't know what you're actually doing. So another thing is it allows you to, as opposed to doing the database first approach or, you know, designing something upfront, it allows you to focus on a single domain at a time. So

you get to worry about what do I need to do for this accounting department? What do I need to do for this customer service department? And you could even break it down into teams, right? To where now they can all work across those pieces at once. And this also allows you, go ahead, Joe. I was just adding some notes and had a couple of questions. So one thing I was kind of thinking about is, we talked about this being a language and domain experts, but what if this is just a one person project? What if there are,

is this not appropriate for that sort of thing? It can be, it depends on the complexity of the problem you're trying to solve. So, so we'll get into the drawbacks in a second. Let's, let's shelf that for shelf that just for a second. I guess, I guess just to expand on his question, though, are you describing where the one-person project is the one developer designing and developing something for his own purpose, or one developer developing something for one customer? Well, we know if we're doing it for our own purpose,

we need it to scale to a million different people. There's that. There is that. It's a whole other level of complexity that we won't get into. But for somebody else, we'll answer that in just a second. I guess everyone's got customers, right? Or users that you're targeting. So even if you're writing a library that you're going to put up on NPM or something, then you still have people that you want to use it. And so you need to be able to express your ideas and talk about it, whether

it's in the readme or the documentation or people on Reddit or whatever. I think what it boils down to, I mean, let's, let's go ahead and jump into it. It boils down to the complexity. So if it's just a crud type application, like literally all you're doing is updating and retrieving data from a table. And there's not that much, not that much that needs to happen to it. Like let's, let's take an application to where it's nothing more than, you know, filling out a form and then showing a list of all the people that filled out the form, right? Like maybe even a comment form. You don't need domain driven design for a comment form, right? Basically people filled out a form, it went into a database, and then you have another page that will list that data out. There's no reason to overcomplicate that thing. When you have a

system that has the complexity that you have multiple different departments or you have different stakeholders that do different processes, at that point, whether you're one person or a big team, it may be worth looking at domain-driven design because what it does is it helps you break down the concepts better, right? The different portions of the business. Does that answer the question? Yeah. And I'm also kind of thinking too, for something like if you are writing a library, like some sort of comment library, then there is kind of a, there's a domain for that, right? There, there's all sorts of stuff in that space that you've interacted with before. And while you

may be the expert, you know, if you're doing common stuff, there's forums or stack overflow, there's, you know, every website you ever used that interact with you in the same way. And so you want to use concepts and languages and stuff. You don't want to invent this whole new language for this, you know, kind of redundant task. Right. So in that sense, I guess you're playing the expert as well. Yeah, that's true. I mean, I guess like in the commenting system, like if you look at like a Stack Overflow or Reddit, it's a great example, right? Because generally speaking, they're just kind of, you know, comment forms with some reply threads, but then they built on top of it, right? Now they have all these rewards things and they have, you know, these statuses that you can achieve and all this other stuff. So when it first started off, it probably could have been a very simple thing, right?

Like I said, it's almost a CRUD type thing at that point, insert and then grab it and list it. But then when you started building on other things, these reward systems and all that, then it might make sense to break that into various different domains. Which I feel like this is a great opportunity to mention since we're talking about,

since Reddit was brought up as an example that you should probably head to reddit.com slash r slash coding blocks and uh you follow along yeah baby vote me up vote me on that points awesome um so the last reason why you should use it pretty much was you now have put your business logic in one area. Like it's easy to go reason about. It's not spread out all throughout the application. You have an accounting section and an accounting domain. Your business logic for your accounting things are in one place. And that's very nice, right? Like it makes it easier to maintain over time. Well, you got to ask though, like what about duplicate logic? Like customer service could cancel an order. A customer can cancel an order because accounting can cancel

an order. Like what about shared behaviors? So that stuff exists and that's where you get into things like bounded context. And we'll, we'll talk about that here in a little while. I don't know if we'll get into it directly today, but, but yeah. Well, yeah. I mean, you could have a, you know, shared code that could still be used between these and it doesn't, this isn't excluding that capability. Right. Yeah. So in the case of what you're talking about is you could create a shared library that is, you know, refund, right? You're refunding an order. Customer service can leverage that.

Accounting can leverage that. And you want that functionality to exist in one place. However, the access to that might be limited by the domain you're in, you know. So both have the ability to leverage shared code at that point. Okay. Yeah, I'm digging this this kind of reminds me a little bit we talked about with design patterns about how we're just having a common language and um these kind of abstractions for talking about things making easier when you know if i say a factory i don't have to spend 10 minutes explaining how this thing works because

you know we both have kind of agreed on the concept of what a factory is and what it does and what it means and so we can skip past that and talk about things in a more powerful and more expressive way and so it sounds like uh yeah this is a pretty smart way of doing things yep excellent hey maybe maybe each one of us like from now on all episodes two of us read one of us doesn't and then that way we can ask and fill in blanks like that like can i be the not reader? No, it's my turn next go around. So the drawbacks, you need access to the domain experts. Like we said a little while ago, if you don't have access to them,

why are you even writing the thing in the first place? But that's one piece of it. The second is, we've said this before, nothing comes free in programming. There's additional time and effort required to do this. If you're just given a problem and you just start programming, you can put rubber to the road real fast, right? Are you going to do it the most effective way?

Are you going to necessarily do it the absolute best way? Maybe not. But with domain-driven design, you spend a lot of time up front just understanding the business needs and defining the language. Yeah, I was going to say, that spend a lot of time upfront, just understanding the business needs and defining the language. Yeah. That's the, that's a big part of it. And then not only during the upfront of just making sure you understand the problem and that you can talk through the problem and that you can agree on what terms, what things mean. Like if you hear, uh, you know, that, that customer that you're talking to, you know, be it someone from

accounting or be it someone from customer service, and you hear them start to use some terms, ask what those mean and define what those mean and how they expect the interactions to be. But then as you actually start to develop, maybe you realize like, oh, hey, you know what? They kept saying something. And at the time, I thought that this is what it meant. But maybe I need to go back and ask. Or maybe I didn't even realize it was a big deal. But now I'm starting to see, I think this is a bigger deal.

Maybe I should go back to them, right? So there's that iteration of going back to them and having those conversations. Yep. You have a weird look. I was just thinking, this sounds pretty anti-agile so i did a quick google here and i found um stack overflow uh i'll have a link to the show notes um someone specifically says not to do this but i kind of want to do it anyway so i want to mention it uh but this person recommends not trying to waterfall your model and then agile your code but i think that's in a way

that's kind of what we're talking about a little bit like you want to spend some time up front kind of planning your domains and drawing some lines and figuring out kind of a blueprint and then kind of iterating on that you know so it's just kind of funny to say see that he's saying specifically not to do that um it's interesting Immediately what I jumped to is like, Oh, this seems like a good idea. But, but hold on a second though. Waterfall is usually like literally writing out all the design docs and everything, right? Like when we talk about the waterfall, this isn't, this is literally just defining your business cases and needs and behaviors, right? Like that. I feel like this is slightly different than doing

something like waterfall. The agile is your way of getting there, right? Like when you talk about agile and sprints and all that, it's, it's all right, sprint to get the first piece done or the first piece is done and then sprint to get the next piece is done, right? Where waterfall is just a very long drawn out process. I feel like they address two different things in this case. But when I think about waterfall though, I'm thinking about like, it's all about a project plan. You're saying like, Hey, by this date, we're going to do X, Y, and Z. And we're going to set this milestone that we'll have this done. And then we'll build upon whatever we did there. Like it's all about the project planning and we're not talking about

project planning. Right. So I don't feel like that, that, uh, fits in here. We're, we're not talking about project planning. Right. So I don't feel like that, that, uh, fits in here. We're, we're just talking about like communicating with the customer, making sure that you understand what their need is and understanding their vocabulary. And when they say, when they use certain terms, uh,

what does that mean? Uh, you know, to whatever the problem is, it's trying to be solved. Yep. That's kind of, that's funny.

Like, as soon as i hear the words up front i'm just conditioned to say waterfall and then you know exit the room like you know we're done talking here that's a yeah it's a really uh immature way to do things and i don't know of many businesses that uh are fully on board with agile like almost everybody's got some sort of milestones or something i mean that's a whole nother conversation we should have a big like agile throw down one of these days. But yeah, just kind of was funny. That actually brought up something.

I was listening to a podcast the other day and I can't remember which one it was. But there was a guy that he works for O'Reilly. He's one of the big architect guys. And the question of agile came up and he said, you know, the problem with it is the whole notion of agile is up and he said, you know, the problem with it is you're the whole notion of agile is sprinting, right? It's, it's just like, if you're out sprinting, instead of taking a slow jog or something, you're trying to run to get to the next small milestone. And then your next sprint comes up and you're running as fast as you can to that one. He said, the problem with that is

if you're constantly sprinting, you're never taking time to go back and address the things that needed to be addressed. So your technical debt stacks up and that kind of thing. And he said, you know, there, there needs to be a happy, a happy medium somewhere on that. You know, it can't always be just pushing forward, pushing forward, pushing forward. You need to sometimes, you know, take the time to clean up your house a little bit. So I found that interesting anyways. All right. So, so the time thing up front that the big problem there is you really have to have the time to think about those business problems and spend the time with that and how it's going to interact with other portions of your app, right? Like you can't just start putting code down because you might really paint yourself into a corner.

Another drawback is there's a learning curve as with anything that you do, right? There's always going to be that time where you're having to ramp up and learn how to approach things properly. So that's inevitable. You're going to spend time learning just the process of doing this. And as we said earlier, you're like, Hey, why don't you, would you do this? If you're a single person? Not if it was a crud app. If it's something stupid simple, don't waste your time. Unless you're just trying to learn how to do this. But if you're doing it for a project or a customer, you know.

I mean, Eric Evans might argue. Maybe, maybe. Eric Evans is the author of the book Domain Driven Design. Yep. Yeah, I was just thinking we'll have a couple of resources at the bottom, the resources we like on the blog post, and we'll have a link to that book as well as some videos and some other stuff that we like.

Yep, totally. And then here's the other one, and this is always the hardest thing, right, is getting buy-in from the people up above you. If you have upper management and they're like, no, I want code done today, you've got to get buy-in to say, no, we need to define this, right? Like we need to have bigger problems then though. Like they're not even going to let you give you time to understand the problem.

Man, there's been a lot of places we've all worked at where, you know, it's like, no, we need this done. We need it done now. And, and the speed at which it's completed is more important than the finished product at the end, which is sad, but it's a reality sometimes. Right? Agreed? Disagreed? Maybe I'm missing something there. Can I sadly agree?

What if I don't want to agree happily? I don't want to do it with a smile on my face. You can totally do that. Yeah. And Joe's got the link to the anti-agile up there which is amazing so that'll be in the show notes as well i like to sew dissent wherever i go that's garbage he says dissatisfaction chaos well let me just say this though. If you haven't already left us a review, we would greatly, greatly appreciate it.

You can head to www.codingblocks.net slash review and find links there to some of the podcast popular aggregators out there. And if you have already left us a review, we super duper can't say it enough how much we appreciate it. It totally puts a smile on our face when we read those. We're big fans of you for taking the time to write those. Yep. And if you want to try and slip in a name that, you know,

we might accidentally read it on the show, that's a great place to do it. And it's humorous. It's happened. It's awesome. There's been names that we didn't think we should say that turned out to actually be their name. Yeah. That's happened. It's awesome. There have been names that we didn't think we should say that turned out to actually be their name. Yeah, that has happened. So they have some awkward conversations.

Oh, boy. And we've highlighted it several times. Yes. We're good like that. All right. So let's just take a moment here to uh to get into like one of my favorite portions of the show survey says all right so last time we asked how fast is your personal internet connection now i'm hoping you guys didn't cheat. No, man. I actually forgot we had a podcast because it's been a while.

Oh, yeah. Well, you know. Sorry. You know, like Joe moves. I got sick. Yeah, things happen, man. Dude, it's all of us. So your choices were less than five megabits because DSL is amazing.

I love some DSL. Or less than 25, less than 50, or I should say less than or equal to 25, less than or equal to 50, less than or equal to 75, 100, or greater than 100. Or you're just like, what are you guys talking about? I'm on fiber.

One gigabit. Yeah. What do you guys think? Pick what you think was the most popular answer. It's my turn to go first this time, right? I don't remember. All right, I'm going first.

Yeah, we could ask I could ask Siri to flip a coin for me. All right, so I'm going to say it probably won't end well. Oh, you want to listen to flip a coin? I can't find flip a coin in your library. Thanks. So I'm going to say, yeah, it probably won't end well. Oh, you want to listen to flip a coin? I can't find flip a coin in your library. Thanks. So I'm going to say less than five.

Really? Yeah, I really do think so. Okay. What's your percentage? 30%. Dang. 30%. Okay. Yeah. All right. Okay. 30 percent. Okay.

Alright. Well, I think less than 50 with 30 percent. Less than or equal to 50 with 30 percent. So both of you are claiming a third. Alright. Well, we're playing by Price is Right rules. Yes, yes. I lose

these a lot by like a dollar yeah and this is and today is no different dog gone is it 29 so are you kidding me that's ridiculous oh so surprisingly less than five megabits per second was the most popular choice dear listener what are you doing like i hope for your sake that is seriously your only option move that's what i actually get my desktop for some reason whether it's wireless or plugged in it just never gets over 10 i think i need to get a new computer or something yeah you got man. 10 base T will limit you. Yeah, I was going to say. Well, my laptop right next to it is fine, and it doesn't matter if I plug in,

so it's got to be the motherboard or something's crazy. No, no. The updated driver is like, it's just weird. Your network card, do you have a gigabit or do you have 10? You might have 10 base T in it. No one has had a 10 base T Ethernet connection since the 90s, man. Come on. Hey, maybe he was using parts from his old computer

his really old computer five years he's got like the first ethernet card made by 3com so wait what was the percentage did I literally miss it by one again so no not by one but it was less than five

at 24% of the vote. Wow. So a quarter of the people, yeah. Yeah, I was really surprised. I did not think that it would hit that low. I actually expected that by today's standards, I expected that that was going to be one of the smaller ones, so I was really shocked to see that it won out.

So I'm curious, what was second? I would think that less than 25 was second place joe would you like to weigh in on this uh i think uh i'm gonna go less than 50 with 30 at least he's consistent. I play to play, not to win. In that case, Joe wins. Yeah, no. The second and third place were close.

Less than or equal to 50 was second place at 19%. Okay. So not too far away, but it was a tie for third between less than or equal to 25 versus greater than a hundred wow so two ends of the spectrum and they're tied at 17 of the vote that's really crazy so there there's you know combined there's you know a third of the vote right there on two ends of the spectrum. That's crazy. That's fun though. I, I, I don't know why I just guessed that there are plenty enough places where they just haven't updated the infrastructure well enough. And you got to remember too, like if the tell, if the telco companies are the only ones that were in cities

at a given time, like they fight like crazy to make sure that no competition comes in. So that's kind of why I took that route. Well, I'm really curious. I would really be curious to know if the less than or five, uh, you know, if that's us based votes or outside of the U S um, I mean, I am kind of picturing us, which is kind of what your comment led me to think you were thinking as well. You hear about other countries out there that have insane rates, but they're also much smaller than a country the size of...

Their city is their country. They're not trying to cover the land mass of, say, in Australia. Right. Right. Right. Yeah.

So that takes us to our new survey for this episode. And I have to clarify here so that Alan won't try to interject a language that doesn't count. But which programming language are you most envious of? Man, I should have kept my comment to myself earlier. Yeah, I couldn't just say which language are you most envious of. I have to clarify that and say which programming language are you most envious of? French.

Le C? Oui. Le C. okay so your choices are c c sharp c plus plus f sharp go haskell java javascript python r Python, R, Ruby, Swift, TypeScript, and lastly, the ever popular VB.net. Yeah, baby. So which programming language are you most envious of? Which one do you look at the code from and you're like,

oh, I wish that I was that person doing that thing. Yeah, like maybe you spend all your day in C Sharp and you see some Python and you're like, Oh God, that looks so, I wish I was a Python developer.

I wish I got to work in Python all day long. Adulterous coders. You know, you see some JavaScript, you're like, Oh, if only, if only I could do some JavaScript to my job.

Well, I mean, we've definitely talked about as it relates relates to JavaScript, though, about framework envy, though, right? About how you spend your day in one particular framework, and then you see something like a React framework, and you're like, oh, man, that looks, I want to work in that. None of us have that envy. Yeah, I think everyone, really, JavaScript is nothing but envy. Yeah, I think everyone really JavaScript is nothing but envy.

It's so beautiful. JavaScript is envy of framework and fatigue of framework. That's all it is. Man, I totally want to work in that one that hasn't frustrated me yet. Right, exactly.

And then by the time you get the build environment up and everything, you're like, oh, I'm over this. Yeah, totally. Let's try the next one. Let's set up another build environment. Yeah, man. Yeah, so I'm curious to see how that survey is going to go. Coolness.

All right, so jumping back in, we already kind of covered all this part right here. So the ubiquitous language we talked about, it's like one of the most important parts. We can kind of just skip over this section now because we pretty much knocked it out early. So let's jump into some of the details of this thing now. So really what I want to do is I just want to throw out some of the vocabulary around domain-driven design. And we're not going to go too deep on this particular episode. We'll talk in an upcoming episode about some of these things more in depth. But one of the important pieces of this is called the bounded context.

And this is where things like what Joe was talking about earlier come into play, where what if two different domains need about earlier come into play where, you know, what if, what if two different domains need to do the same type thing, like issue a refund or something. So the way that it was put by Eric Evans in his book is explicitly the bounded context explicitly defines the context, which in which within a model applies, keep the model strictly consistent within these bounds, but don't be distracted or confused by issues outside. So really what you're saying is you want to make sure that you're doing what needs to happen within that particular domain and not worry about what things outside that domain need to do. Again, it's the behavior driven

thing that you mentioned earlier. Like that's the key part of this. And you're drawing these lines, you're drawing these explicit lines saying, this is what this particular domain does. This is the context for this domain. Any, any questions on that one? Makes sense. Good. No, I mean, I'm good with that. I mean, we kind of covered it before when we were talking about like the accounting customer object versus, you know, like what we were referring to the username example. Yep. So one of the next terms is the problem domain. This one's fairly straightforward.

This is the specific problem you're trying to work on and solve. Your core domain. These are the key pieces of your customer's business that you can't outsource. These are the things that you have to focus on that you have to develop. The subdomain. These are different pieces of software that you may interact with. Might be your own stuff, might be with a different department, but these are things that you don't necessarily have to focus on necessarily for your domain. Context mapping. This is where you're identifying the bounded context and how the relationships work together. So that refund example that you said earlier, right?

If you have something that does that, your accounting department may need to use that and your customer service department may both need to use that piece of functionality. So this is where you're mapping those together. So am I going to be using these specific terms with the domain experts? Like I'm going to say, all right, guys, Hey, Tuesday is shared kernel day. You could popcorn for everyone. No, I, no, I don't believe you would. These are going to be within your,

your technical or engineering department I believe is the way that this would work. Okay, how about this? So if I were, say, starting a new web consulting business, right, and I'm talking with my first customer, I say, hey, come down to the office. We're going to whiteboard some things. Then this would provide like a good model for how to work with them, right? Like we would start defining the problem, then look at the core business processes, break it down into subdomains, then start context mapping, whatever that means, and then shared kerneling, and then start coding.

Yeah, pretty much. So really you'd be defining the business problem with them, and then you'd be breaking down these things a little bit further within your engineering department using these terms. I always like to start with asking the customer, can you tell me what anemic domain models you need? Yeah. And I can start from there. Oh, man. Yeah. I was just thinking like a customer calls and you're like, what the heck? We just, you know, a thousand dollars just disappeared and just not

adding up. What is going on? I don't want to say, well, the MySQL driver treats floats as, I want to say, well, the order processor had a problem calculating tax. Yes, and that's actually one of the biggest problems for developers, right? Is being able to come up out of the technical and speak at the business, right? At the problem as opposed to the technical implementation you know, implementation of it because business people don't care about it. They don't know anything about it and they really do not care about it. Right. My customer just got charged $50 too much. I don't care that there's a credit card processor that got hit with double authorization fee. Like nobody, they don't know about that stuff. They don't care. Nobody even knows how credit cards work. Here's an even better one, though. This is something

that we've kind of talked about since you're talking about financial kind of situations with tax and things like that. But like, hey, there's this rounding error. Why did this round up when I expected it to round down? Oh, you see the Microsoft framework that we're using that uses bankers

rounding, and so it rounds up when you expected it shouldn't have you know or rounds down when you think that it shouldn't have I'm sorry I got that backwards spoon rakers the one who brought that thing up right if I remember right and he's the one that'll kick your tail in Rocket League just in case anybody wants to go on there and do that on one of our

game nights but challenge accepted yes oh yeah he's he's freaking amazing I've like compared to me everyone is kind of amazing he's extra extra amazing but yeah i really do like that i mean like it's anything too i think it's a good lesson to kind of take away that you want to talk to your customers like your customers expect right so you want to be the one to reach out and you know kind of try more to meet them than expecting them to come to you. Like, you know, you don't want to say, well, sorry, uh, react sucks. And that's why this

dropdown doesn't look right. You know, you want to say, I'm sorry, there's a usability problem. And, uh, you know, it's a fundamental problem with underlying technology and we're working on a workaround. Right. Hey, uh, by the way, you said, whatever the context mapping things is. So, uh, to paint a picture here, it's kind of like a Venn diagram. So you have your accounting department, you have your customer service department, and then there's things that they control within those, right? But then things like order refunds are places where they overlap. So if you think about these two Venn diagrams kind of meeting and they overlap on these

order refunds. That's what you're talking about with your context mapping so that you can see, Hey, what parts of the system are actually used by different domains, right? So that's where, that's where that comes into play. Okay. So we're talking about like John's pictures, maybe some arrows, some boxes. Yeah, totally.

Like a lot of this stuff really is just taking notes, right? And sketching it down and seeing how, where the arrows connect. Like that's what a lot of this stuff is. When you're talking about domain-driven design, it's literally the design of the system from a business perspective. Wait, I got to take notes?

I'm out. You could do it on a Surface Pro, right? Like if you have a digital pen it works okay fine I kind of want to start my own business now I want to buy this book I want to extract all the interesting stuff out of it and then like you know put a couple slides

around it and like dump stuff like in you know like at this stage give them a worksheet have them fill it out or you know give them what you call it um what what do you call it oh my gosh uh not keyframes when you have little box diagrams and stuff like uh wireframes wireframes yeah like this is the wireframe stage like and then we had to sell a course for uh starting your own boutique website uh company don't forget the ever important

forum about like having them fill out all the anemic domain models that they want. They know what those are. Yes. And some Mad Libs for fun. And then, so the last one that we had here was the shared kernel that he brought up and that's not sharing popcorn. So part of the model that is shared by more than one team. So this one's kind of important because different from just the behavior, if different teams are sharing your customer model, the importance of this is multiple domains get to use it, but you can't just willy nilly change it, right? Like if you're the only user of a customer domain, then it's kind of up to you. You can go change that thing however you need. But as soon as it

starts getting shared between multiple domains, there needs to be an agreement on we're updating this thing because now that impacts more than one place, right? So that's when you talk about shared kernel, that's like your shared, like your common stuff that happens. It might even be logins or anything like that, right? Yeah, I've definitely heard of problems with that where you hear something like, well, accounting switched over to the white planes package and didn't talk to Coastal Service now because the service can't process any refunds

and it's a big fire. Yes. Good job. You know, and I'm sure that there's somebody out there, like, let's focus in on this customer idea. You know, there's probably someone out there that's listening and thinking like, why on earth would I want the same class name in these different name spaces why wouldn't i just want the one

that does everything but you know like one of your possible use cases of all the many might just be that from a um what would the term eludes me right now, not from a security point of view, but from like an information leakage kind of point of view, you might not want information about that customer available to everyone in the company, right? Like, you know, customer service, they might need to see a larger set of information than say those in the shipping department. Right. And so you only want to have those attributes that are available or specific to them. And if you have these different namespaces with each customer object that represents what it needs, then you're already kind of protecting yourself against that

type of leakage right from the get-go, right? And to even take it a step further, right? Like if customer information is a great one because a customer service app, if done right. And, and, and I'll say this fairly confidently to, to keep from phishing attacks and things like that. You don't necessarily want somebody to just be able to type in Michael outlaw and then go see all your information, right? Typically the way it works. And if you've ever had to call into a customer support line, they'll be like, Hey, could you tell me what your address is? Or give me some random piece of information that's associated with your account. So they can't even open it up until they've gotten various different pieces, right? Now to take it a step further, you might not want

somebody in, in shipping or shipping is probably a bad one. You probably don't want somebody who's working in merchandising, right? You don't necessarily want somebody in merchandising to be able to change your customer account information. They may, they may need to be able to see some of it for some weird reason, right? Like this customer ordered X number of these. So let's try and market something to him, but they shouldn't be able to change your account. Somebody in customer service should be able to go in and update your address or maybe your password because it's, you know, something's happened. They should be able to reset it. But that's where even, even taking a little bit further is not everybody should have access to the same features, right? You, that customer object

may be able to do all kinds of crazy things, but you really need to draw the lines between what can this particular domain do with it? Because now it's almost like the whole point, if we go back to what we talked about earlier with the, you know, we've been looking at everything through a microscope. The whole reason you don't declare global variables is you can't, you can't guarantee how that thing's going to be interacted with, right? That's almost the same type thing. Except now we're more at a macro level. We're saying, Hey, limit this thing down, only allow it to do what it's supposed to do. Even though that particular object can do so much more, you only have access to these pieces of it. Yeah. So by focusing on the behaviors,

going back to the shipping example, like focusing on the behaviors of what the shipping department needs right you're already solving some problems that you're not even trying to like but you're just getting them kind of for free right you know like this uh there's a better term for it but you know that information leakage as i referred to it yeah it reminds me of what we talked about too with the integration or the the interface separation policy um segregation policy where you basically want to pass in the the minimum amount of information keep it simple um and you think about it like if you imagine like the say the ups driver comes picks up boxes from some sort of fulfillment center and goes ship it and they realize that it's not just the name and dress on this big box it also shows the contents and maybe the person's credit card number and,

you know, maybe their order history. And like, that's crazy. You would never do that, but that's the kind of information and stuff that you're passing around. If you're passing around these big, complicated objects and that just doesn't make sense for,

um, or a lot of policies. And as your company grows and it's like, say you're like an Amazon or a Walmart or something like these individual systems, um, that are interacting are all huge. And sometimes it passes to like, you know, a lot of people's hands. So you want to be really careful

with that kind of information. So you don't want the UPS driver knowing what size gloves President Trump is ordering, you know, for example. And there was another term that Alan, you used a lot when we were going through the clean code series. And that was like reason about right, like you would say like, hey, if you if you organize your code this way, if you break your code down apart into this and you keep these things small like this, it allows you to reason about better through what it is. Right. And so if you take this now, if you evolve that and continue that on into the domain driven design, right now you can reason about what are the shipping needs? What are the accounting needs, right? And you can reason about those behaviors independent of the other, right? You can only

focus on shipping when you're dealing with shipping and only focus on accounting as you're dealing with accounting. And everything is concise right there. And you know the beauty about it, if we take it even to a further level and we talk about some of what you see is, we've talked about it with just credit card processing things in the past. What you'll typically end up seeing is, if this, then do this. If this, then do this. When you break your things out into domains like this, you no longer have all that switch logic in your classes. You now have that broken out because you know that you're dealing with accounting now. And you know that accounting is doing this behavior.

And if you're in customer service, it's doing this behavior. It's not, hey, if you're logged in from accounting or from an accounting role, do this. If you're logged in from a customer service role, do this. So it actually, and this goes back to the whole making your code more testable, you have very, they're almost simplified,

you know, programming logic behind the scenes now. And so it's easier to break that stuff out and look at it in a reasonable manner. So it's, by the way, this is not a small topic. No, it is not. I mean, the book alone is gigantic. It's what is it? Is it another 600 page book? Yeah, it's huge. And we're actually thinking about buying it for each of us just so that we can, you know, go through this stuff. And, and maybe we've even talked about doing some live coding. Maybe it'll be something to where the three of us get on a YouTube video and just start doing something, right?

Like maybe we'll come up with a business problem and try and do this, but. Oh, I'm so close. It's 560 pages. Yeah, that's not a small book. And there's hours of information out there. So yeah, that's the thing already. So there's already like a wealth of information about it, which is the only reason why it's been like it. Cause it's not an cheap book either.

No, it's not. I mean, I guess clean code wasn't cheap either. I mean, it's 30, but this one's 50 bucks. Right. And I think it's original price is like up in 70 something. So yeah, like 75. That's why we're not giving them away this episode. So what? That's why we're not giving them away. We're not giving these away yet. Cause if we get them, we're going to need to go through them a little bit, man. I think we got enough giveaways going on. Have you joined the mailing list yet? I did it five times during the show already. I just want to increase my odds. That's awesome. So, I mean, I guess I'm hoping now if we compare this just real quick to what we talked about in the last episode, like the last episode, you get a list of things that you needed to get done.

And typically what you do is you'd set up your tables and then all of a sudden you'd have classes that would interact with those tables that were kind of DTOs. And now you've got this spread of stuff that could just be accessed anywhere. Right. And then in that, in that spread of code, you've got all these, if else's switch cases, you know, maybe you created some sort of, you know, hierarchical OO structure to where, you know, you had an accounting class and you had, you had some other customer service class, but things still kind of end up jumbling and being, they have access to too much. And that's what this tries to solve. This tries to solve the complex business problems by doing it in a way that you

can look at and it makes sense from both the programmer as well as the business, right? Because you can look at it and you say, oh, you need to refund an order for your customer. And then if you go look at your code, you have your customer and you have a refund behavior in there, right? So it allows you to tie the two together. And I think that's why this one's so important. Well, as we get deeper into this in coming episodes will break apart specifically where those behaviors are going to be though totally because according to uh the domain driven design whatever we want to call fundamentals you know there are specific objects for certain tasks right yeah we are only scratching the surface of this right now and in this episode episode, yeah, in this episode, and we've been talking for what, like a, an hour already. So the, all we're doing is laying down

the groundwork right now. The, the details do get, get a little bit involved. Yeah. So with that, let's go ahead and say, there are some resources that we're going to include as resources we liked related to this episode. So number one on that list, there's a Pluralsight course covering the domain-driven design fundamentals by Steve Smith and Julie Lerman. We've mentioned her many times on this show. So we'll include a link to that. It's not a short one, I will warn you, but it is a good one. High quality. Yeah. High quality stuff. And just a little preface, if you are thinking about doing that one in particular, they actually take a business problem and walk through solving it using domain-driven design,

like literally as if this was being presented and they talked through it all. It's, it's excellent stuff. Including like actually hearing them go back and forth and iterating on the development with the customer and having those conversations to clarify parts. Yeah. Like you said earlier, like you confuse something and you have to go back and be like, Hey, wait, what did we mean here? Right. I mean, there was a excellent, excellent, um, video course on this one. Uh, the next one we have is, this is one

that I started watching and it's got a mixture of both domain driven design as well as CQRS and a few other things. It's called modern software architecture, domain models, CQRS and event sourcing by Dino Esposito this one's excellent i i really liked it he covers so much ground in this one like it's literally drinking through a fire hose and he throws out a ton of different uh approaches to things whether or not you want to do things in the same database do things in separate databases like it's it's all over the place so another excellent one but i think that the fundamentals one is probably a better place to start obviously we're going to include a link to the book uh

by eric evans yep and then a couple of a couple of ones that were actually listed in julie larriman and steve smith's course were dddcommunity.org and domainlanguage.com, ones that they recommended. So if you have questions or you want to get up on a forum or look at a blog, these are two good ones to go check out as well. So all these links will be in the show notes, so definitely go up there, check it out. It'll be codingblocks.net slash episode 58 and it's fair to say too that the domainlanguage.com that is the quote official that's eric evans site yep and he is the uh the owner creator of this so there's excellent information up there and with that we get to get into alan's favorite portion of the show it's the tip of the week awesome and uh as always uh we gotta mess things up a little bit and so i've got two

and it looks like we've we've all got weird stuff going on um so without further ado uh first one i wanted to mention was voicecode.io which is uh looks like a plugin for dragon uh and i'm not sure if you guys are familiar with dragon but it's basically um like speech speech recognition software that's really popular and it's used for a bunch of different stuff including accessibility anyway um there's some really cool videos on the website where someone's actually codes through a music generator like a really good one in ruby uh using the software i thought that was really cool especially someone who's had uh two two carpal tunnel surgeries i thought that was really interesting uh to see people to be able to do that stuff without having to type

very nice and yeah wait wait you're saying you just dictate okay yep in the video i watched like i did a ruby and uh made a really cool music generator there's all sorts of technical terms like even like sine waves and stuff and uh it just kind of like sat there and talked it out and it just did it it worked and there's you know all the weird syntax and stuff with coding so i just always assumed that was you know near impossible but it worked really well. That's cool. And I did have... Oh, go ahead. No, I'm curious. What language did you try it out with?

No, I didn't try it out. It requires a Dragon software, which looks like it starts at $60 but goes up from there. I see. Right. Man, that sounds pretty neat. Yeah, it's really cool. The video's really cool. We should just all write our code that way.

Yes. Yeah. People around you would not cool. The video's really cool. We should just all write our code that way. Yes. Yeah. People around you would not get annoyed in an office at all. Void, annoying function name, open paren, close paren, curly brace. Especially like yelling over the keyboard like, it's a terrible name. And then, you know, that getting transcribed into the... Slash, slash, I know it's a terrible name. That's why I getting transcribed into the uh slash slash i know it's

a terrible name that's why i named it that way right exactly the uh the other one i wanted to mention was something i really uh i recently stumbled upon which is a site called surge.sh like as in the shell but it's actually a website um surge.sh and um what I did with this is, um, is NPM package for, I think it's just surge.sh. I'm sorry, just surge. And, um, after you install that package, you can just type surge. And if you haven't registered account, you can actually do it. Uh, you can do the full registration via command line. They'll say, all right, what's your username? What's your password, confirm password done. And then you can type surge in and it will actually publish a static site on a subdomain i'm not sure how long they keep it around for but it's totally free so like if

you're just messing with a little website which is what i was doing and i was trying to figure out like the just the easiest way to kind of host that and i was trying to think maybe there's some way to get up on github pages or whatever just because i want to be able to kind of host that and I was trying to think maybe there's some way to get up on github pages or whatever just because I want to be able to kind of show someone what I'm working on I found this thing and it was basically like okay type surge and it'll give you a generated um url so I think I had like striped llama or something a striped llama dot surge.sh and it just publishes whatever director you want up there and it's just static site hosting so I was able to take that subdomain and you know it's meant to be like a temporary kind of thing you know you don't want to um yeah i don't know how long they keep it around for but it's just cool to think like i could send that link out to somebody

you know stripedzebra.com or whatever uh and they can look at what i'm working on and it's just really cool and free dude you can also do it to your own domain because you can add a c name this is really neat. Yep, there you go. Yeah, deploy anything in six keystrokes. That's very cool. I don't know how you find these random things. That's amazing.

Google. Yeah, right. Well, Google and Slack. Oh, yeah, our Slack channel is amazing. Oh, speaking of, there was a correction also to something else. So Nate the DBA did the one on the debugging. Somebody else, and I can't remember who it is now, and I apologize because it's been a few weeks ago when they mentioned it,

but when we were talking about SSDs in the previous episode, and we say gigabits, it's gigabytes per second. So it's a factor of eight more you know faster than what we had said so when you're talking about uh the samsung evo 960s or the 960 pros and we were talking about like three plus gigabits is what we had said it's gigabytes so to whomever i forgot the avatar or the name and slack i apologize but it was actually an email. It was actually, no, it wasn't even an email.

It was, um, was it a comment? It was a comment on the page. Okay. That's beautiful. So we might actually be able to reference that. All right.

So while he's finding that I will give you my tip of the week and because I did the talk on it and I had to follow up somebody amazing, uh, as your function apps. Amazing. So it's the whole serverless architecture thing. I should have come up with a better name for it, but if you haven't looked into it, if you need some sort of process and you have something that you need to do, but you don't have a server to put it on, look at doing it in Azure it's or, or even AWS Lambda. Google also has their own compute one. So it's kind of

interesting. I don't want to go too deep into it. But the one really cool thing about Azure functions is they support a just a whole slew of different languages. Amazon's AWS Lambda support a smaller subset of it and Google only supports JavaScript with Node.js. So I found that interesting. But if you have just like one-off tasks that you need to run, either be it on a schedule or if it's something that you need to, when you call this thing, you need it to kick off and run some sort of process. This could be a very inexpensive way for you to do things and not have to worry about the infrastructure around it, right? You could call this thing, run some code, and you're done. So definitely, if you don't know about them, go check them out.

I'll try and get some links up here so you can go look at it. But very cool stuff to know about. And the user that sent in the correction was Kogli. Kogli. Nice. Well, thank you, Kogli. Kogli. Nice. Well, thank you, Kogli, and thank you for correcting us on that. Totally, totally messed that one up last score.

So in the last episode's tip of the week, I gave the regx101.com, and Matthew Watkins wrote in, and he was like, oh, hey, there's this even better one that he thought I was referencing, refiddle.com, which I was like, wow, I hadn't heard of that one. Let me go check that out. Oh, my God, that one's cool, too. So here's another RegEx fiddle site for you to play with, refiddle.com, But the one that he was saying was better than refiddle

was reg XR.com. So, uh, reg XR.com, which was kind of similar to the reg X one Oh one. Um, but yeah. So whichever one's your favorite man, like any one of these things for reg X, you could go in and, uh, you know, you get some syntax highlighting within the reg X actual, you know, uh, you know, structure, and then you can actually see what it's going to match on and you get some, uh, descriptions of it. And then you could save these, share these. I mean, so we live in an awesome world right now. We do. Oh, and RegExer is not ER at the end. It's just RegExR. Right.

Yeah. So if you're listening and driving when you get where you're going, yeah, it is so cool. It really is. We live in an awesome world. We do. So that's mine. And so thank you, Matthew, for taking the time to write in

and share that with us. Yep. Indeed. Yeah, you're going gonna wrap it up for us so yeah so you're gonna summarize this and let us know if we failed at what we were trying to do you guys listen to reply all they do the yes yes no yes yes yes yeah so let's see if i can explain it back i'm playing that alex goldman uh so uh tonight we gave an introduction to the domain design wait what does dd say unbelievable 3d baby 3d domain driven design we gave an introduction to dungeons and dragons dude much more familiar with that and basically we talked about defining and coding around a ubiquitous

language, which helps facilitate communication with domain experts. We gave a couple of tips for things to do and not to do. We talked about a couple of different terms or levels for how to kind of break problems down into different phases. And I think we're going to be talking about this some more. Awesome. Yep. So with that, subscribe to us on about this some more. Awesome. Yep.

So with that, subscribe to us on iTunes, Stitcher and more using your favorite podcast app and be sure to give us a review by visiting www.codingblocks.net slash review. And while you're up there, go ahead and check out our show notes, our examples and more. And send your feedback,

questions or rants to the Slack channel, codingblocks.slack.com, and follow us on Twitter at CodingBlocks, or go to CodingBlocks.net, and you can find our YouTube and Pinterest pages and all that stuff. And make sure you sign up for the mailing list, because we're trying to give away free stuff. We want you to have it.

We want you to have all the tools at your disposal, so definitely go up there and sign up for the mailing list. You think Microsoft would give us an Xbox giveaway if you ask? We talk in their MVP? You know what? I'll ask somebody. As a matter of fact, it's not completely

crazy, right? No, it's not. I don't think it's out of the realm of possibility. So check it out. Also at the beginning of May there is an MVP. I don't know. It's a meetup, but they're having like a community thing here in the Atlanta area. So if you're coming to that, please come holler at me. I'd love to meet you.

We should host a party, or when I say we, I mean, you should host a Coding Blocks pre-party and take everybody out and get them Atlanta food. I know somebody who did that. Yeah, Mike could do that. Yeah. That means I got to organize something. I can't even organize myself, man. My wife doesn't like that.

Hey, what are we doing tomorrow? I don't know. Yeah. Anyways, all right, guys. I will see if I can get us an Xbox alright that's it episode 58 in the books we'll see you in three months

commit it yes that means no more wasted time searching log files and more time writing and stripping great code airbrakesupports.net and all major programming languages oh shit and more time writing and stripping great code. Airbrakesupports.net and all major programming languages. Oh, I didn't see that.

I'm sorry. I didn't realize it was all three of us. I'm sorry. Because we didn't go over that part before. So I'm telling you I'm not bad at it. Yeah, I forgot. I didn't tell you about it. Because he said it was shrimping great code.

So it's probably best that we redo this anyways. You got to shurp it. All right, we'll give it another shot. You got to shurp it. Let's do it was shrimping. Shrimping is a great code. It's probably best that we redo this anyways. You got to shurp it. You got to shurp it. Let's do it from the top. It wasn't that bad. Especially when I only have like 10 words. Here, let me fix that real quick. But our newest sponsor, Airbrake.

I thought that came out rather well. Except for, except for, you know, the chirping and the, the urban. I find it. I find it humorous. They're the things that like we each,

like there's definitely the things that I'm like conscious about. I'm like, Oh God, no, no, no, I don't want to do that. And then like when somebody else,

like you got, when I hear one of you guys have something that you're conscious about, I'm like, Oh, thank God. I'm not the only one. Yeah. Oh yes.