1 00:00:01,080 --> 00:00:03,000 Speaker 1: How'd you like to listen to dot net rocks with 2 00:00:03,040 --> 00:00:07,879 no ads? Easy? Become a patron for just five dollars 3 00:00:07,919 --> 00:00:10,800 a month. You get access to a private RSS feed 4 00:00:10,839 --> 00:00:14,279 where all the shows have no ads. Twenty dollars a month, 5 00:00:14,279 --> 00:00:16,920 we'll get you that and a special dot net Rocks 6 00:00:16,960 --> 00:00:21,000 patron mug. Sign up now at Patreon dot dot NetRocks 7 00:00:21,120 --> 00:00:36,359 dot com. Hey, welcome back to dot net rocks. I'm 8 00:00:36,439 --> 00:00:39,320 Carl Franklin and I'm Richard Campbell. We are here for 9 00:00:39,359 --> 00:00:41,119 your dot net pleasure. 10 00:00:40,920 --> 00:00:42,719 Speaker 2: And any other pleasures you want. But you know, don't 11 00:00:42,759 --> 00:00:43,320 get crazy. 12 00:00:43,479 --> 00:00:47,840 Speaker 1: No, I'm gonna limit it to dot net Okay, maybe 13 00:00:47,840 --> 00:00:50,159 geek up pleasure, maybe a little science. 14 00:00:50,640 --> 00:00:53,119 Speaker 2: Yeah, I'm writing my indie year geek outs. Man, it's 15 00:00:53,560 --> 00:00:55,679 a pile of work, but I am working on them. 16 00:00:55,679 --> 00:00:58,520 Speaker 1: That's great. I can't wait to can't wait to hear them. 17 00:00:58,640 --> 00:00:58,840 Speaker 2: Yeah. 18 00:00:58,920 --> 00:01:01,399 Speaker 1: All right, Well let's get started with a little thing 19 00:01:01,439 --> 00:01:02,880 we call better no a framework. 20 00:01:03,000 --> 00:01:12,120 Speaker 2: Awesome. All right. 21 00:01:12,159 --> 00:01:14,719 Speaker 1: So I went looking to see what's trending as far 22 00:01:14,760 --> 00:01:19,040 as c sharp repositories on GitHub, and one that has 23 00:01:19,519 --> 00:01:22,439 recently got a lot of activity or a lot of 24 00:01:22,799 --> 00:01:28,239 coolness is Tom Hurst's t unit a modern, fast, and 25 00:01:28,400 --> 00:01:32,640 flexible dot net testing framework. Now I have never used it. 26 00:01:33,239 --> 00:01:36,239 I don't know anything about it except what it says 27 00:01:36,439 --> 00:01:40,200 in the repo, which is that it's modern and fast. 28 00:01:40,879 --> 00:01:44,319 T unit leverages source generators to locate and register your 29 00:01:44,359 --> 00:01:47,719 test as opposed to reflection. Nice you'll have a slight 30 00:01:47,799 --> 00:01:51,120 bump and build time, but a speedier runtime. T unit 31 00:01:51,239 --> 00:01:55,439 also builds upon the newer Microsoft Testing platform that's Microsoft 32 00:01:55,480 --> 00:01:58,920 Dot Testing dot Platform. Whereas most other frameworks you'll have 33 00:01:59,000 --> 00:02:03,560 to you'll use, we'll use vs tests. The new platform 34 00:02:03,640 --> 00:02:06,120 is reconstructed from the ground up to address pain points, 35 00:02:06,200 --> 00:02:07,719 be more extensible, and be faster. 36 00:02:07,959 --> 00:02:10,159 Speaker 2: So this is just a play on x unit, but 37 00:02:10,400 --> 00:02:14,080 x unit depends on reflection, and here they're using analyzers. 38 00:02:14,159 --> 00:02:15,319 Speaker 1: Yes, some sort. 39 00:02:15,159 --> 00:02:18,000 Speaker 2: Of modernized cunts. It's sort of modernized. Yeah, that's good idea. 40 00:02:18,080 --> 00:02:18,479 I like that. 41 00:02:18,560 --> 00:02:20,879 Speaker 1: Yeah. So, like I said, it's trending and you might 42 00:02:20,919 --> 00:02:23,280 want to check it out. That's when I got Richard, 43 00:02:23,319 --> 00:02:24,680 who's talking to us today. 44 00:02:24,479 --> 00:02:27,680 Speaker 2: Grady comment to off a show nineteen sixteen. So that's 45 00:02:27,719 --> 00:02:31,319 the one we did with Rendell back in September. They 46 00:02:31,360 --> 00:02:34,719 show I called how Simple is as Simple as Possible? 47 00:02:35,159 --> 00:02:35,479 Speaker 3: Right. 48 00:02:36,360 --> 00:02:39,879 Speaker 2: I mean, Rendell's a smart person, right like, he just 49 00:02:39,919 --> 00:02:43,800 thinks about development really coherently and very typical of you know, 50 00:02:43,879 --> 00:02:45,639 how do we do the right thing the right way? 51 00:02:45,680 --> 00:02:47,919 And it kicked off a ton of comments, lots of 52 00:02:47,919 --> 00:02:51,400 people reacting to the show, and Cash Bonfil said this, 53 00:02:51,520 --> 00:02:53,439 he said, this is a really interesting show and if 54 00:02:53,439 --> 00:02:56,280 it's writing discussions we're currently having at work. We're a 55 00:02:56,319 --> 00:02:58,560 team of eight developers all together, so hardly the size 56 00:02:58,599 --> 00:03:01,199 of Netflix. That it's okay, man, you don't need to 57 00:03:01,199 --> 00:03:03,520 be this side of Netflix. Now, that's set of problems. 58 00:03:03,800 --> 00:03:07,120 We're building a lot of micro services because we can. 59 00:03:07,960 --> 00:03:11,080 It's all good, but it comes to the price. One 60 00:03:11,120 --> 00:03:14,479 example is that we are making everything asynchronous, that is, 61 00:03:14,479 --> 00:03:17,199 with service bus integrations in the form of topics and queues. 62 00:03:17,280 --> 00:03:22,039 Again all good on paper, because every time we have 63 00:03:22,159 --> 00:03:24,919 AC and communications between our very small services, we have 64 00:03:25,000 --> 00:03:27,759 situations where things don't work out as it was supposed to. 65 00:03:28,080 --> 00:03:31,400 Messages end up on dlques and someone or something has 66 00:03:31,439 --> 00:03:34,240 to monitor and compensate. All of a sudden, we start 67 00:03:34,240 --> 00:03:37,639 building endpoints and handles on how I allow messages to 68 00:03:37,639 --> 00:03:40,240 be fixed and rerun. So we're spending our precious time 69 00:03:40,280 --> 00:03:44,759 creating things to compensate for architectural and infrastructure things instead 70 00:03:44,759 --> 00:03:49,560 of actually building business value. My point is that on 71 00:03:49,599 --> 00:03:52,960 an architectural drawing, a simple straight line might end up 72 00:03:52,960 --> 00:03:57,400 being insanely complex. Another funny thing, we started using dapper 73 00:03:57,479 --> 00:04:02,439 that's DAPR for the exact reasons that Mendel mentions. Eventually 74 00:04:02,479 --> 00:04:04,080 we left it again and it turned out to have 75 00:04:04,120 --> 00:04:07,599 to be a horrible developer experience. Dapper is another great 76 00:04:07,599 --> 00:04:09,759 example of being a good idea from an architectural point 77 00:04:09,759 --> 00:04:12,280 of view, but implementing it it was a nightmare. I'm 78 00:04:12,280 --> 00:04:13,960 pretty sure it will improve in the future, but the 79 00:04:14,000 --> 00:04:16,680 moment it's too mature from a developer's point of view. 80 00:04:16,759 --> 00:04:18,959 Thanks again for the great show. I always feel like 81 00:04:19,120 --> 00:04:21,160 having a biscuit and a cup of tea when you 82 00:04:21,240 --> 00:04:22,199 have rent a lot. 83 00:04:22,199 --> 00:04:27,040 Speaker 1: Absolutely or some fish and chips and a stout more. 84 00:04:26,959 --> 00:04:29,720 Speaker 2: Like, and it's stout and some mushy peas for sure. 85 00:04:29,879 --> 00:04:30,800 Speaker 1: Yeah, you can keep this. 86 00:04:32,199 --> 00:04:34,120 Speaker 2: You know, it's interesting that you've gone down that path 87 00:04:34,120 --> 00:04:35,959 and you're seeing the struggles around all of it. And 88 00:04:36,000 --> 00:04:39,439 again it's like, because you can thing problem now is 89 00:04:39,439 --> 00:04:43,120 that d architecting would be an interesting challenge, although it 90 00:04:43,120 --> 00:04:45,560 shouldn't be that tough. You've already done the hard work 91 00:04:45,639 --> 00:04:48,079 separating concerns. Now you want to put some of them 92 00:04:48,120 --> 00:04:51,600 back together. But great to hear the experiments going on 93 00:04:51,720 --> 00:04:54,000 and the challenges there. And you're a pretty big team. 94 00:04:54,040 --> 00:04:57,040 I mean eight people is enough that that ability is split. 95 00:04:57,120 --> 00:04:59,800 The work up's pretty cool. So COJH, thank you so 96 00:04:59,879 --> 00:05:01,680 much for your comment, and a coffee of music code 97 00:05:01,720 --> 00:05:03,079 by is on its way to you. And if you'd 98 00:05:03,120 --> 00:05:04,839 like a copy of musiccode buy, I write a comment 99 00:05:04,879 --> 00:05:06,920 on the website at dot NetRocks dot com or on 100 00:05:06,920 --> 00:05:08,920 the Facebook, so we publish every show there, and if 101 00:05:08,920 --> 00:05:10,240 you comment there and I read it on the show, 102 00:05:10,360 --> 00:05:11,800 we'll send you a copy of music cope or. 103 00:05:11,720 --> 00:05:13,279 Speaker 1: If you feel like buying music to code but how 104 00:05:13,319 --> 00:05:15,800 you can go to music tocode by dot net and 105 00:05:15,839 --> 00:05:18,680 you can also follow us on ex Twitter. Of course 106 00:05:18,680 --> 00:05:20,399 we've been there for years, but the cool kids are 107 00:05:20,399 --> 00:05:23,199 hanging out. I'm mastaed on, I'm at Carl Franklin at 108 00:05:23,199 --> 00:05:25,000 techeb dot social. 109 00:05:24,720 --> 00:05:26,800 Speaker 2: And I'm rich Campbell at masadon dot social. 110 00:05:27,040 --> 00:05:29,800 Speaker 1: Send us a two and uh, Richard. Before we get 111 00:05:29,800 --> 00:05:33,800 started here, I realized that I didn't do my you know, 112 00:05:33,839 --> 00:05:36,000 what happened in nineteen twenty three. This is show in 113 00:05:36,040 --> 00:05:38,199 nineteen twenty three, and we've sort of vowed to do that. 114 00:05:38,439 --> 00:05:40,759 Speaker 2: Oh wow, yeah, what happened in nineteen twenty three. 115 00:05:41,000 --> 00:05:44,120 Speaker 1: Well, I'm going through the Wikipedia thing because my usual 116 00:05:44,160 --> 00:05:46,399 page that we go to is down for some reason. 117 00:05:46,480 --> 00:05:50,519 But let's just pick a few here. January fifth, Lithuani 118 00:05:50,600 --> 00:05:56,480 begins the Clyppeeda revolt to annex the Clyipeda region. I 119 00:05:56,560 --> 00:05:57,040 don't know. 120 00:05:57,639 --> 00:06:01,079 Speaker 2: Oh no, this is pre World War two, right, so 121 00:06:01,160 --> 00:06:03,680 you're talking about the fall that's sort of the fallout 122 00:06:03,720 --> 00:06:05,399 of the end of the Ottoman Empire, and it's a 123 00:06:06,240 --> 00:06:07,560 it's craziness for sure. 124 00:06:07,639 --> 00:06:11,160 Speaker 1: March first, Eskom, the largest electricity producer in Africa, is 125 00:06:11,279 --> 00:06:15,160 established in South Africa. March third, the first issue of 126 00:06:15,240 --> 00:06:17,199 Time magazine is published. 127 00:06:17,319 --> 00:06:18,360 Speaker 2: Wow, that's cool. 128 00:06:18,519 --> 00:06:22,519 Speaker 1: March ninth, Vladimir Lenin suffers his third stroke, which renders 129 00:06:22,639 --> 00:06:26,519 him bedridden and unable to speak. Consequently, he retires from 130 00:06:26,519 --> 00:06:31,199 his position as chairman of the Soviet government. Let's see 131 00:06:31,519 --> 00:06:35,120 British Prime Minister in May Bonar Law resigns due to 132 00:06:35,160 --> 00:06:38,079 ill health. Okay, not all that oh, the Irish Civil 133 00:06:38,120 --> 00:06:43,160 War ended May twenty fourth. Let's see what else I 134 00:06:43,160 --> 00:06:49,319 can find here. July tenth, large hailstones killed twenty three 135 00:06:49,360 --> 00:06:51,439 people in Rostov and the Soviet Union. 136 00:06:52,439 --> 00:06:55,879 Speaker 2: Oh my wow, those are big hailstones that they're killing people. 137 00:06:56,000 --> 00:07:01,319 Speaker 1: Yeah. July twentieth, Pancho Villa is assassinated a Hidalgo de 138 00:07:01,480 --> 00:07:09,240 Palo Shiwawa. The Treaty of Lusine is signed, setting the 139 00:07:09,240 --> 00:07:12,279 boundaries of modern Republic of Turkey in Switzerland. 140 00:07:12,360 --> 00:07:14,399 Speaker 2: Right, I would argue the big thing in twenty three 141 00:07:14,519 --> 00:07:16,720 is the beer hall push is that's the beginning of 142 00:07:16,759 --> 00:07:20,639 the first coup attempt by Hitler and his go court 143 00:07:20,759 --> 00:07:22,439 hearts that failed. 144 00:07:22,519 --> 00:07:26,519 Speaker 1: Beer hall push, Beer hall pushed, Oh, pohar pusch. November eighth, 145 00:07:26,560 --> 00:07:29,240 in Munich, Adolf Hitler leads the Nazis and an unsuccessful 146 00:07:29,240 --> 00:07:32,759 attempt to overthrow the Bavarian government. Police and troops crushed 147 00:07:32,759 --> 00:07:34,800 the attempt. The next day. Twenty people die as a 148 00:07:34,800 --> 00:07:40,439 result of associated violence. And our friend Christian Vayer was 149 00:07:40,480 --> 00:07:41,160 not born yet. 150 00:07:41,240 --> 00:07:44,000 Speaker 2: No, but it did, you know? And one would argue 151 00:07:44,160 --> 00:07:47,519 the lack of consequences for the party at that time 152 00:07:47,879 --> 00:07:49,600 set them up for what would happen later. 153 00:07:49,839 --> 00:07:51,240 Speaker 1: Yeah, I don't know why you brought that up. Is 154 00:07:51,279 --> 00:07:54,360 there some sort of current event or something that you're 155 00:07:54,439 --> 00:07:54,959 referring to. 156 00:07:55,120 --> 00:07:58,399 Speaker 2: I'm not referring to anything, not referring to a thing. 157 00:07:58,399 --> 00:07:59,399 I don't know what you're talking about. 158 00:07:59,480 --> 00:08:02,519 Speaker 1: I don't know it's you're talking about either. Okay, all right, 159 00:08:02,600 --> 00:08:06,920 let's bring in our guest. Vlad Honanoff is a software 160 00:08:07,040 --> 00:08:11,519 architect with extensive industry experience, having held roles ranging from 161 00:08:11,560 --> 00:08:16,000 webmaster to chief architect. He currently helps organizations make sense 162 00:08:16,000 --> 00:08:22,040 of their business domains, untangled monoliths, and address complex architectural challenges. 163 00:08:22,759 --> 00:08:26,600 In twenty twenty one, Vlad published Learning Domain Driven Design, 164 00:08:27,240 --> 00:08:30,639 followed by his latest book, Balancing, Coupling and Software Design, 165 00:08:30,720 --> 00:08:35,399 released earlier this month. As a public speaker, Vlad presents 166 00:08:35,399 --> 00:08:39,120 at conferences worldwide on topics such as software architecture, demain 167 00:08:39,200 --> 00:08:42,919 driven design, and distributed systems. And I believe this is 168 00:08:42,919 --> 00:08:45,240 his first time on dot Netrock. So welcome, Flad. 169 00:08:45,320 --> 00:08:48,120 Speaker 4: Thank you so much. It's such an honor been here. 170 00:08:48,399 --> 00:08:49,559 Speaker 1: Oh you've heard of our show? 171 00:08:49,600 --> 00:08:52,519 Speaker 4: Then, yeah, bit, I started listening to you in two 172 00:08:52,559 --> 00:08:56,480 thousand and six, I believe, Wow, and then use Yeah, 173 00:08:56,720 --> 00:09:00,960 spoiled experience of listening to other podcasts for me because 174 00:09:01,360 --> 00:09:03,720 that's the quality I expected from the rest of them. 175 00:09:03,919 --> 00:09:05,279 Speaker 1: Yeah, we get that a lot. 176 00:09:07,600 --> 00:09:10,639 Speaker 2: We've always taken the engineering side of the show very seriously. Yeah, 177 00:09:10,679 --> 00:09:15,279 the content we have more fun, but quality audio is important. 178 00:09:19,759 --> 00:09:23,159 Speaker 1: Our content quality went way up when Richard joined the team, 179 00:09:23,279 --> 00:09:23,879 that's for sure. 180 00:09:24,240 --> 00:09:26,159 Speaker 2: That's a long time ago. Man, it's coming up on 181 00:09:26,279 --> 00:09:28,879 twenty years, like in a few months. 182 00:09:29,159 --> 00:09:34,399 Speaker 1: Yep, yep. And remember that serious lapse year that we 183 00:09:34,480 --> 00:09:37,600 had before you came on, where we started doing comedy 184 00:09:37,840 --> 00:09:42,120 and to two hour shows and what were we thinking. 185 00:09:41,919 --> 00:09:44,799 Speaker 2: Two and a half? Yeah, it was a variety showed. 186 00:09:44,840 --> 00:09:47,159 I remember talking about it. It's like there's a vent diagram here. 187 00:09:47,200 --> 00:09:49,879 There's a vent diagram of folks who want a technical 188 00:09:49,919 --> 00:09:54,279 interview and folks who want like music and geeky humor 189 00:09:54,320 --> 00:09:56,519 and all those things, and the intersection is small, but 190 00:09:56,559 --> 00:09:59,200 the two big other circles are big. Why don't we 191 00:09:59,240 --> 00:10:02,080 just pull them up? Part that's right, So Mondays was born, 192 00:10:02,279 --> 00:10:03,440 both shows got bigger. 193 00:10:03,559 --> 00:10:07,679 Speaker 1: Okay, lad, enough about us. Let's talk about your experience 194 00:10:07,879 --> 00:10:12,399 untangling monoliths and getting the balance of complexity right. What 195 00:10:12,440 --> 00:10:13,919 are you talking about. 196 00:10:14,200 --> 00:10:19,279 Speaker 4: Yeah, so actually the comment that Richard read that experience 197 00:10:19,720 --> 00:10:23,159 sounded kind of similar to what I went through a 198 00:10:23,159 --> 00:10:27,080 few years ago. We also had a system that was working, 199 00:10:27,159 --> 00:10:31,000 that was producing business value, but it was a monolith. 200 00:10:31,279 --> 00:10:34,000 It was a monolithic code base. So we said, okay, 201 00:10:34,120 --> 00:10:37,120 let's make it better by breaking it down into micro 202 00:10:37,240 --> 00:10:41,639 services or in other words, let's decouple things. Right, So 203 00:10:41,759 --> 00:10:46,519 we introduced tons of services that we call the micro services, 204 00:10:46,720 --> 00:10:51,200 of course, with asynchronous integration between them, and from that 205 00:10:51,440 --> 00:10:57,480 point on, it was impossible to evolve that system. It 206 00:10:57,519 --> 00:11:01,000 was impossible to change it because suddenly we had to 207 00:11:01,039 --> 00:11:05,320 modify tons of those services or I don't want to 208 00:11:05,360 --> 00:11:09,159 say microservices because they have nothing to do with micro services. 209 00:11:09,559 --> 00:11:11,279 Speaker 2: Yeah, I don't know how. I mean, how do you 210 00:11:11,320 --> 00:11:13,440 call it. It's only a micro service if you put 211 00:11:13,440 --> 00:11:15,279 that in the comments, like, I don't know the difference. 212 00:11:15,679 --> 00:11:17,039 It's just a service. Yeah. 213 00:11:17,159 --> 00:11:20,559 Speaker 1: The thing is they're completely separated, right. But I guess 214 00:11:20,559 --> 00:11:23,080 what we're talking about, and what we've been talking about 215 00:11:23,080 --> 00:11:26,279 the complexity aspect of it is when you want to 216 00:11:26,360 --> 00:11:29,279 implement a feature, you have to touch so many different 217 00:11:29,279 --> 00:11:33,279 places to make sure that it is still going to 218 00:11:33,320 --> 00:11:33,960 be robust. 219 00:11:35,159 --> 00:11:39,000 Speaker 4: Yeah. Yeah, and again it started with that decoupling effort 220 00:11:39,000 --> 00:11:42,440 by breaking things apart. But what we did is we 221 00:11:42,519 --> 00:11:48,720 increased coupling. Essentially, Now everything was coupled. And if previously 222 00:11:48,759 --> 00:11:51,080 we had to modify one code base, now we had 223 00:11:51,080 --> 00:11:55,120 to modify multiple projects and then synchronize changes, synchronize their 224 00:11:55,200 --> 00:11:59,440 life cycles. Tons of fun. And yeah, it was a 225 00:11:59,480 --> 00:12:01,039 failure atostrophic failure. 226 00:12:01,240 --> 00:12:03,519 Speaker 2: I mean the other the alternative there is that you 227 00:12:03,600 --> 00:12:06,639 run multiple versions of each service. I've gone down that 228 00:12:06,759 --> 00:12:09,320 path where it's like, hey, we're you know, if we 229 00:12:09,440 --> 00:12:11,720 change this API, we're going to affect these other things. 230 00:12:11,799 --> 00:12:13,559 It's like, okay, well let's keep this old one running, 231 00:12:13,559 --> 00:12:16,320 but we'll run a new one as well, and let's. 232 00:12:16,000 --> 00:12:19,080 Speaker 1: Have a service that returns the current versions of all 233 00:12:19,120 --> 00:12:20,960 the services that you should be running. 234 00:12:22,840 --> 00:12:26,120 Speaker 2: That wasn't a problem at all. We were fine, Everything 235 00:12:26,279 --> 00:12:29,799 was fine. That's fine. 236 00:12:31,519 --> 00:12:34,240 Speaker 1: If you had a merge conflict in that service, the 237 00:12:34,360 --> 00:12:39,919 version service service service version service, oh my god, nightmare. 238 00:12:40,240 --> 00:12:42,679 Speaker 2: But you know, I do feel like you're trading plumbing 239 00:12:42,759 --> 00:12:49,840 issues off for monolith issues. Nothing comes for free here. Yeah, absolutely, 240 00:12:50,000 --> 00:12:52,159 where's the balance in this? Because I know it's in 241 00:12:52,200 --> 00:12:52,639 the title. 242 00:12:54,639 --> 00:12:59,799 Speaker 4: Yeah. So, following that experience, that catastrophic failure of that project, 243 00:13:00,279 --> 00:13:02,799 I wanted to figure out what microservices are, how to 244 00:13:02,919 --> 00:13:07,480 design their boundaries properly. And I found the answers I 245 00:13:07,519 --> 00:13:12,279 was looking for in a book that was published in 246 00:13:12,440 --> 00:13:17,200 early seventies. It's called Structure Design, and the answers were 247 00:13:17,320 --> 00:13:22,600 in chapter on coupling, and in it I found some 248 00:13:22,679 --> 00:13:27,159 interesting things that our industry knew in the past, but 249 00:13:27,200 --> 00:13:31,480 we kind of have forgotten it now. So what I did, 250 00:13:31,840 --> 00:13:35,919 what I wanted to do, is to adapt those forgotten 251 00:13:36,240 --> 00:13:42,000 insights to our current technological world, the technologies we are 252 00:13:42,039 --> 00:13:46,399 working on today, and that's how the balanced coupling model 253 00:13:46,519 --> 00:13:51,879 was born. The idea here is that whenever you have 254 00:13:52,000 --> 00:13:56,360 two components, and these components can be anything, whether these 255 00:13:56,399 --> 00:14:01,279 are services, microservices, or two classes interacting with each other, 256 00:14:01,840 --> 00:14:05,480 in order to work together, they have to exchange some 257 00:14:05,600 --> 00:14:08,919 knowledge about each other, like what is your public interface, 258 00:14:09,720 --> 00:14:12,919 what is the format of the data I have to pass? 259 00:14:13,879 --> 00:14:17,480 Or maybe what are the assumptions I have to make 260 00:14:17,639 --> 00:14:21,919 about your behavior? So let's call that knowledge. The second 261 00:14:21,919 --> 00:14:25,840 aspect is the distance between them. Now, if we're talking 262 00:14:25,879 --> 00:14:30,679 about two classes, then their source code is located close 263 00:14:30,720 --> 00:14:32,840 to each other, those are probably the same files and 264 00:14:32,879 --> 00:14:33,720 the same directory. 265 00:14:33,960 --> 00:14:36,320 Speaker 2: Sure. On the other hand, in the same language. 266 00:14:36,399 --> 00:14:36,679 Speaker 1: Yeah. 267 00:14:37,000 --> 00:14:39,799 Speaker 4: On the other hand, if we're looking at two micro services, 268 00:14:39,960 --> 00:14:45,120 then we have much greater distance between those source codes. Right, 269 00:14:46,159 --> 00:14:51,799 greater distance. Now, why we should be interested in it 270 00:14:51,840 --> 00:14:56,799 is the greater the distance, the more collaboration and more 271 00:14:56,879 --> 00:15:00,600 communication effort you need to implement a change that affects 272 00:15:00,679 --> 00:15:03,279 both of them. So I'm going back to that example 273 00:15:03,279 --> 00:15:09,759 from the comment. Once you decompose a monelith into micro services, 274 00:15:10,080 --> 00:15:14,320 you're increasing the distance between those parts of the system. 275 00:15:14,399 --> 00:15:18,679 Those components. Now they're residing in different micro services, so 276 00:15:18,720 --> 00:15:22,440 we have greater distance. And when we look at these 277 00:15:22,679 --> 00:15:25,720 two the mansions, on the one hand, we have the 278 00:15:26,080 --> 00:15:29,039 knowledge that they have to share, and on the other 279 00:15:29,080 --> 00:15:33,360 hand we have distance between them. Then we can deduce 280 00:15:33,440 --> 00:15:38,960 some interesting insights by evaluating their extreme extreme combinations. For example, 281 00:15:39,000 --> 00:15:42,039 if you have a lot of knowledge change across a 282 00:15:42,039 --> 00:15:44,879 big distance, well, that's not going to be foul. 283 00:15:44,960 --> 00:15:45,120 Speaker 1: Right. 284 00:15:45,840 --> 00:15:49,120 Speaker 4: The more knowledge they share, the more cascading changes are 285 00:15:49,120 --> 00:15:53,120 going to follow, Like the more reasons to change together 286 00:15:53,320 --> 00:15:59,440 those components have. Now, when you couple that with the 287 00:15:59,480 --> 00:16:03,600 increased distance. Then we have lots of skating changes, and 288 00:16:03,639 --> 00:16:06,559 we have lots of effort needed to implement each of 289 00:16:06,600 --> 00:16:11,559 those changes. Bottom line, not fun. Or we can look 290 00:16:11,600 --> 00:16:16,399 at the opposite of that. What if we have two 291 00:16:16,440 --> 00:16:20,399 components that are not sharing much knowledge, maybe they are 292 00:16:20,440 --> 00:16:23,840 not even integrated. They're just located close to each other, 293 00:16:24,320 --> 00:16:28,440 so we have low knowledge and low distance between them. 294 00:16:28,960 --> 00:16:32,480 Now what we have is components that are not truly 295 00:16:32,559 --> 00:16:37,000 related to each other, located in the same code, based 296 00:16:37,039 --> 00:16:39,639 the same names, paid the same package module, however you 297 00:16:39,720 --> 00:16:44,039 call it. That's what we usually call the classic modelife 298 00:16:44,480 --> 00:16:46,279 or a big ball of mod You have a bunch 299 00:16:46,279 --> 00:16:48,879 of stuff that is not related, but it's close to 300 00:16:48,879 --> 00:16:51,919 each other, and the next time you have to modify something, 301 00:16:51,960 --> 00:16:55,039 you have to make your ways through those unrelated things 302 00:16:55,080 --> 00:16:58,039 to find what is that class or module that you 303 00:16:58,080 --> 00:17:03,240 do have to modify. And both these relationships high distance, 304 00:17:03,320 --> 00:17:07,559 high strength, high knowledge. I call that dimension of knowledge 305 00:17:07,599 --> 00:17:11,799 sharing integration strength. So once you have high integration strength 306 00:17:11,880 --> 00:17:16,319 and high distance, you have complexity on the overarching system. 307 00:17:16,559 --> 00:17:20,000 If you have low knowledge and low distance, then suddenly 308 00:17:20,039 --> 00:17:24,279 you have another type of complexity. You have cognitive load 309 00:17:24,559 --> 00:17:30,119 that results from you having to struggle to understand what's 310 00:17:30,119 --> 00:17:33,200 going on, what are those things that are implemented in 311 00:17:33,240 --> 00:17:36,519 the same module, and what do you have to modify 312 00:17:36,720 --> 00:17:40,440 when a new business requirement comes in. So those are 313 00:17:40,480 --> 00:17:45,400 two types of complexities. Now, what if we reverse these relationships. 314 00:17:45,480 --> 00:17:50,920 What if we will look at low integration strength, which 315 00:17:50,960 --> 00:17:56,759 means low amount of knowledge shared across a big distance. Well, 316 00:17:57,079 --> 00:18:03,200 big distance means that now we still have to to 317 00:18:03,319 --> 00:18:06,880 invest high effort in implementing cascating changes. On the other hand, 318 00:18:07,359 --> 00:18:10,400 we have that low integgression strength, So there we are 319 00:18:10,440 --> 00:18:15,000 minimizing the chances of those cascading chances a changes happening. 320 00:18:16,480 --> 00:18:20,519 And that relationship is usually what we call a loose coupling. 321 00:18:20,519 --> 00:18:23,119 Speaker 2: Right, and it's what happens most of the time, right 322 00:18:23,160 --> 00:18:25,240 when you're calling in the third party APIs and things 323 00:18:25,279 --> 00:18:27,920 like that. They're all loosely coupled because they are low 324 00:18:27,960 --> 00:18:31,400 distance with low levels of integration. Right, hopefully for long 325 00:18:31,400 --> 00:18:34,559 distance with low levels of integration, they're not inside your perimeter. 326 00:18:35,000 --> 00:18:38,240 They have skate context. Yeah, you know, you've got to 327 00:18:38,240 --> 00:18:40,640 carry your own state like you're not counting on anything, 328 00:18:40,759 --> 00:18:41,920 You're they're external to you. 329 00:18:42,000 --> 00:18:44,000 Speaker 1: Effect ask a question, get an answer. 330 00:18:44,720 --> 00:18:48,039 Speaker 4: Yeah, And the opposite of that is going to be high. 331 00:18:48,039 --> 00:18:51,279 I'm out of an aggression strength high amount of knowledge over. 332 00:18:51,519 --> 00:18:53,200 Speaker 2: Small distance right now local. 333 00:18:53,440 --> 00:18:53,680 Speaker 1: Yeah. 334 00:18:53,960 --> 00:18:57,319 Speaker 4: Now, we do want to minimize the knowledge we are 335 00:18:57,359 --> 00:19:01,039 sharing across the boundaries of components, of course, but it's 336 00:19:01,079 --> 00:19:04,119 not always possible. Sometimes we do have to share knowledge 337 00:19:04,279 --> 00:19:07,240 because maybe we have two components that are implementing closely 338 00:19:07,279 --> 00:19:10,680 related business functionalities, so we have to share knowledge. 339 00:19:10,720 --> 00:19:14,079 Speaker 1: Yeah, maybe they're both injecting the same services, that kind 340 00:19:14,119 --> 00:19:14,400 of thing. 341 00:19:14,519 --> 00:19:18,799 Speaker 4: Yeah, Yeah, there are different levels of evaluating that knowledge. 342 00:19:19,240 --> 00:19:22,079 So let's assume we're on that higher end of the scale, 343 00:19:23,599 --> 00:19:26,559 and there is no way for us to reduce the 344 00:19:26,599 --> 00:19:30,400 amount of knowledge in that case by putting them closer 345 00:19:30,480 --> 00:19:33,079 to each other. We know, we acknowledge that. Yeah, they 346 00:19:33,119 --> 00:19:37,440 will change together, but we are preparing ourselves by minimizing reasy. 347 00:19:37,680 --> 00:19:40,519 Speaker 2: Easy to do that. Yeah, So if I mean I 348 00:19:40,559 --> 00:19:44,079 see the rule emerging here, then this, Hey, these two 349 00:19:44,119 --> 00:19:46,720 things are to be closely tied together, we should make 350 00:19:46,720 --> 00:19:50,759 sure they're close. Yeah, yeah, yeah, and that. In nineties 351 00:19:51,559 --> 00:19:57,839 a model was formulated called connaisance, and in that model, 352 00:19:58,519 --> 00:20:03,279 its author Miller Page Jones use that word proximity to 353 00:20:03,359 --> 00:20:06,880 say that things should be in close proximity to each other. 354 00:20:07,200 --> 00:20:10,480 I prefer the world distance, which is the opposite of 355 00:20:10,480 --> 00:20:12,079 proximity for other reasons. 356 00:20:12,839 --> 00:20:13,160 Speaker 1: Yeah. 357 00:20:13,279 --> 00:20:14,599 Speaker 4: Yeah, but that's so. 358 00:20:15,119 --> 00:20:18,400 Speaker 1: The basic idea is that go ahead and have your 359 00:20:18,480 --> 00:20:21,519 micro services or your services or whatever, but those that 360 00:20:21,640 --> 00:20:24,759 share knowledge should be closer together, and the ones that 361 00:20:24,799 --> 00:20:29,039 should be have more distance, should have less dependency on 362 00:20:29,839 --> 00:20:32,160 each other. Yeah, share share less. 363 00:20:31,960 --> 00:20:35,359 Speaker 4: Knowledge, Yeah exactly, Yeah, and that makes sense. The next 364 00:20:35,400 --> 00:20:38,240 question is how do you evaluate that knowledge? 365 00:20:39,039 --> 00:20:39,279 Speaker 1: Right? 366 00:20:39,480 --> 00:20:43,799 Speaker 4: Yeah, And that's the complicated part, because how do you 367 00:20:43,880 --> 00:20:48,240 measure knowledge? Like what is the management measurement unit for knowledge? Yeah? 368 00:20:48,480 --> 00:20:50,119 Speaker 2: But how much do I need to know? 369 00:20:50,440 --> 00:20:55,680 Speaker 4: Yeah? Yeah, And for that I adapted that model from 370 00:20:55,960 --> 00:21:00,680 seventy's book Structure Design to differentiate between a number of 371 00:21:01,400 --> 00:21:05,519 types of knowledge knowledges. Now, once we're dealing with types, 372 00:21:05,680 --> 00:21:08,240 we don't have to measure the exact amount of knowledge, 373 00:21:08,279 --> 00:21:13,079 because once we're going higher on that scale of types, 374 00:21:13,359 --> 00:21:17,200 the amount is going to be significantly higher anyway. So 375 00:21:18,720 --> 00:21:22,680 overall there are four levels, four basic levels. One of 376 00:21:22,720 --> 00:21:25,720 them is, let's say if we are implementing two components. 377 00:21:27,279 --> 00:21:31,920 Let's say Richard, you're implementing micro service, which means when 378 00:21:32,240 --> 00:21:35,599 I'm integrating with it, I should be using its public interface, 379 00:21:36,079 --> 00:21:37,920 but I'm not going to do it. Instead, I will 380 00:21:37,960 --> 00:21:41,200 reach out to your database directly and take whatever the 381 00:21:41,240 --> 00:21:41,839 data I need. 382 00:21:43,000 --> 00:21:46,119 Speaker 1: Yeah, it. 383 00:21:47,720 --> 00:21:50,279 Speaker 2: Memories make the batman stop. 384 00:21:50,920 --> 00:21:53,519 Speaker 4: Yeah. So what I'm doing here is I'm introducing a 385 00:21:53,519 --> 00:21:55,799 dependency on your implementation detail. 386 00:21:55,599 --> 00:21:58,039 Speaker 2: Right, and I can break you very easily by modifying 387 00:21:58,079 --> 00:21:59,440 my database for my next version. 388 00:21:59,559 --> 00:21:59,960 Speaker 4: Exactly. 389 00:22:00,000 --> 00:22:03,039 Speaker 2: I not know that I did exactly. Yeah. 390 00:22:03,200 --> 00:22:07,359 Speaker 4: That's why let's call this level intrusive coupling. I am 391 00:22:07,440 --> 00:22:08,920 intruding your boundaries. 392 00:22:09,400 --> 00:22:11,160 Speaker 2: I mean in a way that doesn't bother me all 393 00:22:11,160 --> 00:22:14,200 that much, because you're I can break you. You can't 394 00:22:14,240 --> 00:22:14,960 really break me. 395 00:22:15,279 --> 00:22:16,599 Speaker 4: It depends what I'm doing there. 396 00:22:17,039 --> 00:22:19,160 Speaker 2: It's kind of like the beer puts. Yeah, I mean 397 00:22:19,160 --> 00:22:21,599 you can't. You're right, you can by inserting weird data 398 00:22:21,640 --> 00:22:25,359 into my database. Yeah, that you know, can break my 399 00:22:25,480 --> 00:22:28,640 code expecting certain consistency in the database, which is my fault. 400 00:22:28,640 --> 00:22:30,519 I should have had put parameters on my database that 401 00:22:30,519 --> 00:22:31,440 don't allow you to do that. 402 00:22:31,880 --> 00:22:35,480 Speaker 4: Yeah. So that's intrusive coupling. That's the highest level of 403 00:22:35,680 --> 00:22:38,400 knowledge sharing. We're assuming that this is the knowledge you 404 00:22:38,440 --> 00:22:38,720 shared it. 405 00:22:38,960 --> 00:22:42,079 Speaker 2: Yeah, but this seems like I don't do this, this 406 00:22:42,160 --> 00:22:42,559 is bad. 407 00:22:42,640 --> 00:22:43,400 Speaker 1: Yeah, this is only. 408 00:22:43,319 --> 00:22:46,160 Speaker 4: Level one depends let's get back to it. 409 00:22:46,559 --> 00:22:47,799 Speaker 2: Okay, let's get back to it. 410 00:22:48,720 --> 00:22:51,920 Speaker 4: The next level is functional coupling, and here we have 411 00:22:52,119 --> 00:22:56,200 two components that are implementing closely related functionalities. Maybe they're 412 00:22:56,200 --> 00:22:59,240 implementing closely related use cases, but the bottom line is 413 00:22:59,519 --> 00:23:03,839 the wheel have to change together when the business requirements. 414 00:23:03,359 --> 00:23:05,000 Speaker 2: Change, so they resonate together. 415 00:23:05,200 --> 00:23:05,440 Speaker 1: Yeah. 416 00:23:05,920 --> 00:23:10,240 Speaker 4: Yeah, So they have to share lots of knowledge because 417 00:23:10,279 --> 00:23:14,079 once that functional dependency is there, we have to make 418 00:23:14,920 --> 00:23:18,759 an assumption that there will be business rules that both 419 00:23:18,759 --> 00:23:23,279 of them will have to follow. So that's the functional coupling. Now, 420 00:23:23,359 --> 00:23:27,680 there are different degrees of functional coupling. Let's not get 421 00:23:27,759 --> 00:23:30,680 into it because we'll need another hour just for that 422 00:23:30,799 --> 00:23:31,440 sure topic. 423 00:23:31,640 --> 00:23:33,119 Speaker 2: But is it one of the arguments that you should 424 00:23:33,119 --> 00:23:35,160 have been the same service. 425 00:23:35,559 --> 00:23:37,599 Speaker 4: Yes, but let's get back to it later. 426 00:23:37,960 --> 00:23:39,279 Speaker 2: Okay, I'm jumping head. 427 00:23:39,599 --> 00:23:40,279 Speaker 1: Yeah. 428 00:23:41,559 --> 00:23:45,559 Speaker 4: The third level is model coupling. This one means that 429 00:23:45,599 --> 00:23:48,119 we have two components that share the knowledge of the 430 00:23:48,200 --> 00:23:53,160 model of the business domain that are using Now, every 431 00:23:53,160 --> 00:23:54,880 time I talk about this level, I have to wear 432 00:23:54,920 --> 00:23:59,279 my dominion and design guide CAP because it's heavily influenced 433 00:23:59,319 --> 00:24:02,599 by the Clean Dream design. And the thing is, when 434 00:24:02,599 --> 00:24:04,519 we are implementing a system, of course, we are not 435 00:24:04,680 --> 00:24:08,480 coding all the knowledge available about that business domain, but 436 00:24:08,559 --> 00:24:11,599 we have to pick whatever we think is relevant to 437 00:24:11,720 --> 00:24:14,279 solve the problem that we want to solve for the 438 00:24:14,400 --> 00:24:18,440 users of our systems. Right, So we're crafting a model 439 00:24:18,480 --> 00:24:23,680 of a business domain now with new requirements, with new 440 00:24:23,799 --> 00:24:29,359 insights into business domain. That model should evolve over time. 441 00:24:30,200 --> 00:24:34,279 Once we're sharing that knowledge, we kind of reducing our 442 00:24:34,319 --> 00:24:38,200 ability to evolve that model, so it can be problematic 443 00:24:38,240 --> 00:24:43,160 in some cases. That's the third level of integration strengths. 444 00:24:43,880 --> 00:24:47,920 Speaker 2: But models don't change as often as functionality does. 445 00:24:48,079 --> 00:24:50,559 Speaker 4: Well, it depends what kind of system you're working on. 446 00:24:51,079 --> 00:24:52,920 Let's say that you are working for a star up 447 00:24:52,960 --> 00:24:58,279 company and at the first stages there's so much uncertainty 448 00:24:58,440 --> 00:25:02,559 about twitching. Yeah, everything about how we're going to solve 449 00:25:02,559 --> 00:25:05,720 the problem for our customers, and even the problem itself 450 00:25:05,720 --> 00:25:09,400 can change. Yeah, So that's model coupling. The third level, Now, 451 00:25:09,559 --> 00:25:13,680 the lowest one is what I call contract coupling. And 452 00:25:13,920 --> 00:25:19,440 here we have an integration specific contract that was formulated 453 00:25:20,119 --> 00:25:24,079 for integration purposes only. Its goal is to encapsulate all 454 00:25:24,119 --> 00:25:29,279 the knowledge about implementation details, all knowledge about functional requirements, 455 00:25:29,400 --> 00:25:32,279 and of course all the knowledge about the model of 456 00:25:32,319 --> 00:25:36,680 the business domain that's being used to implement the component. 457 00:25:38,680 --> 00:25:41,720 What we want to expose is a much more stable 458 00:25:41,759 --> 00:25:45,880 interface that is not going to be changed after each 459 00:25:45,960 --> 00:25:49,640 new business requirement that comes in something way more stable. 460 00:25:49,759 --> 00:25:53,799 Speaker 2: This is that public API inter face mindset exactly. 461 00:25:53,880 --> 00:25:58,000 Speaker 4: Yeah, yeah, yeah. And if I will bring back my 462 00:25:58,119 --> 00:26:01,119 domain gveing design cap again, then have anti corruption layer, 463 00:26:01,200 --> 00:26:06,480 we have open host service. These parents. What they're doing 464 00:26:06,559 --> 00:26:13,680 essentially is introducing an integration contract for those purposes. So 465 00:26:13,720 --> 00:26:17,680 we have four types of interfaces, contract, model, functional, and interesting. 466 00:26:18,720 --> 00:26:22,880 These are four types of knowledges, and we cannot put 467 00:26:22,920 --> 00:26:27,240 a number to evaluate the amount of knowledge we are sharing. 468 00:26:27,519 --> 00:26:31,920 But knowing these four types already helps us to evaluate 469 00:26:32,000 --> 00:26:32,640 where we are. 470 00:26:33,119 --> 00:26:37,359 Speaker 2: Yeah, at least get people in the categories, right, yeah. 471 00:26:37,880 --> 00:26:40,599 Speaker 4: Now, as I mentioned in the book, there are degrees 472 00:26:40,839 --> 00:26:44,839 for functional model and contract coupling, so that you can 473 00:26:44,880 --> 00:26:48,680 compare to interfaces of the same type. These degrees are 474 00:26:48,720 --> 00:26:51,759 based on the conations model. It has lots of levels, 475 00:26:51,799 --> 00:26:54,400 so it will require another hour. 476 00:26:54,680 --> 00:26:58,440 Speaker 2: Just that topic, by the book is a good number, right, 477 00:26:58,519 --> 00:27:01,559 Like you could probably discribe, especially at the functional level, 478 00:27:01,559 --> 00:27:03,799 you could discriminate a bunch of options in there. But 479 00:27:04,440 --> 00:27:07,039 I'm with you. Four you can feel good about. It's like, 480 00:27:07,519 --> 00:27:10,279 I'm not just thinking that all coupling is bad. I'm 481 00:27:10,279 --> 00:27:14,240 recognizing some is necessary, but some has larger consequences than others. 482 00:27:14,519 --> 00:27:18,039 Speaker 4: Yeah. Now, let's talk about the dimension of space, the 483 00:27:18,079 --> 00:27:21,440 distance between those components. So on the one hand, we 484 00:27:21,519 --> 00:27:26,079 have the code base where the components are implemented. If 485 00:27:26,119 --> 00:27:28,799 the files are in the same directory, the distance is low, 486 00:27:29,039 --> 00:27:31,160 or maybe in the same file even the distance is 487 00:27:31,200 --> 00:27:36,799 minimized versus let's say, different project, different repositories. But there 488 00:27:36,880 --> 00:27:41,400 is another aspect to that dimension, and it's organizational. First. 489 00:27:41,519 --> 00:27:45,759 Let's say that we have two micro services, and we 490 00:27:45,799 --> 00:27:49,640 have two cases. In the first one, both micro services 491 00:27:49,720 --> 00:27:53,319 are implemented by the same team. In the second one, 492 00:27:53,480 --> 00:27:57,559 we have two micro services implemented by different teams. In 493 00:27:57,599 --> 00:28:01,880 the second case, we'll need much higher collaboration and communication 494 00:28:01,960 --> 00:28:05,599 effort to implement a change. So it also affects the distance. 495 00:28:05,720 --> 00:28:07,599 Speaker 2: I mean, I argue it's the same amount of communication 496 00:28:07,640 --> 00:28:10,880 it's just one is easy because you're in the same team, 497 00:28:10,960 --> 00:28:13,880 and one needs more structure because you're not the same. 498 00:28:14,160 --> 00:28:18,920 Speaker 4: Yeah, exactly, So we have that organizational aspect that increases 499 00:28:19,119 --> 00:28:22,400 the distance. And also again going back to the comment 500 00:28:22,480 --> 00:28:25,160 that you read in the beginning of the show, Let's 501 00:28:25,160 --> 00:28:30,240 say we have two components that are imp implementing synchrons 502 00:28:30,319 --> 00:28:34,359 communication between them, and the second case with asynchronous communication 503 00:28:34,480 --> 00:28:38,400 between them. Right now, in the case of asynchronus communication, 504 00:28:39,880 --> 00:28:44,480 we have a bigger distance between them, bigger virtual distance 505 00:28:44,480 --> 00:28:48,640 between them. Let's say that way because we have a 506 00:28:51,000 --> 00:28:53,720 lower life cycle dependency between them. 507 00:28:53,799 --> 00:28:54,079 Speaker 2: Right. 508 00:28:54,319 --> 00:28:58,799 Speaker 4: If we have low distance, let's say components implemented in 509 00:28:58,839 --> 00:29:01,880 the same monolith, then we have that life cycle dependency 510 00:29:01,880 --> 00:29:07,359 between those services. Everything within that MAELD have to be implemented, tested, 511 00:29:07,400 --> 00:29:08,440 and deployed. 512 00:29:08,240 --> 00:29:10,599 Speaker 2: Simultaneously, functionally, but coupled. 513 00:29:11,039 --> 00:29:11,319 Speaker 1: Yeah. 514 00:29:11,440 --> 00:29:15,160 Speaker 4: Once we were introducing that asynchronous communication between them, we 515 00:29:15,200 --> 00:29:17,359 are kind of extending the distance, right. 516 00:29:17,440 --> 00:29:17,759 Speaker 1: Yeah. 517 00:29:17,839 --> 00:29:20,759 Speaker 4: Now, let's go back to the topic of ineggression strength. 518 00:29:21,119 --> 00:29:24,119 Let's say that we have two components share lots of 519 00:29:24,160 --> 00:29:31,200 knowledge between them. Let's say they have interessive coupling between them. 520 00:29:31,359 --> 00:29:36,359 The bad one M and let's assume we have high 521 00:29:36,359 --> 00:29:40,920 distance between them. Is this design necessarily bad? 522 00:29:41,359 --> 00:29:44,160 Speaker 2: I mean, it's got a lot of consequences to it. Yeah, right, 523 00:29:44,240 --> 00:29:47,480 and you need a lot of communicating to move you're 524 00:29:47,799 --> 00:29:51,599 often going to have if you've got a good testing harness, 525 00:29:51,640 --> 00:29:54,079 it's going to fail a lot because you're moving things 526 00:29:54,079 --> 00:29:55,319 that affect the other composers. 527 00:29:55,440 --> 00:29:59,000 Speaker 1: I would ask, why did you choose this model? Oh, 528 00:29:59,039 --> 00:30:00,400 why do you need that? 529 00:30:00,400 --> 00:30:03,680 Speaker 4: That's a great question, So I'll provide you more information 530 00:30:03,720 --> 00:30:06,440 about the context. So here's the thing. I work on 531 00:30:06,480 --> 00:30:11,319 a system that integrates with a legacy system that is there. 532 00:30:12,440 --> 00:30:15,519 This is not going to change ever. Nobody wants to 533 00:30:15,519 --> 00:30:18,759 touch it, so there's no one I can ask to 534 00:30:18,799 --> 00:30:22,079 add new interface to it so that I can work with. 535 00:30:22,200 --> 00:30:23,359 Speaker 2: You're not going to get any changes. 536 00:30:23,480 --> 00:30:25,799 Speaker 1: Got to go directly to the database, that's what you're saying. 537 00:30:25,920 --> 00:30:28,759 Speaker 4: Yeah, so I will do it. But I made that 538 00:30:28,799 --> 00:30:32,480 assumption that that legacy system is not going to change, 539 00:30:32,599 --> 00:30:35,880 right right, Okay, And that's the third dimension of coupling volatility. 540 00:30:36,480 --> 00:30:38,720 Speaker 1: Hey, I think this feels like a good place to 541 00:30:38,759 --> 00:30:40,920 take a break, So hold that thought. Flag will come 542 00:30:41,000 --> 00:30:44,559 right back after these very important messages don't go away. 543 00:30:44,599 --> 00:30:47,279 Did you know that you can work with AWS directly 544 00:30:47,319 --> 00:30:53,279 from your ID. AWS provides toolkits for visual studio, visual studio, code, 545 00:30:53,559 --> 00:30:57,640 and jet brains rider. Learn more at AWS dot Amazon 546 00:30:57,720 --> 00:31:03,920 dot com, slash net slash tools, and we're back. It's 547 00:31:03,920 --> 00:31:07,839 dot net rocks. I'm Carl Franklin, that's Richard Hey Campbell, 548 00:31:08,000 --> 00:31:17,359 and we're talking to Vlatkonanoff about you know, decoupling, coupled, balancing, decoupling, 549 00:31:17,400 --> 00:31:18,519 I think is what we're calling it. 550 00:31:18,599 --> 00:31:20,880 Speaker 2: Yeah, balancing coupling. 551 00:31:20,960 --> 00:31:23,160 Speaker 1: Yeah, balancing coupling or dec degree. 552 00:31:23,200 --> 00:31:26,319 Speaker 2: So you just hit a third dimension there, the volatility 553 00:31:26,880 --> 00:31:30,400 versus the distance, which is not necessarily a physical distance. 554 00:31:30,440 --> 00:31:34,279 It's also are the teams separated or are they on 555 00:31:34,400 --> 00:31:37,519 disparate teams? Might be security boundaries. There's a bunch of 556 00:31:37,559 --> 00:31:40,960 different ways with great separation. And then the level of 557 00:31:41,880 --> 00:31:45,880 interaction or the coupling within the code, how tightly tied 558 00:31:45,880 --> 00:31:50,519 together they are, Yeah, alas sharing, so yeah, they manage 559 00:31:50,559 --> 00:31:54,240 knowledge sharing and the bund scenario you painted there where 560 00:31:54,240 --> 00:31:57,519 it's like, Okay, I'm doing some intrusive coupling on it 561 00:31:58,400 --> 00:32:01,279 in my new app against its existing app, which is 562 00:32:01,440 --> 00:32:04,839 relatively nearby. We're working in the same context, but its 563 00:32:04,920 --> 00:32:07,680 volatility is very low, as in, I'm one of the 564 00:32:07,680 --> 00:32:10,200 reasons I'm doing this intrusive behavior is because I cannot 565 00:32:10,279 --> 00:32:13,839 change the other phase. So that doesn't seem to me 566 00:32:13,920 --> 00:32:17,400 like the lowest thing. It seems like the only solution circumstance. 567 00:32:17,599 --> 00:32:21,720 Speaker 4: Yeah, and that brings us to the title of that 568 00:32:21,799 --> 00:32:25,720 model balanced coupling. Once we have those three dimensions, once 569 00:32:25,720 --> 00:32:28,920 we can evaluate them, we can say, okay, so we 570 00:32:29,000 --> 00:32:31,519 have in aggression strength and we have distance, and we 571 00:32:31,680 --> 00:32:34,680 have to be inversely proportional to each other. Okay, okay, 572 00:32:34,839 --> 00:32:37,559 once one of them gets higher, the second one should 573 00:32:37,599 --> 00:32:41,200 get lower. We can even find some middle ground. We 574 00:32:41,240 --> 00:32:45,680 have middle amount of medium amount of knowledge, then medium 575 00:32:45,720 --> 00:32:51,759 distance is okay too. But sometimes we're needed. We can 576 00:32:51,799 --> 00:32:56,160 be a bit more pragmatic by introducing that third dimension 577 00:32:56,200 --> 00:33:01,440 of volatility. And if components are not expected to change, 578 00:33:02,039 --> 00:33:05,359 those components that are sharing the knowledge, then it can 579 00:33:05,400 --> 00:33:09,680 be okay to allow them to share high amounts of 580 00:33:09,759 --> 00:33:11,519 knowledge across big distances. 581 00:33:12,039 --> 00:33:14,240 Speaker 2: Right. Yeah, and well, and again you get into that 582 00:33:14,240 --> 00:33:16,319 motion of hey, we're finding a lot of coupling between this. 583 00:33:16,519 --> 00:33:18,720 Maybe we need to get this into the same team, 584 00:33:19,079 --> 00:33:21,400 like a lawful lot of complexity would end if we 585 00:33:21,440 --> 00:33:24,400 move that team member on that other team over with 586 00:33:24,559 --> 00:33:27,920 us while this work is going on, and then communication 587 00:33:28,000 --> 00:33:31,240 becomes easier. We can get through this period and decide 588 00:33:31,240 --> 00:33:36,160 what happens from there, as opposed to, Hey, this is 589 00:33:36,559 --> 00:33:39,640 complicated and it's distant, and we can't do anything about 590 00:33:39,640 --> 00:33:41,640 that part, so let's minimize the volatility. 591 00:33:42,680 --> 00:33:45,920 Speaker 4: Yeah, And that's a very interesting comment because in the 592 00:33:45,960 --> 00:33:50,319 book I'm talking about software design. However, we had a 593 00:33:50,359 --> 00:33:53,559 conversation with a friend of mine, a Sonya and Tanzem 594 00:33:54,440 --> 00:33:59,920 about the organizational design, and turns out we can use 595 00:34:01,319 --> 00:34:04,200 the same model to evaluate the design of the organization. 596 00:34:04,400 --> 00:34:07,680 Like if you have people in the same team who 597 00:34:07,720 --> 00:34:11,840 are working on underlated things, which means they're not sharing 598 00:34:11,880 --> 00:34:14,480 much knowledge between them, right, why do we need them 599 00:34:14,639 --> 00:34:15,400 in one team? 600 00:34:15,800 --> 00:34:17,760 Speaker 2: Why? Yeah? Why are in the same team? 601 00:34:17,840 --> 00:34:18,079 Speaker 1: Yeah? 602 00:34:18,559 --> 00:34:21,719 Speaker 2: And the opposite you do you talk about Conway's law, 603 00:34:21,800 --> 00:34:26,599 this idea that the team architecture also tends to dictate 604 00:34:26,599 --> 00:34:29,239 the software architecture effectively, like if you if you have 605 00:34:29,400 --> 00:34:31,800 three teams, you're going to make a three pass parser. Yeah, 606 00:34:32,519 --> 00:34:35,119 that's just how it's going to happen, and now you're 607 00:34:35,159 --> 00:34:38,440 talking about, Hey, as we get to the best architecture 608 00:34:38,480 --> 00:34:41,000 on this, we could start shaping the team structure so 609 00:34:41,039 --> 00:34:42,679 that Tonway's law doesn't fight us. 610 00:34:43,559 --> 00:34:43,800 Speaker 1: Yeah. 611 00:34:43,840 --> 00:34:45,079 Speaker 4: Absolutely, I think. 612 00:34:45,000 --> 00:34:48,280 Speaker 2: That's really interesting. And you've described a scenario now where 613 00:34:48,519 --> 00:34:50,880 you might want to add a team member or even 614 00:34:50,960 --> 00:34:55,480 separate a team. Both scenarios are reasonable, which is probably 615 00:34:55,519 --> 00:34:57,800 a fairly good case. Then it's like, in both cases 616 00:34:57,800 --> 00:35:00,280 you can see why you would change the organization to 617 00:35:00,360 --> 00:35:01,679 reflect that intended art. 618 00:35:01,719 --> 00:35:05,000 Speaker 1: First we fix the architecture, then we fix the team architecture. 619 00:35:05,199 --> 00:35:06,760 Speaker 2: Perhaps, Yeah, I mean I think there's going to be 620 00:35:06,760 --> 00:35:09,800 an oscillation back and forth, Like we don't always see 621 00:35:09,840 --> 00:35:11,679 that these two things are going to end up coupled, 622 00:35:11,800 --> 00:35:16,079 right as that as they requirements e merge and you 623 00:35:16,119 --> 00:35:18,239 start seeing this is more and more and more coupled, 624 00:35:18,280 --> 00:35:21,559 you might have as anario where it's like, yeah, okay, 625 00:35:21,599 --> 00:35:25,079 we should probably bring these things together, but this participant 626 00:35:25,119 --> 00:35:28,159 can't necessarily join that team in easily. Should we change 627 00:35:28,199 --> 00:35:30,719 the team member into somebody you know, switch who's going 628 00:35:30,800 --> 00:35:32,760 to work on that into someone in that other team, 629 00:35:33,159 --> 00:35:36,039 because it'll make all of these other things easier, Like, yeah, 630 00:35:36,360 --> 00:35:38,840 that's an overhead too to change team members like that, 631 00:35:39,239 --> 00:35:41,800 but it might be less expensive than continuing in the 632 00:35:41,800 --> 00:35:43,239 current the current layout. 633 00:35:43,480 --> 00:35:47,960 Speaker 4: Yeah, And as they say, organizational design always wins, right, 634 00:35:48,880 --> 00:35:55,599 So we need that that way of evaluating the type 635 00:35:55,639 --> 00:35:58,679 of knowledge that is being shared, whether it's across technical 636 00:35:58,760 --> 00:36:01,599 components or across teams or team members. 637 00:36:01,719 --> 00:36:05,000 Speaker 1: Yeah, it's easier to change code than people. 638 00:36:05,079 --> 00:36:07,519 Speaker 2: But sometimes it's more efficient to change the people if 639 00:36:07,519 --> 00:36:09,920 you can, Yeah, if you can. Like what I like 640 00:36:10,039 --> 00:36:13,960 is we've created a reason to have that conversation. Yes, Like, 641 00:36:14,039 --> 00:36:16,639 when I think in terms of balance company and balancing 642 00:36:16,679 --> 00:36:20,840 these three numbers, one of the options suddenly becomes do 643 00:36:20,920 --> 00:36:23,920 we change the team to compensate with this problem? Is 644 00:36:23,960 --> 00:36:26,239 that even a possibility, because sometimes that'd be a very 645 00:36:26,239 --> 00:36:28,679 easy solve, Like that person's always wanted to be on 646 00:36:28,719 --> 00:36:30,199 that team, and now we have a good reason to 647 00:36:30,199 --> 00:36:34,280 put them there, at least introducing that factor, like the 648 00:36:34,360 --> 00:36:35,920 idea that we're going to use conways a lot in 649 00:36:36,000 --> 00:36:38,239 our favor, and we're going to shuffle the team to 650 00:36:38,320 --> 00:36:41,800 increase the quality of software. That's slick, man, that's good thinking. 651 00:36:42,119 --> 00:36:44,639 Speaker 1: It's been my experience, Richard, maybe years two and laid 652 00:36:44,719 --> 00:36:48,400 for that matter, that it's easier to add people to 653 00:36:48,480 --> 00:36:52,559 a team than to remove them, sure enough from a team, 654 00:36:53,000 --> 00:36:54,760 and people don't like being removed. 655 00:36:55,599 --> 00:36:58,800 Speaker 2: I find depends on the person. But also like you 656 00:36:58,800 --> 00:37:01,079 can work into more independent you don't need to be here. 657 00:37:01,320 --> 00:37:03,199 Speaker 1: Yeah, there's another team we want you to be on 658 00:37:03,239 --> 00:37:05,360 because it'd be more effective there, and that kind of thing. 659 00:37:05,559 --> 00:37:09,239 Speaker 2: Yeah, this is the personality thing. But I just liked 660 00:37:09,239 --> 00:37:10,599 that you could put it on the table now in 661 00:37:10,639 --> 00:37:14,440 a coherent way. It's not political. I'm not after that 662 00:37:14,519 --> 00:37:17,159 person or anything like that. I see an issue in 663 00:37:17,199 --> 00:37:22,039 our architecture that is going to lead to consequences, and 664 00:37:22,119 --> 00:37:24,239 maybe a change of team would mitigate that. 665 00:37:24,920 --> 00:37:25,400 Speaker 1: Interesting. 666 00:37:25,599 --> 00:37:30,000 Speaker 2: Yeah, I know, I'm shaking up. I'm excited. Thanks, Flat, 667 00:37:30,079 --> 00:37:32,480 that's really interesting. That's a great way to talk about this. 668 00:37:33,719 --> 00:37:34,000 Speaker 1: Cool. 669 00:37:34,360 --> 00:37:37,280 Speaker 4: Yeah, it's important to have a framework to formulate these 670 00:37:37,360 --> 00:37:43,159 kind of things. But yeah, you know, when I decided 671 00:37:43,199 --> 00:37:45,880 I want to be a programmer, they told me that 672 00:37:45,920 --> 00:37:49,079 you're going to work with computers, not with people. Biggest 673 00:37:49,119 --> 00:37:50,000 lie of the century. 674 00:37:50,039 --> 00:37:56,159 Speaker 2: Big lie totally turned out. People use the software and 675 00:37:56,199 --> 00:37:57,639 it ruins everything. 676 00:37:57,840 --> 00:37:59,840 Speaker 1: I know, if you just get rid of the people, 677 00:38:02,159 --> 00:38:03,000 chopped so much. 678 00:38:03,519 --> 00:38:07,199 Speaker 2: Yeah, you know, as long as nobody uses software, it 679 00:38:07,320 --> 00:38:08,000 works great. 680 00:38:08,320 --> 00:38:11,519 Speaker 1: I wonder why. That's why you have front end developers 681 00:38:11,559 --> 00:38:14,599 who like people and back end developers who don't like people. 682 00:38:15,519 --> 00:38:18,199 You know, people become DBAs because they just want to 683 00:38:18,239 --> 00:38:20,400 talk to the database. That's it. 684 00:38:20,480 --> 00:38:21,960 Speaker 2: But I do have to talk to people. I get 685 00:38:22,000 --> 00:38:26,119 to say no, no, no, you can't, no, you can't. 686 00:38:27,880 --> 00:38:31,519 I'm sorry, we're digressing. There's more to this story. I 687 00:38:31,519 --> 00:38:32,920 think you need to continue about it. 688 00:38:32,920 --> 00:38:35,880 Speaker 1: But you know, you open a Pandora's box though. If 689 00:38:36,280 --> 00:38:40,239 you know architecture for both the teams and the code 690 00:38:40,320 --> 00:38:44,199 has to work hand in hand. It's definitely Conway's law 691 00:38:44,199 --> 00:38:44,920 applies here. 692 00:38:45,280 --> 00:38:54,039 Speaker 4: Yeah, yeah, absolutely absolutely, And the two are interconnected. And 693 00:38:54,079 --> 00:38:57,400 that's what I love about that dimensional distance is that 694 00:38:57,440 --> 00:39:01,599 it reflects it. It reflects organizational desig even though you're 695 00:39:01,639 --> 00:39:02,800 looking just at the code. 696 00:39:03,079 --> 00:39:06,280 Speaker 1: So you're a consultant. You go into a company and 697 00:39:06,320 --> 00:39:12,519 they have some horrible monolithic thing, or maybe they've got 698 00:39:12,559 --> 00:39:17,119 micro services whatever, But you see the problems that you've 699 00:39:17,159 --> 00:39:24,039 outlined here, and how do you go about convincing them 700 00:39:24,800 --> 00:39:28,639 about this kind of stuff without sounding too academic? Right? 701 00:39:28,679 --> 00:39:32,199 I mean, this is pretty technical stuff you're getting into here, right, 702 00:39:32,519 --> 00:39:37,719 You've got formulas and stuff, and maybe you have some 703 00:39:37,760 --> 00:39:42,400 stories from your experiences dealing with customers and how they've 704 00:39:42,639 --> 00:39:43,440 worked around it. 705 00:39:43,599 --> 00:39:47,519 Speaker 4: Yeah. So the most common story is one of a 706 00:39:47,559 --> 00:39:51,400 company that wanted micro services and ended up with distributed monelith, 707 00:39:51,480 --> 00:39:54,760 and the hardest thing is to convince them to bring 708 00:39:54,840 --> 00:39:59,159 back everything into the same code base, to redesign it 709 00:39:59,320 --> 00:40:03,159 over time into a modular monelith, and then rebreak it 710 00:40:03,280 --> 00:40:04,360 into micro services. 711 00:40:04,920 --> 00:40:08,719 Speaker 2: Interesting. Yeah, that doesn't seem like the right path, but 712 00:40:08,800 --> 00:40:10,800 I can see why it would be right. 713 00:40:11,440 --> 00:40:14,920 Speaker 4: Yeah, because once you have it in the same code base, 714 00:40:15,199 --> 00:40:19,639 you have shorter distance, which means it's easier to change, 715 00:40:20,119 --> 00:40:21,679 to change things together. 716 00:40:21,480 --> 00:40:23,639 Speaker 1: If you need to. Productivity goes up. Yeah. 717 00:40:23,760 --> 00:40:27,920 Speaker 4: Now you re evaluate the boundaries of those services micro 718 00:40:28,000 --> 00:40:31,760 services that you want to build, and once they have 719 00:40:31,840 --> 00:40:35,199 that logical form of modules within the same model, if 720 00:40:35,599 --> 00:40:39,239 it's okay to be wrong, that's right, a mistake that 721 00:40:39,599 --> 00:40:40,880 is really easy to fix. 722 00:40:41,039 --> 00:40:43,480 Speaker 2: But you're also doing this very empirically. You know, if 723 00:40:43,480 --> 00:40:46,679 you assemble them, they'll gather some momentum and life will 724 00:40:46,679 --> 00:40:49,159 be easier for a while, but eventually you're going to 725 00:40:49,199 --> 00:40:51,960 have a production issue of some kind that sort of 726 00:40:52,000 --> 00:40:55,360 points to, here's a piece of code that's resonating and 727 00:40:55,400 --> 00:40:57,920 if it were separated, it would cause less residence. 728 00:40:59,519 --> 00:41:03,360 Speaker 4: That's true. Yeah, that's true, But there are different ways 729 00:41:03,440 --> 00:41:10,599 to There was a company I was working with. They 730 00:41:11,159 --> 00:41:13,840 had that code base which was monolithic, but it was 731 00:41:13,880 --> 00:41:19,639 still deployed as different services for that reason, not sually. 732 00:41:19,679 --> 00:41:22,519 For that reason, they needed different levels of scale for 733 00:41:22,559 --> 00:41:26,679 different components of that system. So the underlying code base 734 00:41:27,000 --> 00:41:31,480 is monolithic. Whatever there is change like new deployment, we 735 00:41:31,559 --> 00:41:37,119 already deploying all the services together like no exceptions, but 736 00:41:37,360 --> 00:41:42,760 still were able to gain the benefits of a lower 737 00:41:43,119 --> 00:41:48,840 cost of a design mistake and that advantage of kind 738 00:41:48,840 --> 00:41:54,440 of reducing the operational the cost of operational failure. 739 00:41:55,159 --> 00:41:58,320 Speaker 1: Give me a story of where you found difficult people 740 00:41:58,519 --> 00:42:01,039 who dug in their heels and said, you know, I 741 00:42:01,199 --> 00:42:05,760 separated out these micro services because I read such and 742 00:42:05,840 --> 00:42:09,679 such a book and you know this is sound architecture 743 00:42:09,679 --> 00:42:12,199 and you don't know what you're talking about, and you know, 744 00:42:12,280 --> 00:42:15,920 meanwhile it's really slow and brittle. I mean, how do 745 00:42:15,960 --> 00:42:17,119 you deal with people like that? 746 00:42:17,599 --> 00:42:20,920 Speaker 4: So usually when they call me, these people have already 747 00:42:21,039 --> 00:42:30,920 left the company. Ah really, well, maybe they were promoted 748 00:42:31,480 --> 00:42:32,960 so that they. 749 00:42:34,559 --> 00:42:38,239 Speaker 1: Yeah, Gilbert Principle failing upward and moved to management. 750 00:42:38,480 --> 00:42:38,920 Speaker 2: There you go. 751 00:42:40,039 --> 00:42:43,639 Speaker 1: Yeah, I see, but you you have obviously at some 752 00:42:43,800 --> 00:42:47,440 point experienced and pushback, right of course. Yeah. 753 00:42:47,480 --> 00:42:49,119 Speaker 2: But at the same time, they're not calling you because 754 00:42:49,159 --> 00:42:50,000 things are going well. 755 00:42:50,280 --> 00:42:50,519 Speaker 1: Yeah. 756 00:42:51,119 --> 00:42:53,440 Speaker 2: Yeah, they never called me for that. It's like, hey, 757 00:42:53,639 --> 00:42:55,239 I wanted to pay your fee and bring it in 758 00:42:55,280 --> 00:42:57,079 for a week just to show you how well everything's going. 759 00:42:57,800 --> 00:43:01,039 Speaker 1: I think about Robert Irvine and restaurants impossible. How he 760 00:43:01,079 --> 00:43:03,559 goes into these failing restaurants and they dig in their 761 00:43:03,559 --> 00:43:06,079 heels and says, my food is great, and it's like, yeah, 762 00:43:06,119 --> 00:43:08,360 I can tell your one customer loves it. 763 00:43:11,440 --> 00:43:14,440 Speaker 4: Well. You know what, if we're talking about pushbacks, then 764 00:43:14,599 --> 00:43:17,760 I'll bring back the topic of domain dreaming design because 765 00:43:17,920 --> 00:43:21,719 for some reason, the main driving design it's got this 766 00:43:21,960 --> 00:43:26,280 reputation of being too complex, with too much, too many 767 00:43:26,320 --> 00:43:29,079 patterns and if you apply them. 768 00:43:29,039 --> 00:43:31,639 Speaker 1: Driven because it makes your foot look big and it's 769 00:43:31,639 --> 00:43:33,440 a it's a pistol, you know. 770 00:43:33,760 --> 00:43:40,280 Speaker 4: Yeah. Now, once you face that kind of pushback, what 771 00:43:40,360 --> 00:43:44,519 I usually do is I started talking about the principles 772 00:43:44,719 --> 00:43:48,719 of domain dreaming design without mentioning domaindreamine design without mentioning 773 00:43:48,920 --> 00:43:53,880 concrete patterns like Okay, so we have this problem that 774 00:43:53,920 --> 00:43:57,800 we have to address. So that's the root cause of 775 00:43:57,840 --> 00:44:01,159 the issues you're facing. Now, maybe you want a brainstorm 776 00:44:01,199 --> 00:44:03,639 what we can do. And there was a guy that 777 00:44:03,760 --> 00:44:07,760 invented the aggregate pattern with a different name, but he 778 00:44:07,880 --> 00:44:10,119 was so happy, and I said, okay, cool, let's go 779 00:44:10,159 --> 00:44:11,880 on with it. Call it what a you wanted. 780 00:44:12,360 --> 00:44:14,880 Speaker 1: Yeah, yeah, yeah, Bob's pattern. 781 00:44:15,039 --> 00:44:17,559 Speaker 2: But yeah, you know it's people have their biases. So 782 00:44:17,559 --> 00:44:19,639 if you leave the words out but still do the 783 00:44:19,679 --> 00:44:24,039 work and get results. And maybe he retroduced the word later, 784 00:44:24,119 --> 00:44:26,760 but it's not even important. The goal was to get solved, 785 00:44:26,960 --> 00:44:30,079 so just find a way to get forward. The principles 786 00:44:30,079 --> 00:44:32,960 are still their useful principles for some reason. 787 00:44:33,039 --> 00:44:35,760 Speaker 4: I don't know why, but this model of balanced coupling 788 00:44:35,840 --> 00:44:38,039 is way easier for people to grasp and to start 789 00:44:38,119 --> 00:44:40,559 using them. Domain dum in design, Yeah, I mean always 790 00:44:40,559 --> 00:44:41,840 compared with do major in design. 791 00:44:42,119 --> 00:44:46,000 Speaker 1: I'm getting that. Yeah, I'm getting that. Four levels. That's 792 00:44:46,039 --> 00:44:46,800 all you need to know. 793 00:44:47,159 --> 00:44:51,000 Speaker 2: Yeah, just that conversation of sorting your problems into these 794 00:44:51,039 --> 00:44:53,880 different categories and then saying and then you have it 795 00:44:53,880 --> 00:44:56,519 approach strategy for each one. It's different. 796 00:44:57,960 --> 00:45:02,519 Speaker 4: Yeah, and if you look into pretty much almost all 797 00:45:02,719 --> 00:45:06,159 patterns from domain dreaming design, they have that balancing behind 798 00:45:06,159 --> 00:45:10,960 the scenes. If you have, for example, Eric Evans always 799 00:45:11,079 --> 00:45:14,360 says that not all of our system is going to 800 00:45:14,400 --> 00:45:17,599 be well designed. It means that supporting subdomains are not 801 00:45:17,679 --> 00:45:21,159 that important. It's okay to around some corners. What about 802 00:45:21,199 --> 00:45:25,039 supporting subdomains. They're not business critical, so they're not going 803 00:45:25,079 --> 00:45:28,079 to change that much, which means their volatility is going 804 00:45:28,119 --> 00:45:31,960 to be much lower than core subdomins. So again we're 805 00:45:32,000 --> 00:45:36,480 getting that balance. We can introduce some complexity because we 806 00:45:36,519 --> 00:45:41,880 have lower volatility, but when we're talking about high volatility 807 00:45:42,000 --> 00:45:46,679 of course subdomains, then yeah, we should keep things as 808 00:45:46,920 --> 00:45:50,039 well designed as possible. Sure we have those patterns for 809 00:45:50,239 --> 00:45:53,039 encapsulating models in bounded contexts, etc. 810 00:45:53,400 --> 00:45:57,440 Speaker 2: You're also learning to pick your fights right. You get 811 00:45:57,440 --> 00:46:00,360 people together that be architecturally absolutist in everything has to 812 00:46:00,360 --> 00:46:03,320 be built the same way, where by going through this 813 00:46:03,400 --> 00:46:07,519 coupling practice and figuring out what's actually going to be problematic, 814 00:46:07,760 --> 00:46:09,239 only fight for the ones that are going to have 815 00:46:09,280 --> 00:46:13,199 the biggest harm if they are done poorly. The edge 816 00:46:13,199 --> 00:46:15,480 cases can be a little can be weaker because the 817 00:46:15,519 --> 00:46:18,639 consequences are small. But where the consequences are big, then 818 00:46:18,679 --> 00:46:21,480 you can push harder and spend more time, even do 819 00:46:21,679 --> 00:46:24,960 spikes to evaluate how couple this is really going to be. 820 00:46:25,119 --> 00:46:28,320 What are the consequences of separating it? Like, it's worth 821 00:46:28,360 --> 00:46:29,719 spending time on that, just you don't have to do 822 00:46:29,719 --> 00:46:30,280 it for everything. 823 00:46:31,800 --> 00:46:36,719 Speaker 4: Yeah, and volatility, that dimension of changes or dimension of 824 00:46:36,760 --> 00:46:40,480 time helps a lot here because once you spot the 825 00:46:40,599 --> 00:46:43,800 high volatility. By the way, how do you evaluate volatility 826 00:46:44,440 --> 00:46:48,679 and different ways different models. I prefer the management design subdomains. 827 00:46:49,440 --> 00:46:53,000 And once you spot a high volatility, then yeah, you 828 00:46:53,079 --> 00:46:56,079 have a low hanging through there things that first. 829 00:46:56,320 --> 00:46:59,599 Speaker 2: Yeah, Well, and it also speaks to when we're going 830 00:46:59,639 --> 00:47:02,280 to sign a new piece of this app and we 831 00:47:02,360 --> 00:47:05,280 see high volatility. Now I certainly have a new opinion 832 00:47:05,320 --> 00:47:07,880 about where should it reside based on where what the 833 00:47:07,920 --> 00:47:10,880 coupling looks like. It's like, you know, at least initially, 834 00:47:10,920 --> 00:47:13,119 I think we should start this in this team where 835 00:47:13,159 --> 00:47:15,239 it's close to all the pieces it's going to touch. 836 00:47:15,840 --> 00:47:19,119 You know, if that changes, we can revise that but 837 00:47:19,239 --> 00:47:22,239 for the moment, especially when say the design is immature, 838 00:47:22,360 --> 00:47:26,079 it's a new area, Minimizing distance takes a lot of 839 00:47:26,159 --> 00:47:26,960 risk off the table. 840 00:47:27,480 --> 00:47:27,679 Speaker 1: Yeah. 841 00:47:27,719 --> 00:47:31,440 Speaker 4: Well, let's be honest here, it's not always possible. Sometimes 842 00:47:31,480 --> 00:47:37,920 when you minimize the distance, you are introducing accidental complexity, Right, 843 00:47:39,119 --> 00:47:42,760 So I always strive for at least logical boundaries within 844 00:47:42,800 --> 00:47:46,800 that monolith. Sure, and then we have that distance. It's 845 00:47:46,880 --> 00:47:51,760 going to be significantly lower compared to the initial distribute monelith, 846 00:47:51,840 --> 00:47:55,519 of course, but still we can talk about different distances 847 00:47:55,599 --> 00:47:58,679 within that code base, within that monelith. If we're looking 848 00:47:58,679 --> 00:48:01,719 at the same module, the same logical boundary, the distance 849 00:48:01,840 --> 00:48:06,159 is lower compared to different logical boundaries within it. 850 00:48:06,599 --> 00:48:08,599 Speaker 2: Yeah, I appreciate that. That's good. 851 00:48:08,719 --> 00:48:11,079 Speaker 1: Yeah, So is there anything else that you want to 852 00:48:11,119 --> 00:48:14,159 cover before we say goodbye? Any shout outs or anything 853 00:48:14,400 --> 00:48:15,079 shut outs? 854 00:48:15,800 --> 00:48:19,159 Speaker 4: Not surely. I just want to remind again that there 855 00:48:19,239 --> 00:48:26,719 is more to it. There are degrees for the three 856 00:48:27,480 --> 00:48:29,480 levels of integration strength. 857 00:48:30,039 --> 00:48:32,239 Speaker 1: Right, that's the one you said would take another hour 858 00:48:32,320 --> 00:48:32,920 to explain. 859 00:48:33,519 --> 00:48:38,360 Speaker 4: Yeah, they provide more detail and they also kind of 860 00:48:38,400 --> 00:48:41,639 help you to identify those specific cases, whether it's functional 861 00:48:41,639 --> 00:48:42,719 coupling or model coupling. 862 00:48:42,880 --> 00:48:48,800 Speaker 1: All right, well, Vlad Honenoff. His new book is Balancing 863 00:48:48,920 --> 00:48:53,719 Coupling and Software Design. Go check it out. It's a 864 00:48:53,719 --> 00:48:58,440 fascinating subject and we've already had our eyes open. And 865 00:48:58,840 --> 00:49:01,559 thank you Vlad for talking to us today. Thank you 866 00:49:01,639 --> 00:49:03,719 so much for having me bet all right, we'll talk 867 00:49:03,760 --> 00:49:07,239 to you, dear listener, next time on dot net rocks. 868 00:49:27,400 --> 00:49:30,320 Dot NetRocks is brought to you by Franklin's Net and 869 00:49:30,400 --> 00:49:34,320 produced by Pop Studios, a full service audio, video and 870 00:49:34,400 --> 00:49:38,679 post production facility located physically in New London, Connecticut, and 871 00:49:38,760 --> 00:49:43,400 of course in the cloud online at pwop dot com. 872 00:49:43,599 --> 00:49:45,719 Speaker 3: Visit our website at d O T N E t 873 00:49:45,960 --> 00:49:49,960 R O c k S dot com for RSS feeds, downloads, 874 00:49:50,119 --> 00:49:53,800 mobile apps, comments, and access to the full archives going 875 00:49:53,840 --> 00:49:57,199 back to show number one, recorded in September. 876 00:49:56,679 --> 00:49:59,199 Speaker 1: Two thousand and two. And make sure you check out 877 00:49:59,199 --> 00:50:02,360 our sponsors. They keep us in business. Now, go write 878 00:50:02,400 --> 00:50:04,199 some code. See you next time. 879 00:50:05,079 --> 00:50:06,559 Speaker 3: You got your middle. 880 00:50:06,400 --> 00:50:14,679 Speaker 1: Vands do the same. This is hard than my Texas