WEBVTT

1
00:00:01.080 --> 00:00:03.000
<v Speaker 1>How'd you like to listen to dot net rocks with

2
00:00:03.040 --> 00:00:07.879
<v Speaker 1>no ads? Easy? Become a patron for just five dollars

3
00:00:07.919 --> 00:00:10.800
<v Speaker 1>a month. You get access to a private RSS feed

4
00:00:10.839 --> 00:00:14.279
<v Speaker 1>where all the shows have no ads. Twenty dollars a month,

5
00:00:14.279 --> 00:00:16.920
<v Speaker 1>we'll get you that and a special dot net Rocks

6
00:00:16.960 --> 00:00:21.000
<v Speaker 1>patron mug. Sign up now at Patreon dot dot NetRocks

7
00:00:21.120 --> 00:00:36.359
<v Speaker 1>dot com. Hey, welcome back to dot net rocks. I'm

8
00:00:36.439 --> 00:00:39.320
<v Speaker 1>Carl Franklin and I'm Richard Campbell. We are here for

9
00:00:39.359 --> 00:00:41.119
<v Speaker 1>your dot net pleasure.

10
00:00:40.920 --> 00:00:42.719
<v Speaker 2>And any other pleasures you want. But you know, don't

11
00:00:42.759 --> 00:00:43.320
<v Speaker 2>get crazy.

12
00:00:43.479 --> 00:00:47.840
<v Speaker 1>No, I'm gonna limit it to dot net Okay, maybe

13
00:00:47.840 --> 00:00:50.159
<v Speaker 1>geek up pleasure, maybe a little science.

14
00:00:50.640 --> 00:00:53.119
<v Speaker 2>Yeah, I'm writing my indie year geek outs. Man, it's

15
00:00:53.560 --> 00:00:55.679
<v Speaker 2>a pile of work, but I am working on them.

16
00:00:55.679 --> 00:00:58.520
<v 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
<v Speaker 2>Yeah.

18
00:00:58.920 --> 00:01:01.399
<v Speaker 1>All right, Well let's get started with a little thing

19
00:01:01.439 --> 00:01:02.880
<v Speaker 1>we call better no a framework.

20
00:01:03.000 --> 00:01:12.120
<v Speaker 2>Awesome. All right.

21
00:01:12.159 --> 00:01:14.719
<v Speaker 1>So I went looking to see what's trending as far

22
00:01:14.760 --> 00:01:19.040
<v Speaker 1>as c sharp repositories on GitHub, and one that has

23
00:01:19.519 --> 00:01:22.439
<v Speaker 1>recently got a lot of activity or a lot of

24
00:01:22.799 --> 00:01:28.239
<v Speaker 1>coolness is Tom Hurst's t unit a modern, fast, and

25
00:01:28.400 --> 00:01:32.640
<v Speaker 1>flexible dot net testing framework. Now I have never used it.

26
00:01:33.239 --> 00:01:36.239
<v Speaker 1>I don't know anything about it except what it says

27
00:01:36.439 --> 00:01:40.200
<v Speaker 1>in the repo, which is that it's modern and fast.

28
00:01:40.879 --> 00:01:44.319
<v Speaker 1>T unit leverages source generators to locate and register your

29
00:01:44.359 --> 00:01:47.719
<v Speaker 1>test as opposed to reflection. Nice you'll have a slight

30
00:01:47.799 --> 00:01:51.120
<v Speaker 1>bump and build time, but a speedier runtime. T unit

31
00:01:51.239 --> 00:01:55.439
<v Speaker 1>also builds upon the newer Microsoft Testing platform that's Microsoft

32
00:01:55.480 --> 00:01:58.920
<v Speaker 1>Dot Testing dot Platform. Whereas most other frameworks you'll have

33
00:01:59.000 --> 00:02:03.560
<v Speaker 1>to you'll use, we'll use vs tests. The new platform

34
00:02:03.640 --> 00:02:06.120
<v Speaker 1>is reconstructed from the ground up to address pain points,

35
00:02:06.200 --> 00:02:07.719
<v Speaker 1>be more extensible, and be faster.

36
00:02:07.959 --> 00:02:10.159
<v Speaker 2>So this is just a play on x unit, but

37
00:02:10.400 --> 00:02:14.080
<v Speaker 2>x unit depends on reflection, and here they're using analyzers.

38
00:02:14.159 --> 00:02:15.319
<v Speaker 1>Yes, some sort.

39
00:02:15.159 --> 00:02:18.000
<v Speaker 2>Of modernized cunts. It's sort of modernized. Yeah, that's good idea.

40
00:02:18.080 --> 00:02:18.479
<v Speaker 2>I like that.

41
00:02:18.560 --> 00:02:20.879
<v Speaker 1>Yeah. So, like I said, it's trending and you might

42
00:02:20.919 --> 00:02:23.280
<v Speaker 1>want to check it out. That's when I got Richard,

43
00:02:23.319 --> 00:02:24.680
<v Speaker 1>who's talking to us today.

44
00:02:24.479 --> 00:02:27.680
<v Speaker 2>Grady comment to off a show nineteen sixteen. So that's

45
00:02:27.719 --> 00:02:31.319
<v Speaker 2>the one we did with Rendell back in September. They

46
00:02:31.360 --> 00:02:34.719
<v Speaker 2>show I called how Simple is as Simple as Possible?

47
00:02:35.159 --> 00:02:35.479
<v Speaker 3>Right.

48
00:02:36.360 --> 00:02:39.879
<v Speaker 2>I mean, Rendell's a smart person, right like, he just

49
00:02:39.919 --> 00:02:43.800
<v Speaker 2>thinks about development really coherently and very typical of you know,

50
00:02:43.879 --> 00:02:45.639
<v Speaker 2>how do we do the right thing the right way?

51
00:02:45.680 --> 00:02:47.919
<v Speaker 2>And it kicked off a ton of comments, lots of

52
00:02:47.919 --> 00:02:51.400
<v Speaker 2>people reacting to the show, and Cash Bonfil said this,

53
00:02:51.520 --> 00:02:53.439
<v Speaker 2>he said, this is a really interesting show and if

54
00:02:53.439 --> 00:02:56.280
<v Speaker 2>it's writing discussions we're currently having at work. We're a

55
00:02:56.319 --> 00:02:58.560
<v Speaker 2>team of eight developers all together, so hardly the size

56
00:02:58.599 --> 00:03:01.199
<v Speaker 2>of Netflix. That it's okay, man, you don't need to

57
00:03:01.199 --> 00:03:03.520
<v Speaker 2>be this side of Netflix. Now, that's set of problems.

58
00:03:03.800 --> 00:03:07.120
<v Speaker 2>We're building a lot of micro services because we can.

59
00:03:07.960 --> 00:03:11.080
<v Speaker 2>It's all good, but it comes to the price. One

60
00:03:11.120 --> 00:03:14.479
<v Speaker 2>example is that we are making everything asynchronous, that is,

61
00:03:14.479 --> 00:03:17.199
<v Speaker 2>with service bus integrations in the form of topics and queues.

62
00:03:17.280 --> 00:03:22.039
<v Speaker 2>Again all good on paper, because every time we have

63
00:03:22.159 --> 00:03:24.919
<v Speaker 2>AC and communications between our very small services, we have

64
00:03:25.000 --> 00:03:27.759
<v Speaker 2>situations where things don't work out as it was supposed to.

65
00:03:28.080 --> 00:03:31.400
<v Speaker 2>Messages end up on dlques and someone or something has

66
00:03:31.439 --> 00:03:34.240
<v Speaker 2>to monitor and compensate. All of a sudden, we start

67
00:03:34.240 --> 00:03:37.639
<v Speaker 2>building endpoints and handles on how I allow messages to

68
00:03:37.639 --> 00:03:40.240
<v Speaker 2>be fixed and rerun. So we're spending our precious time

69
00:03:40.280 --> 00:03:44.759
<v Speaker 2>creating things to compensate for architectural and infrastructure things instead

70
00:03:44.759 --> 00:03:49.560
<v Speaker 2>of actually building business value. My point is that on

71
00:03:49.599 --> 00:03:52.960
<v Speaker 2>an architectural drawing, a simple straight line might end up

72
00:03:52.960 --> 00:03:57.400
<v Speaker 2>being insanely complex. Another funny thing, we started using dapper

73
00:03:57.479 --> 00:04:02.439
<v Speaker 2>that's DAPR for the exact reasons that Mendel mentions. Eventually

74
00:04:02.479 --> 00:04:04.080
<v Speaker 2>we left it again and it turned out to have

75
00:04:04.120 --> 00:04:07.599
<v Speaker 2>to be a horrible developer experience. Dapper is another great

76
00:04:07.599 --> 00:04:09.759
<v Speaker 2>example of being a good idea from an architectural point

77
00:04:09.759 --> 00:04:12.280
<v Speaker 2>of view, but implementing it it was a nightmare. I'm

78
00:04:12.280 --> 00:04:13.960
<v Speaker 2>pretty sure it will improve in the future, but the

79
00:04:14.000 --> 00:04:16.680
<v Speaker 2>moment it's too mature from a developer's point of view.

80
00:04:16.759 --> 00:04:18.959
<v Speaker 2>Thanks again for the great show. I always feel like

81
00:04:19.120 --> 00:04:21.160
<v Speaker 2>having a biscuit and a cup of tea when you

82
00:04:21.240 --> 00:04:22.199
<v Speaker 2>have rent a lot.

83
00:04:22.199 --> 00:04:27.040
<v Speaker 1>Absolutely or some fish and chips and a stout more.

84
00:04:26.959 --> 00:04:29.720
<v Speaker 2>Like, and it's stout and some mushy peas for sure.

85
00:04:29.879 --> 00:04:30.800
<v Speaker 1>Yeah, you can keep this.

86
00:04:32.199 --> 00:04:34.120
<v Speaker 2>You know, it's interesting that you've gone down that path

87
00:04:34.120 --> 00:04:35.959
<v Speaker 2>and you're seeing the struggles around all of it. And

88
00:04:36.000 --> 00:04:39.439
<v Speaker 2>again it's like, because you can thing problem now is

89
00:04:39.439 --> 00:04:43.120
<v Speaker 2>that d architecting would be an interesting challenge, although it

90
00:04:43.120 --> 00:04:45.560
<v Speaker 2>shouldn't be that tough. You've already done the hard work

91
00:04:45.639 --> 00:04:48.079
<v Speaker 2>separating concerns. Now you want to put some of them

92
00:04:48.120 --> 00:04:51.600
<v Speaker 2>back together. But great to hear the experiments going on

93
00:04:51.720 --> 00:04:54.000
<v Speaker 2>and the challenges there. And you're a pretty big team.

94
00:04:54.040 --> 00:04:57.040
<v Speaker 2>I mean eight people is enough that that ability is split.

95
00:04:57.120 --> 00:04:59.800
<v Speaker 2>The work up's pretty cool. So COJH, thank you so

96
00:04:59.879 --> 00:05:01.680
<v Speaker 2>much for your comment, and a coffee of music code

97
00:05:01.720 --> 00:05:03.079
<v Speaker 2>by is on its way to you. And if you'd

98
00:05:03.120 --> 00:05:04.839
<v Speaker 2>like a copy of musiccode buy, I write a comment

99
00:05:04.879 --> 00:05:06.920
<v Speaker 2>on the website at dot NetRocks dot com or on

100
00:05:06.920 --> 00:05:08.920
<v Speaker 2>the Facebook, so we publish every show there, and if

101
00:05:08.920 --> 00:05:10.240
<v Speaker 2>you comment there and I read it on the show,

102
00:05:10.360 --> 00:05:11.800
<v Speaker 2>we'll send you a copy of music cope or.

103
00:05:11.720 --> 00:05:13.279
<v Speaker 1>If you feel like buying music to code but how

104
00:05:13.319 --> 00:05:15.800
<v Speaker 1>you can go to music tocode by dot net and

105
00:05:15.839 --> 00:05:18.680
<v Speaker 1>you can also follow us on ex Twitter. Of course

106
00:05:18.680 --> 00:05:20.399
<v Speaker 1>we've been there for years, but the cool kids are

107
00:05:20.399 --> 00:05:23.199
<v Speaker 1>hanging out. I'm mastaed on, I'm at Carl Franklin at

108
00:05:23.199 --> 00:05:25.000
<v Speaker 1>techeb dot social.

109
00:05:24.720 --> 00:05:26.800
<v Speaker 2>And I'm rich Campbell at masadon dot social.

110
00:05:27.040 --> 00:05:29.800
<v Speaker 1>Send us a two and uh, Richard. Before we get

111
00:05:29.800 --> 00:05:33.800
<v Speaker 1>started here, I realized that I didn't do my you know,

112
00:05:33.839 --> 00:05:36.000
<v Speaker 1>what happened in nineteen twenty three. This is show in

113
00:05:36.040 --> 00:05:38.199
<v Speaker 1>nineteen twenty three, and we've sort of vowed to do that.

114
00:05:38.439 --> 00:05:40.759
<v Speaker 2>Oh wow, yeah, what happened in nineteen twenty three.

115
00:05:41.000 --> 00:05:44.120
<v Speaker 1>Well, I'm going through the Wikipedia thing because my usual

116
00:05:44.160 --> 00:05:46.399
<v Speaker 1>page that we go to is down for some reason.

117
00:05:46.480 --> 00:05:50.519
<v Speaker 1>But let's just pick a few here. January fifth, Lithuani

118
00:05:50.600 --> 00:05:56.480
<v Speaker 1>begins the Clyppeeda revolt to annex the Clyipeda region. I

119
00:05:56.560 --> 00:05:57.040
<v Speaker 1>don't know.

120
00:05:57.639 --> 00:06:01.079
<v Speaker 2>Oh no, this is pre World War two, right, so

121
00:06:01.160 --> 00:06:03.680
<v Speaker 2>you're talking about the fall that's sort of the fallout

122
00:06:03.720 --> 00:06:05.399
<v Speaker 2>of the end of the Ottoman Empire, and it's a

123
00:06:06.240 --> 00:06:07.560
<v Speaker 2>it's craziness for sure.

124
00:06:07.639 --> 00:06:11.160
<v Speaker 1>March first, Eskom, the largest electricity producer in Africa, is

125
00:06:11.279 --> 00:06:15.160
<v Speaker 1>established in South Africa. March third, the first issue of

126
00:06:15.240 --> 00:06:17.199
<v Speaker 1>Time magazine is published.

127
00:06:17.319 --> 00:06:18.360
<v Speaker 2>Wow, that's cool.

128
00:06:18.519 --> 00:06:22.519
<v Speaker 1>March ninth, Vladimir Lenin suffers his third stroke, which renders

129
00:06:22.639 --> 00:06:26.519
<v Speaker 1>him bedridden and unable to speak. Consequently, he retires from

130
00:06:26.519 --> 00:06:31.199
<v Speaker 1>his position as chairman of the Soviet government. Let's see

131
00:06:31.519 --> 00:06:35.120
<v Speaker 1>British Prime Minister in May Bonar Law resigns due to

132
00:06:35.160 --> 00:06:38.079
<v Speaker 1>ill health. Okay, not all that oh, the Irish Civil

133
00:06:38.120 --> 00:06:43.160
<v Speaker 1>War ended May twenty fourth. Let's see what else I

134
00:06:43.160 --> 00:06:49.319
<v Speaker 1>can find here. July tenth, large hailstones killed twenty three

135
00:06:49.360 --> 00:06:51.439
<v Speaker 1>people in Rostov and the Soviet Union.

136
00:06:52.439 --> 00:06:55.879
<v Speaker 2>Oh my wow, those are big hailstones that they're killing people.

137
00:06:56.000 --> 00:07:01.319
<v Speaker 1>Yeah. July twentieth, Pancho Villa is assassinated a Hidalgo de

138
00:07:01.480 --> 00:07:09.240
<v Speaker 1>Palo Shiwawa. The Treaty of Lusine is signed, setting the

139
00:07:09.240 --> 00:07:12.279
<v Speaker 1>boundaries of modern Republic of Turkey in Switzerland.

140
00:07:12.360 --> 00:07:14.399
<v Speaker 2>Right, I would argue the big thing in twenty three

141
00:07:14.519 --> 00:07:16.720
<v Speaker 2>is the beer hall push is that's the beginning of

142
00:07:16.759 --> 00:07:20.639
<v Speaker 2>the first coup attempt by Hitler and his go court

143
00:07:20.759 --> 00:07:22.439
<v Speaker 2>hearts that failed.

144
00:07:22.519 --> 00:07:26.519
<v Speaker 1>Beer hall push, Beer hall pushed, Oh, pohar pusch. November eighth,

145
00:07:26.560 --> 00:07:29.240
<v Speaker 1>in Munich, Adolf Hitler leads the Nazis and an unsuccessful

146
00:07:29.240 --> 00:07:32.759
<v Speaker 1>attempt to overthrow the Bavarian government. Police and troops crushed

147
00:07:32.759 --> 00:07:34.800
<v Speaker 1>the attempt. The next day. Twenty people die as a

148
00:07:34.800 --> 00:07:40.439
<v Speaker 1>result of associated violence. And our friend Christian Vayer was

149
00:07:40.480 --> 00:07:41.160
<v Speaker 1>not born yet.

150
00:07:41.240 --> 00:07:44.000
<v Speaker 2>No, but it did, you know? And one would argue

151
00:07:44.160 --> 00:07:47.519
<v Speaker 2>the lack of consequences for the party at that time

152
00:07:47.879 --> 00:07:49.600
<v Speaker 2>set them up for what would happen later.

153
00:07:49.839 --> 00:07:51.240
<v Speaker 1>Yeah, I don't know why you brought that up. Is

154
00:07:51.279 --> 00:07:54.360
<v Speaker 1>there some sort of current event or something that you're

155
00:07:54.439 --> 00:07:54.959
<v Speaker 1>referring to.

156
00:07:55.120 --> 00:07:58.399
<v Speaker 2>I'm not referring to anything, not referring to a thing.

157
00:07:58.399 --> 00:07:59.399
<v Speaker 2>I don't know what you're talking about.

158
00:07:59.480 --> 00:08:02.519
<v 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
<v Speaker 1>let's bring in our guest. Vlad Honanoff is a software

160
00:08:07.040 --> 00:08:11.519
<v Speaker 1>architect with extensive industry experience, having held roles ranging from

161
00:08:11.560 --> 00:08:16.000
<v Speaker 1>webmaster to chief architect. He currently helps organizations make sense

162
00:08:16.000 --> 00:08:22.040
<v Speaker 1>of their business domains, untangled monoliths, and address complex architectural challenges.

163
00:08:22.759 --> 00:08:26.600
<v Speaker 1>In twenty twenty one, Vlad published Learning Domain Driven Design,

164
00:08:27.240 --> 00:08:30.639
<v Speaker 1>followed by his latest book, Balancing, Coupling and Software Design,

165
00:08:30.720 --> 00:08:35.399
<v Speaker 1>released earlier this month. As a public speaker, Vlad presents

166
00:08:35.399 --> 00:08:39.120
<v Speaker 1>at conferences worldwide on topics such as software architecture, demain

167
00:08:39.200 --> 00:08:42.919
<v Speaker 1>driven design, and distributed systems. And I believe this is

168
00:08:42.919 --> 00:08:45.240
<v Speaker 1>his first time on dot Netrock. So welcome, Flad.

169
00:08:45.320 --> 00:08:48.120
<v Speaker 4>Thank you so much. It's such an honor been here.

170
00:08:48.399 --> 00:08:49.559
<v Speaker 1>Oh you've heard of our show?

171
00:08:49.600 --> 00:08:52.519
<v Speaker 4>Then, yeah, bit, I started listening to you in two

172
00:08:52.559 --> 00:08:56.480
<v Speaker 4>thousand and six, I believe, Wow, and then use Yeah,

173
00:08:56.720 --> 00:09:00.960
<v Speaker 4>spoiled experience of listening to other podcasts for me because

174
00:09:01.360 --> 00:09:03.720
<v Speaker 4>that's the quality I expected from the rest of them.

175
00:09:03.919 --> 00:09:05.279
<v Speaker 1>Yeah, we get that a lot.

176
00:09:07.600 --> 00:09:10.639
<v Speaker 2>We've always taken the engineering side of the show very seriously. Yeah,

177
00:09:10.679 --> 00:09:15.279
<v Speaker 2>the content we have more fun, but quality audio is important.

178
00:09:19.759 --> 00:09:23.159
<v Speaker 1>Our content quality went way up when Richard joined the team,

179
00:09:23.279 --> 00:09:23.879
<v Speaker 1>that's for sure.

180
00:09:24.240 --> 00:09:26.159
<v Speaker 2>That's a long time ago. Man, it's coming up on

181
00:09:26.279 --> 00:09:28.879
<v Speaker 2>twenty years, like in a few months.

182
00:09:29.159 --> 00:09:34.399
<v Speaker 1>Yep, yep. And remember that serious lapse year that we

183
00:09:34.480 --> 00:09:37.600
<v Speaker 1>had before you came on, where we started doing comedy

184
00:09:37.840 --> 00:09:42.120
<v Speaker 1>and to two hour shows and what were we thinking.

185
00:09:41.919 --> 00:09:44.799
<v Speaker 2>Two and a half? Yeah, it was a variety showed.

186
00:09:44.840 --> 00:09:47.159
<v Speaker 2>I remember talking about it. It's like there's a vent diagram here.

187
00:09:47.200 --> 00:09:49.879
<v Speaker 2>There's a vent diagram of folks who want a technical

188
00:09:49.919 --> 00:09:54.279
<v Speaker 2>interview and folks who want like music and geeky humor

189
00:09:54.320 --> 00:09:56.519
<v Speaker 2>and all those things, and the intersection is small, but

190
00:09:56.559 --> 00:09:59.200
<v Speaker 2>the two big other circles are big. Why don't we

191
00:09:59.240 --> 00:10:02.080
<v Speaker 2>just pull them up? Part that's right, So Mondays was born,

192
00:10:02.279 --> 00:10:03.440
<v Speaker 2>both shows got bigger.

193
00:10:03.559 --> 00:10:07.679
<v Speaker 1>Okay, lad, enough about us. Let's talk about your experience

194
00:10:07.879 --> 00:10:12.399
<v Speaker 1>untangling monoliths and getting the balance of complexity right. What

195
00:10:12.440 --> 00:10:13.919
<v Speaker 1>are you talking about.

196
00:10:14.200 --> 00:10:19.279
<v Speaker 4>Yeah, so actually the comment that Richard read that experience

197
00:10:19.720 --> 00:10:23.159
<v Speaker 4>sounded kind of similar to what I went through a

198
00:10:23.159 --> 00:10:27.080
<v Speaker 4>few years ago. We also had a system that was working,

199
00:10:27.159 --> 00:10:31.000
<v Speaker 4>that was producing business value, but it was a monolith.

200
00:10:31.279 --> 00:10:34.000
<v Speaker 4>It was a monolithic code base. So we said, okay,

201
00:10:34.120 --> 00:10:37.120
<v Speaker 4>let's make it better by breaking it down into micro

202
00:10:37.240 --> 00:10:41.639
<v Speaker 4>services or in other words, let's decouple things. Right, So

203
00:10:41.759 --> 00:10:46.519
<v Speaker 4>we introduced tons of services that we call the micro services,

204
00:10:46.720 --> 00:10:51.200
<v Speaker 4>of course, with asynchronous integration between them, and from that

205
00:10:51.440 --> 00:10:57.480
<v Speaker 4>point on, it was impossible to evolve that system. It

206
00:10:57.519 --> 00:11:01.000
<v Speaker 4>was impossible to change it because suddenly we had to

207
00:11:01.039 --> 00:11:05.320
<v Speaker 4>modify tons of those services or I don't want to

208
00:11:05.360 --> 00:11:09.159
<v Speaker 4>say microservices because they have nothing to do with micro services.

209
00:11:09.559 --> 00:11:11.279
<v Speaker 2>Yeah, I don't know how. I mean, how do you

210
00:11:11.320 --> 00:11:13.440
<v Speaker 2>call it. It's only a micro service if you put

211
00:11:13.440 --> 00:11:15.279
<v Speaker 2>that in the comments, like, I don't know the difference.

212
00:11:15.679 --> 00:11:17.039
<v Speaker 2>It's just a service. Yeah.

213
00:11:17.159 --> 00:11:20.559
<v Speaker 1>The thing is they're completely separated, right. But I guess

214
00:11:20.559 --> 00:11:23.080
<v Speaker 1>what we're talking about, and what we've been talking about

215
00:11:23.080 --> 00:11:26.279
<v Speaker 1>the complexity aspect of it is when you want to

216
00:11:26.360 --> 00:11:29.279
<v Speaker 1>implement a feature, you have to touch so many different

217
00:11:29.279 --> 00:11:33.279
<v Speaker 1>places to make sure that it is still going to

218
00:11:33.320 --> 00:11:33.960
<v Speaker 1>be robust.

219
00:11:35.159 --> 00:11:39.000
<v Speaker 4>Yeah. Yeah, and again it started with that decoupling effort

220
00:11:39.000 --> 00:11:42.440
<v Speaker 4>by breaking things apart. But what we did is we

221
00:11:42.519 --> 00:11:48.720
<v Speaker 4>increased coupling. Essentially, Now everything was coupled. And if previously

222
00:11:48.759 --> 00:11:51.080
<v Speaker 4>we had to modify one code base, now we had

223
00:11:51.080 --> 00:11:55.120
<v Speaker 4>to modify multiple projects and then synchronize changes, synchronize their

224
00:11:55.200 --> 00:11:59.440
<v Speaker 4>life cycles. Tons of fun. And yeah, it was a

225
00:11:59.480 --> 00:12:01.039
<v Speaker 4>failure atostrophic failure.

226
00:12:01.240 --> 00:12:03.519
<v Speaker 2>I mean the other the alternative there is that you

227
00:12:03.600 --> 00:12:06.639
<v Speaker 2>run multiple versions of each service. I've gone down that

228
00:12:06.759 --> 00:12:09.320
<v Speaker 2>path where it's like, hey, we're you know, if we

229
00:12:09.440 --> 00:12:11.720
<v Speaker 2>change this API, we're going to affect these other things.

230
00:12:11.799 --> 00:12:13.559
<v Speaker 2>It's like, okay, well let's keep this old one running,

231
00:12:13.559 --> 00:12:16.320
<v Speaker 2>but we'll run a new one as well, and let's.

232
00:12:16.000 --> 00:12:19.080
<v Speaker 1>Have a service that returns the current versions of all

233
00:12:19.120 --> 00:12:20.960
<v Speaker 1>the services that you should be running.

234
00:12:22.840 --> 00:12:26.120
<v Speaker 2>That wasn't a problem at all. We were fine, Everything

235
00:12:26.279 --> 00:12:29.799
<v Speaker 2>was fine. That's fine.

236
00:12:31.519 --> 00:12:34.240
<v Speaker 1>If you had a merge conflict in that service, the

237
00:12:34.360 --> 00:12:39.919
<v Speaker 1>version service service service version service, oh my god, nightmare.

238
00:12:40.240 --> 00:12:42.679
<v Speaker 2>But you know, I do feel like you're trading plumbing

239
00:12:42.759 --> 00:12:49.840
<v Speaker 2>issues off for monolith issues. Nothing comes for free here. Yeah, absolutely,

240
00:12:50.000 --> 00:12:52.159
<v Speaker 2>where's the balance in this? Because I know it's in

241
00:12:52.200 --> 00:12:52.639
<v Speaker 2>the title.

242
00:12:54.639 --> 00:12:59.799
<v Speaker 4>Yeah. So, following that experience, that catastrophic failure of that project,

243
00:13:00.279 --> 00:13:02.799
<v Speaker 4>I wanted to figure out what microservices are, how to

244
00:13:02.919 --> 00:13:07.480
<v Speaker 4>design their boundaries properly. And I found the answers I

245
00:13:07.519 --> 00:13:12.279
<v Speaker 4>was looking for in a book that was published in

246
00:13:12.440 --> 00:13:17.200
<v Speaker 4>early seventies. It's called Structure Design, and the answers were

247
00:13:17.320 --> 00:13:22.600
<v Speaker 4>in chapter on coupling, and in it I found some

248
00:13:22.679 --> 00:13:27.159
<v Speaker 4>interesting things that our industry knew in the past, but

249
00:13:27.200 --> 00:13:31.480
<v Speaker 4>we kind of have forgotten it now. So what I did,

250
00:13:31.840 --> 00:13:35.919
<v Speaker 4>what I wanted to do, is to adapt those forgotten

251
00:13:36.240 --> 00:13:42.000
<v Speaker 4>insights to our current technological world, the technologies we are

252
00:13:42.039 --> 00:13:46.399
<v Speaker 4>working on today, and that's how the balanced coupling model

253
00:13:46.519 --> 00:13:51.879
<v Speaker 4>was born. The idea here is that whenever you have

254
00:13:52.000 --> 00:13:56.360
<v Speaker 4>two components, and these components can be anything, whether these

255
00:13:56.399 --> 00:14:01.279
<v Speaker 4>are services, microservices, or two classes interacting with each other,

256
00:14:01.840 --> 00:14:05.480
<v Speaker 4>in order to work together, they have to exchange some

257
00:14:05.600 --> 00:14:08.919
<v Speaker 4>knowledge about each other, like what is your public interface,

258
00:14:09.720 --> 00:14:12.919
<v Speaker 4>what is the format of the data I have to pass?

259
00:14:13.879 --> 00:14:17.480
<v Speaker 4>Or maybe what are the assumptions I have to make

260
00:14:17.639 --> 00:14:21.919
<v Speaker 4>about your behavior? So let's call that knowledge. The second

261
00:14:21.919 --> 00:14:25.840
<v Speaker 4>aspect is the distance between them. Now, if we're talking

262
00:14:25.879 --> 00:14:30.679
<v Speaker 4>about two classes, then their source code is located close

263
00:14:30.720 --> 00:14:32.840
<v Speaker 4>to each other, those are probably the same files and

264
00:14:32.879 --> 00:14:33.720
<v Speaker 4>the same directory.

265
00:14:33.960 --> 00:14:36.320
<v Speaker 2>Sure. On the other hand, in the same language.

266
00:14:36.399 --> 00:14:36.679
<v Speaker 1>Yeah.

267
00:14:37.000 --> 00:14:39.799
<v Speaker 4>On the other hand, if we're looking at two micro services,

268
00:14:39.960 --> 00:14:45.120
<v Speaker 4>then we have much greater distance between those source codes. Right,

269
00:14:46.159 --> 00:14:51.799
<v Speaker 4>greater distance. Now, why we should be interested in it

270
00:14:51.840 --> 00:14:56.799
<v Speaker 4>is the greater the distance, the more collaboration and more

271
00:14:56.879 --> 00:15:00.600
<v Speaker 4>communication effort you need to implement a change that affects

272
00:15:00.679 --> 00:15:03.279
<v Speaker 4>both of them. So I'm going back to that example

273
00:15:03.279 --> 00:15:09.759
<v Speaker 4>from the comment. Once you decompose a monelith into micro services,

274
00:15:10.080 --> 00:15:14.320
<v Speaker 4>you're increasing the distance between those parts of the system.

275
00:15:14.399 --> 00:15:18.679
<v Speaker 4>Those components. Now they're residing in different micro services, so

276
00:15:18.720 --> 00:15:22.440
<v Speaker 4>we have greater distance. And when we look at these

277
00:15:22.679 --> 00:15:25.720
<v Speaker 4>two the mansions, on the one hand, we have the

278
00:15:26.080 --> 00:15:29.039
<v Speaker 4>knowledge that they have to share, and on the other

279
00:15:29.080 --> 00:15:33.360
<v Speaker 4>hand we have distance between them. Then we can deduce

280
00:15:33.440 --> 00:15:38.960
<v Speaker 4>some interesting insights by evaluating their extreme extreme combinations. For example,

281
00:15:39.000 --> 00:15:42.039
<v Speaker 4>if you have a lot of knowledge change across a

282
00:15:42.039 --> 00:15:44.879
<v Speaker 4>big distance, well, that's not going to be foul.

283
00:15:44.960 --> 00:15:45.120
<v Speaker 1>Right.

284
00:15:45.840 --> 00:15:49.120
<v Speaker 4>The more knowledge they share, the more cascading changes are

285
00:15:49.120 --> 00:15:53.120
<v Speaker 4>going to follow, Like the more reasons to change together

286
00:15:53.320 --> 00:15:59.440
<v Speaker 4>those components have. Now, when you couple that with the

287
00:15:59.480 --> 00:16:03.600
<v Speaker 4>increased distance. Then we have lots of skating changes, and

288
00:16:03.639 --> 00:16:06.559
<v Speaker 4>we have lots of effort needed to implement each of

289
00:16:06.600 --> 00:16:11.559
<v Speaker 4>those changes. Bottom line, not fun. Or we can look

290
00:16:11.600 --> 00:16:16.399
<v Speaker 4>at the opposite of that. What if we have two

291
00:16:16.440 --> 00:16:20.399
<v Speaker 4>components that are not sharing much knowledge, maybe they are

292
00:16:20.440 --> 00:16:23.840
<v Speaker 4>not even integrated. They're just located close to each other,

293
00:16:24.320 --> 00:16:28.440
<v Speaker 4>so we have low knowledge and low distance between them.

294
00:16:28.960 --> 00:16:32.480
<v Speaker 4>Now what we have is components that are not truly

295
00:16:32.559 --> 00:16:37.000
<v Speaker 4>related to each other, located in the same code, based

296
00:16:37.039 --> 00:16:39.639
<v Speaker 4>the same names, paid the same package module, however you

297
00:16:39.720 --> 00:16:44.039
<v Speaker 4>call it. That's what we usually call the classic modelife

298
00:16:44.480 --> 00:16:46.279
<v Speaker 4>or a big ball of mod You have a bunch

299
00:16:46.279 --> 00:16:48.879
<v Speaker 4>of stuff that is not related, but it's close to

300
00:16:48.879 --> 00:16:51.919
<v Speaker 4>each other, and the next time you have to modify something,

301
00:16:51.960 --> 00:16:55.039
<v Speaker 4>you have to make your ways through those unrelated things

302
00:16:55.080 --> 00:16:58.039
<v Speaker 4>to find what is that class or module that you

303
00:16:58.080 --> 00:17:03.240
<v Speaker 4>do have to modify. And both these relationships high distance,

304
00:17:03.320 --> 00:17:07.559
<v Speaker 4>high strength, high knowledge. I call that dimension of knowledge

305
00:17:07.599 --> 00:17:11.799
<v Speaker 4>sharing integration strength. So once you have high integration strength

306
00:17:11.880 --> 00:17:16.319
<v Speaker 4>and high distance, you have complexity on the overarching system.

307
00:17:16.559 --> 00:17:20.000
<v Speaker 4>If you have low knowledge and low distance, then suddenly

308
00:17:20.039 --> 00:17:24.279
<v Speaker 4>you have another type of complexity. You have cognitive load

309
00:17:24.559 --> 00:17:30.119
<v Speaker 4>that results from you having to struggle to understand what's

310
00:17:30.119 --> 00:17:33.200
<v Speaker 4>going on, what are those things that are implemented in

311
00:17:33.240 --> 00:17:36.519
<v Speaker 4>the same module, and what do you have to modify

312
00:17:36.720 --> 00:17:40.440
<v Speaker 4>when a new business requirement comes in. So those are

313
00:17:40.480 --> 00:17:45.400
<v Speaker 4>two types of complexities. Now, what if we reverse these relationships.

314
00:17:45.480 --> 00:17:50.920
<v Speaker 4>What if we will look at low integration strength, which

315
00:17:50.960 --> 00:17:56.759
<v Speaker 4>means low amount of knowledge shared across a big distance. Well,

316
00:17:57.079 --> 00:18:03.200
<v Speaker 4>big distance means that now we still have to to

317
00:18:03.319 --> 00:18:06.880
<v Speaker 4>invest high effort in implementing cascating changes. On the other hand,

318
00:18:07.359 --> 00:18:10.400
<v Speaker 4>we have that low integgression strength, So there we are

319
00:18:10.440 --> 00:18:15.000
<v Speaker 4>minimizing the chances of those cascading chances a changes happening.

320
00:18:16.480 --> 00:18:20.519
<v Speaker 4>And that relationship is usually what we call a loose coupling.

321
00:18:20.519 --> 00:18:23.119
<v Speaker 2>Right, and it's what happens most of the time, right

322
00:18:23.160 --> 00:18:25.240
<v Speaker 2>when you're calling in the third party APIs and things

323
00:18:25.279 --> 00:18:27.920
<v Speaker 2>like that. They're all loosely coupled because they are low

324
00:18:27.960 --> 00:18:31.400
<v Speaker 2>distance with low levels of integration. Right, hopefully for long

325
00:18:31.400 --> 00:18:34.559
<v Speaker 2>distance with low levels of integration, they're not inside your perimeter.

326
00:18:35.000 --> 00:18:38.240
<v Speaker 2>They have skate context. Yeah, you know, you've got to

327
00:18:38.240 --> 00:18:40.640
<v Speaker 2>carry your own state like you're not counting on anything,

328
00:18:40.759 --> 00:18:41.920
<v Speaker 2>You're they're external to you.

329
00:18:42.000 --> 00:18:44.000
<v Speaker 1>Effect ask a question, get an answer.

330
00:18:44.720 --> 00:18:48.039
<v Speaker 4>Yeah, And the opposite of that is going to be high.

331
00:18:48.039 --> 00:18:51.279
<v Speaker 4>I'm out of an aggression strength high amount of knowledge over.

332
00:18:51.519 --> 00:18:53.200
<v Speaker 2>Small distance right now local.

333
00:18:53.440 --> 00:18:53.680
<v Speaker 1>Yeah.

334
00:18:53.960 --> 00:18:57.319
<v Speaker 4>Now, we do want to minimize the knowledge we are

335
00:18:57.359 --> 00:19:01.039
<v Speaker 4>sharing across the boundaries of components, of course, but it's

336
00:19:01.079 --> 00:19:04.119
<v Speaker 4>not always possible. Sometimes we do have to share knowledge

337
00:19:04.279 --> 00:19:07.240
<v Speaker 4>because maybe we have two components that are implementing closely

338
00:19:07.279 --> 00:19:10.680
<v Speaker 4>related business functionalities, so we have to share knowledge.

339
00:19:10.720 --> 00:19:14.079
<v Speaker 1>Yeah, maybe they're both injecting the same services, that kind

340
00:19:14.119 --> 00:19:14.400
<v Speaker 1>of thing.

341
00:19:14.519 --> 00:19:18.799
<v Speaker 4>Yeah, Yeah, there are different levels of evaluating that knowledge.

342
00:19:19.240 --> 00:19:22.079
<v Speaker 4>So let's assume we're on that higher end of the scale,

343
00:19:23.599 --> 00:19:26.559
<v Speaker 4>and there is no way for us to reduce the

344
00:19:26.599 --> 00:19:30.400
<v Speaker 4>amount of knowledge in that case by putting them closer

345
00:19:30.480 --> 00:19:33.079
<v Speaker 4>to each other. We know, we acknowledge that. Yeah, they

346
00:19:33.119 --> 00:19:37.440
<v Speaker 4>will change together, but we are preparing ourselves by minimizing reasy.

347
00:19:37.680 --> 00:19:40.519
<v Speaker 2>Easy to do that. Yeah, So if I mean I

348
00:19:40.559 --> 00:19:44.079
<v Speaker 2>see the rule emerging here, then this, Hey, these two

349
00:19:44.119 --> 00:19:46.720
<v Speaker 2>things are to be closely tied together, we should make

350
00:19:46.720 --> 00:19:50.759
<v Speaker 2>sure they're close. Yeah, yeah, yeah, and that. In nineties

351
00:19:51.559 --> 00:19:57.839
<v Speaker 2>a model was formulated called connaisance, and in that model,

352
00:19:58.519 --> 00:20:03.279
<v Speaker 2>its author Miller Page Jones use that word proximity to

353
00:20:03.359 --> 00:20:06.880
<v Speaker 2>say that things should be in close proximity to each other.

354
00:20:07.200 --> 00:20:10.480
<v Speaker 2>I prefer the world distance, which is the opposite of

355
00:20:10.480 --> 00:20:12.079
<v Speaker 2>proximity for other reasons.

356
00:20:12.839 --> 00:20:13.160
<v Speaker 1>Yeah.

357
00:20:13.279 --> 00:20:14.599
<v Speaker 4>Yeah, but that's so.

358
00:20:15.119 --> 00:20:18.400
<v Speaker 1>The basic idea is that go ahead and have your

359
00:20:18.480 --> 00:20:21.519
<v Speaker 1>micro services or your services or whatever, but those that

360
00:20:21.640 --> 00:20:24.759
<v Speaker 1>share knowledge should be closer together, and the ones that

361
00:20:24.799 --> 00:20:29.039
<v Speaker 1>should be have more distance, should have less dependency on

362
00:20:29.839 --> 00:20:32.160
<v Speaker 1>each other. Yeah, share share less.

363
00:20:31.960 --> 00:20:35.359
<v Speaker 4>Knowledge, Yeah exactly, Yeah, and that makes sense. The next

364
00:20:35.400 --> 00:20:38.240
<v Speaker 4>question is how do you evaluate that knowledge?

365
00:20:39.039 --> 00:20:39.279
<v Speaker 1>Right?

366
00:20:39.480 --> 00:20:43.799
<v Speaker 4>Yeah, And that's the complicated part, because how do you

367
00:20:43.880 --> 00:20:48.240
<v Speaker 4>measure knowledge? Like what is the management measurement unit for knowledge? Yeah?

368
00:20:48.480 --> 00:20:50.119
<v Speaker 2>But how much do I need to know?

369
00:20:50.440 --> 00:20:55.680
<v Speaker 4>Yeah? Yeah, And for that I adapted that model from

370
00:20:55.960 --> 00:21:00.680
<v Speaker 4>seventy's book Structure Design to differentiate between a number of

371
00:21:01.400 --> 00:21:05.519
<v Speaker 4>types of knowledge knowledges. Now, once we're dealing with types,

372
00:21:05.680 --> 00:21:08.240
<v Speaker 4>we don't have to measure the exact amount of knowledge,

373
00:21:08.279 --> 00:21:13.079
<v Speaker 4>because once we're going higher on that scale of types,

374
00:21:13.359 --> 00:21:17.200
<v Speaker 4>the amount is going to be significantly higher anyway. So

375
00:21:18.720 --> 00:21:22.680
<v Speaker 4>overall there are four levels, four basic levels. One of

376
00:21:22.720 --> 00:21:25.720
<v Speaker 4>them is, let's say if we are implementing two components.

377
00:21:27.279 --> 00:21:31.920
<v Speaker 4>Let's say Richard, you're implementing micro service, which means when

378
00:21:32.240 --> 00:21:35.599
<v Speaker 4>I'm integrating with it, I should be using its public interface,

379
00:21:36.079 --> 00:21:37.920
<v Speaker 4>but I'm not going to do it. Instead, I will

380
00:21:37.960 --> 00:21:41.200
<v Speaker 4>reach out to your database directly and take whatever the

381
00:21:41.240 --> 00:21:41.839
<v Speaker 4>data I need.

382
00:21:43.000 --> 00:21:46.119
<v Speaker 1>Yeah, it.

383
00:21:47.720 --> 00:21:50.279
<v Speaker 2>Memories make the batman stop.

384
00:21:50.920 --> 00:21:53.519
<v Speaker 4>Yeah. So what I'm doing here is I'm introducing a

385
00:21:53.519 --> 00:21:55.799
<v Speaker 4>dependency on your implementation detail.

386
00:21:55.599 --> 00:21:58.039
<v Speaker 2>Right, and I can break you very easily by modifying

387
00:21:58.079 --> 00:21:59.440
<v Speaker 2>my database for my next version.

388
00:21:59.559 --> 00:21:59.960
<v Speaker 4>Exactly.

389
00:22:00.000 --> 00:22:03.039
<v Speaker 2>I not know that I did exactly. Yeah.

390
00:22:03.200 --> 00:22:07.359
<v Speaker 4>That's why let's call this level intrusive coupling. I am

391
00:22:07.440 --> 00:22:08.920
<v Speaker 4>intruding your boundaries.

392
00:22:09.400 --> 00:22:11.160
<v Speaker 2>I mean in a way that doesn't bother me all

393
00:22:11.160 --> 00:22:14.200
<v Speaker 2>that much, because you're I can break you. You can't

394
00:22:14.240 --> 00:22:14.960
<v Speaker 2>really break me.

395
00:22:15.279 --> 00:22:16.599
<v Speaker 4>It depends what I'm doing there.

396
00:22:17.039 --> 00:22:19.160
<v Speaker 2>It's kind of like the beer puts. Yeah, I mean

397
00:22:19.160 --> 00:22:21.599
<v Speaker 2>you can't. You're right, you can by inserting weird data

398
00:22:21.640 --> 00:22:25.359
<v Speaker 2>into my database. Yeah, that you know, can break my

399
00:22:25.480 --> 00:22:28.640
<v Speaker 2>code expecting certain consistency in the database, which is my fault.

400
00:22:28.640 --> 00:22:30.519
<v Speaker 2>I should have had put parameters on my database that

401
00:22:30.519 --> 00:22:31.440
<v Speaker 2>don't allow you to do that.

402
00:22:31.880 --> 00:22:35.480
<v Speaker 4>Yeah. So that's intrusive coupling. That's the highest level of

403
00:22:35.680 --> 00:22:38.400
<v Speaker 4>knowledge sharing. We're assuming that this is the knowledge you

404
00:22:38.440 --> 00:22:38.720
<v Speaker 4>shared it.

405
00:22:38.960 --> 00:22:42.079
<v Speaker 2>Yeah, but this seems like I don't do this, this

406
00:22:42.160 --> 00:22:42.559
<v Speaker 2>is bad.

407
00:22:42.640 --> 00:22:43.400
<v Speaker 1>Yeah, this is only.

408
00:22:43.319 --> 00:22:46.160
<v Speaker 4>Level one depends let's get back to it.

409
00:22:46.559 --> 00:22:47.799
<v Speaker 2>Okay, let's get back to it.

410
00:22:48.720 --> 00:22:51.920
<v Speaker 4>The next level is functional coupling, and here we have

411
00:22:52.119 --> 00:22:56.200
<v Speaker 4>two components that are implementing closely related functionalities. Maybe they're

412
00:22:56.200 --> 00:22:59.240
<v Speaker 4>implementing closely related use cases, but the bottom line is

413
00:22:59.519 --> 00:23:03.839
<v Speaker 4>the wheel have to change together when the business requirements.

414
00:23:03.359 --> 00:23:05.000
<v Speaker 2>Change, so they resonate together.

415
00:23:05.200 --> 00:23:05.440
<v Speaker 1>Yeah.

416
00:23:05.920 --> 00:23:10.240
<v Speaker 4>Yeah, So they have to share lots of knowledge because

417
00:23:10.279 --> 00:23:14.079
<v Speaker 4>once that functional dependency is there, we have to make

418
00:23:14.920 --> 00:23:18.759
<v Speaker 4>an assumption that there will be business rules that both

419
00:23:18.759 --> 00:23:23.279
<v Speaker 4>of them will have to follow. So that's the functional coupling. Now,

420
00:23:23.359 --> 00:23:27.680
<v Speaker 4>there are different degrees of functional coupling. Let's not get

421
00:23:27.759 --> 00:23:30.680
<v Speaker 4>into it because we'll need another hour just for that

422
00:23:30.799 --> 00:23:31.440
<v Speaker 4>sure topic.

423
00:23:31.640 --> 00:23:33.119
<v Speaker 2>But is it one of the arguments that you should

424
00:23:33.119 --> 00:23:35.160
<v Speaker 2>have been the same service.

425
00:23:35.559 --> 00:23:37.599
<v Speaker 4>Yes, but let's get back to it later.

426
00:23:37.960 --> 00:23:39.279
<v Speaker 2>Okay, I'm jumping head.

427
00:23:39.599 --> 00:23:40.279
<v Speaker 1>Yeah.

428
00:23:41.559 --> 00:23:45.559
<v Speaker 4>The third level is model coupling. This one means that

429
00:23:45.599 --> 00:23:48.119
<v Speaker 4>we have two components that share the knowledge of the

430
00:23:48.200 --> 00:23:53.160
<v Speaker 4>model of the business domain that are using Now, every

431
00:23:53.160 --> 00:23:54.880
<v Speaker 4>time I talk about this level, I have to wear

432
00:23:54.920 --> 00:23:59.279
<v Speaker 4>my dominion and design guide CAP because it's heavily influenced

433
00:23:59.319 --> 00:24:02.599
<v Speaker 4>by the Clean Dream design. And the thing is, when

434
00:24:02.599 --> 00:24:04.519
<v Speaker 4>we are implementing a system, of course, we are not

435
00:24:04.680 --> 00:24:08.480
<v Speaker 4>coding all the knowledge available about that business domain, but

436
00:24:08.559 --> 00:24:11.599
<v Speaker 4>we have to pick whatever we think is relevant to

437
00:24:11.720 --> 00:24:14.279
<v Speaker 4>solve the problem that we want to solve for the

438
00:24:14.400 --> 00:24:18.440
<v Speaker 4>users of our systems. Right, So we're crafting a model

439
00:24:18.480 --> 00:24:23.680
<v Speaker 4>of a business domain now with new requirements, with new

440
00:24:23.799 --> 00:24:29.359
<v Speaker 4>insights into business domain. That model should evolve over time.

441
00:24:30.200 --> 00:24:34.279
<v Speaker 4>Once we're sharing that knowledge, we kind of reducing our

442
00:24:34.319 --> 00:24:38.200
<v Speaker 4>ability to evolve that model, so it can be problematic

443
00:24:38.240 --> 00:24:43.160
<v Speaker 4>in some cases. That's the third level of integration strengths.

444
00:24:43.880 --> 00:24:47.920
<v Speaker 2>But models don't change as often as functionality does.

445
00:24:48.079 --> 00:24:50.559
<v Speaker 4>Well, it depends what kind of system you're working on.

446
00:24:51.079 --> 00:24:52.920
<v Speaker 4>Let's say that you are working for a star up

447
00:24:52.960 --> 00:24:58.279
<v Speaker 4>company and at the first stages there's so much uncertainty

448
00:24:58.440 --> 00:25:02.559
<v Speaker 4>about twitching. Yeah, everything about how we're going to solve

449
00:25:02.559 --> 00:25:05.720
<v Speaker 4>the problem for our customers, and even the problem itself

450
00:25:05.720 --> 00:25:09.400
<v Speaker 4>can change. Yeah, So that's model coupling. The third level, Now,

451
00:25:09.559 --> 00:25:13.680
<v Speaker 4>the lowest one is what I call contract coupling. And

452
00:25:13.920 --> 00:25:19.440
<v Speaker 4>here we have an integration specific contract that was formulated

453
00:25:20.119 --> 00:25:24.079
<v Speaker 4>for integration purposes only. Its goal is to encapsulate all

454
00:25:24.119 --> 00:25:29.279
<v Speaker 4>the knowledge about implementation details, all knowledge about functional requirements,

455
00:25:29.400 --> 00:25:32.279
<v Speaker 4>and of course all the knowledge about the model of

456
00:25:32.319 --> 00:25:36.680
<v Speaker 4>the business domain that's being used to implement the component.

457
00:25:38.680 --> 00:25:41.720
<v Speaker 4>What we want to expose is a much more stable

458
00:25:41.759 --> 00:25:45.880
<v Speaker 4>interface that is not going to be changed after each

459
00:25:45.960 --> 00:25:49.640
<v Speaker 4>new business requirement that comes in something way more stable.

460
00:25:49.759 --> 00:25:53.799
<v Speaker 2>This is that public API inter face mindset exactly.

461
00:25:53.880 --> 00:25:58.000
<v Speaker 4>Yeah, yeah, yeah. And if I will bring back my

462
00:25:58.119 --> 00:26:01.119
<v Speaker 4>domain gveing design cap again, then have anti corruption layer,

463
00:26:01.200 --> 00:26:06.480
<v Speaker 4>we have open host service. These parents. What they're doing

464
00:26:06.559 --> 00:26:13.680
<v Speaker 4>essentially is introducing an integration contract for those purposes. So

465
00:26:13.720 --> 00:26:17.680
<v Speaker 4>we have four types of interfaces, contract, model, functional, and interesting.

466
00:26:18.720 --> 00:26:22.880
<v Speaker 4>These are four types of knowledges, and we cannot put

467
00:26:22.920 --> 00:26:27.240
<v Speaker 4>a number to evaluate the amount of knowledge we are sharing.

468
00:26:27.519 --> 00:26:31.920
<v Speaker 4>But knowing these four types already helps us to evaluate

469
00:26:32.000 --> 00:26:32.640
<v Speaker 4>where we are.

470
00:26:33.119 --> 00:26:37.359
<v Speaker 2>Yeah, at least get people in the categories, right, yeah.

471
00:26:37.880 --> 00:26:40.599
<v Speaker 4>Now, as I mentioned in the book, there are degrees

472
00:26:40.839 --> 00:26:44.839
<v Speaker 4>for functional model and contract coupling, so that you can

473
00:26:44.880 --> 00:26:48.680
<v Speaker 4>compare to interfaces of the same type. These degrees are

474
00:26:48.720 --> 00:26:51.759
<v Speaker 4>based on the conations model. It has lots of levels,

475
00:26:51.799 --> 00:26:54.400
<v Speaker 4>so it will require another hour.

476
00:26:54.680 --> 00:26:58.440
<v Speaker 2>Just that topic, by the book is a good number, right,

477
00:26:58.519 --> 00:27:01.559
<v Speaker 2>Like you could probably discribe, especially at the functional level,

478
00:27:01.559 --> 00:27:03.799
<v Speaker 2>you could discriminate a bunch of options in there. But

479
00:27:04.440 --> 00:27:07.039
<v Speaker 2>I'm with you. Four you can feel good about. It's like,

480
00:27:07.519 --> 00:27:10.279
<v Speaker 2>I'm not just thinking that all coupling is bad. I'm

481
00:27:10.279 --> 00:27:14.240
<v Speaker 2>recognizing some is necessary, but some has larger consequences than others.

482
00:27:14.519 --> 00:27:18.039
<v Speaker 4>Yeah. Now, let's talk about the dimension of space, the

483
00:27:18.079 --> 00:27:21.440
<v Speaker 4>distance between those components. So on the one hand, we

484
00:27:21.519 --> 00:27:26.079
<v Speaker 4>have the code base where the components are implemented. If

485
00:27:26.119 --> 00:27:28.799
<v Speaker 4>the files are in the same directory, the distance is low,

486
00:27:29.039 --> 00:27:31.160
<v Speaker 4>or maybe in the same file even the distance is

487
00:27:31.200 --> 00:27:36.799
<v Speaker 4>minimized versus let's say, different project, different repositories. But there

488
00:27:36.880 --> 00:27:41.400
<v Speaker 4>is another aspect to that dimension, and it's organizational. First.

489
00:27:41.519 --> 00:27:45.759
<v Speaker 4>Let's say that we have two micro services, and we

490
00:27:45.799 --> 00:27:49.640
<v Speaker 4>have two cases. In the first one, both micro services

491
00:27:49.720 --> 00:27:53.319
<v Speaker 4>are implemented by the same team. In the second one,

492
00:27:53.480 --> 00:27:57.559
<v Speaker 4>we have two micro services implemented by different teams. In

493
00:27:57.599 --> 00:28:01.880
<v Speaker 4>the second case, we'll need much higher collaboration and communication

494
00:28:01.960 --> 00:28:05.599
<v Speaker 4>effort to implement a change. So it also affects the distance.

495
00:28:05.720 --> 00:28:07.599
<v Speaker 2>I mean, I argue it's the same amount of communication

496
00:28:07.640 --> 00:28:10.880
<v Speaker 2>it's just one is easy because you're in the same team,

497
00:28:10.960 --> 00:28:13.880
<v Speaker 2>and one needs more structure because you're not the same.

498
00:28:14.160 --> 00:28:18.920
<v Speaker 4>Yeah, exactly, So we have that organizational aspect that increases

499
00:28:19.119 --> 00:28:22.400
<v Speaker 4>the distance. And also again going back to the comment

500
00:28:22.480 --> 00:28:25.160
<v Speaker 4>that you read in the beginning of the show, Let's

501
00:28:25.160 --> 00:28:30.240
<v Speaker 4>say we have two components that are imp implementing synchrons

502
00:28:30.319 --> 00:28:34.359
<v Speaker 4>communication between them, and the second case with asynchronous communication

503
00:28:34.480 --> 00:28:38.400
<v Speaker 4>between them. Right now, in the case of asynchronus communication,

504
00:28:39.880 --> 00:28:44.480
<v Speaker 4>we have a bigger distance between them, bigger virtual distance

505
00:28:44.480 --> 00:28:48.640
<v Speaker 4>between them. Let's say that way because we have a

506
00:28:51.000 --> 00:28:53.720
<v Speaker 4>lower life cycle dependency between them.

507
00:28:53.799 --> 00:28:54.079
<v Speaker 2>Right.

508
00:28:54.319 --> 00:28:58.799
<v Speaker 4>If we have low distance, let's say components implemented in

509
00:28:58.839 --> 00:29:01.880
<v Speaker 4>the same monolith, then we have that life cycle dependency

510
00:29:01.880 --> 00:29:07.359
<v Speaker 4>between those services. Everything within that MAELD have to be implemented, tested,

511
00:29:07.400 --> 00:29:08.440
<v Speaker 4>and deployed.

512
00:29:08.240 --> 00:29:10.599
<v Speaker 2>Simultaneously, functionally, but coupled.

513
00:29:11.039 --> 00:29:11.319
<v Speaker 1>Yeah.

514
00:29:11.440 --> 00:29:15.160
<v Speaker 4>Once we were introducing that asynchronous communication between them, we

515
00:29:15.200 --> 00:29:17.359
<v Speaker 4>are kind of extending the distance, right.

516
00:29:17.440 --> 00:29:17.759
<v Speaker 1>Yeah.

517
00:29:17.839 --> 00:29:20.759
<v Speaker 4>Now, let's go back to the topic of ineggression strength.

518
00:29:21.119 --> 00:29:24.119
<v Speaker 4>Let's say that we have two components share lots of

519
00:29:24.160 --> 00:29:31.200
<v Speaker 4>knowledge between them. Let's say they have interessive coupling between them.

520
00:29:31.359 --> 00:29:36.359
<v Speaker 4>The bad one M and let's assume we have high

521
00:29:36.359 --> 00:29:40.920
<v Speaker 4>distance between them. Is this design necessarily bad?

522
00:29:41.359 --> 00:29:44.160
<v Speaker 2>I mean, it's got a lot of consequences to it. Yeah, right,

523
00:29:44.240 --> 00:29:47.480
<v Speaker 2>and you need a lot of communicating to move you're

524
00:29:47.799 --> 00:29:51.599
<v Speaker 2>often going to have if you've got a good testing harness,

525
00:29:51.640 --> 00:29:54.079
<v Speaker 2>it's going to fail a lot because you're moving things

526
00:29:54.079 --> 00:29:55.319
<v Speaker 2>that affect the other composers.

527
00:29:55.440 --> 00:29:59.000
<v Speaker 1>I would ask, why did you choose this model? Oh,

528
00:29:59.039 --> 00:30:00.400
<v Speaker 1>why do you need that?

529
00:30:00.400 --> 00:30:03.680
<v Speaker 4>That's a great question, So I'll provide you more information

530
00:30:03.720 --> 00:30:06.440
<v Speaker 4>about the context. So here's the thing. I work on

531
00:30:06.480 --> 00:30:11.319
<v Speaker 4>a system that integrates with a legacy system that is there.

532
00:30:12.440 --> 00:30:15.519
<v Speaker 4>This is not going to change ever. Nobody wants to

533
00:30:15.519 --> 00:30:18.759
<v Speaker 4>touch it, so there's no one I can ask to

534
00:30:18.799 --> 00:30:22.079
<v Speaker 4>add new interface to it so that I can work with.

535
00:30:22.200 --> 00:30:23.359
<v Speaker 2>You're not going to get any changes.

536
00:30:23.480 --> 00:30:25.799
<v Speaker 1>Got to go directly to the database, that's what you're saying.

537
00:30:25.920 --> 00:30:28.759
<v Speaker 4>Yeah, so I will do it. But I made that

538
00:30:28.799 --> 00:30:32.480
<v Speaker 4>assumption that that legacy system is not going to change,

539
00:30:32.599 --> 00:30:35.880
<v Speaker 4>right right, Okay, And that's the third dimension of coupling volatility.

540
00:30:36.480 --> 00:30:38.720
<v Speaker 1>Hey, I think this feels like a good place to

541
00:30:38.759 --> 00:30:40.920
<v Speaker 1>take a break, So hold that thought. Flag will come

542
00:30:41.000 --> 00:30:44.559
<v Speaker 1>right back after these very important messages don't go away.

543
00:30:44.599 --> 00:30:47.279
<v Speaker 1>Did you know that you can work with AWS directly

544
00:30:47.319 --> 00:30:53.279
<v Speaker 1>from your ID. AWS provides toolkits for visual studio, visual studio, code,

545
00:30:53.559 --> 00:30:57.640
<v Speaker 1>and jet brains rider. Learn more at AWS dot Amazon

546
00:30:57.720 --> 00:31:03.920
<v Speaker 1>dot com, slash net slash tools, and we're back. It's

547
00:31:03.920 --> 00:31:07.839
<v Speaker 1>dot net rocks. I'm Carl Franklin, that's Richard Hey Campbell,

548
00:31:08.000 --> 00:31:17.359
<v Speaker 1>and we're talking to Vlatkonanoff about you know, decoupling, coupled, balancing, decoupling,

549
00:31:17.400 --> 00:31:18.519
<v Speaker 1>I think is what we're calling it.

550
00:31:18.599 --> 00:31:20.880
<v Speaker 2>Yeah, balancing coupling.

551
00:31:20.960 --> 00:31:23.160
<v Speaker 1>Yeah, balancing coupling or dec degree.

552
00:31:23.200 --> 00:31:26.319
<v Speaker 2>So you just hit a third dimension there, the volatility

553
00:31:26.880 --> 00:31:30.400
<v Speaker 2>versus the distance, which is not necessarily a physical distance.

554
00:31:30.440 --> 00:31:34.279
<v Speaker 2>It's also are the teams separated or are they on

555
00:31:34.400 --> 00:31:37.519
<v Speaker 2>disparate teams? Might be security boundaries. There's a bunch of

556
00:31:37.559 --> 00:31:40.960
<v Speaker 2>different ways with great separation. And then the level of

557
00:31:41.880 --> 00:31:45.880
<v Speaker 2>interaction or the coupling within the code, how tightly tied

558
00:31:45.880 --> 00:31:50.519
<v Speaker 2>together they are, Yeah, alas sharing, so yeah, they manage

559
00:31:50.559 --> 00:31:54.240
<v Speaker 2>knowledge sharing and the bund scenario you painted there where

560
00:31:54.240 --> 00:31:57.519
<v Speaker 2>it's like, Okay, I'm doing some intrusive coupling on it

561
00:31:58.400 --> 00:32:01.279
<v Speaker 2>in my new app against its existing app, which is

562
00:32:01.440 --> 00:32:04.839
<v Speaker 2>relatively nearby. We're working in the same context, but its

563
00:32:04.920 --> 00:32:07.680
<v Speaker 2>volatility is very low, as in, I'm one of the

564
00:32:07.680 --> 00:32:10.200
<v Speaker 2>reasons I'm doing this intrusive behavior is because I cannot

565
00:32:10.279 --> 00:32:13.839
<v Speaker 2>change the other phase. So that doesn't seem to me

566
00:32:13.920 --> 00:32:17.400
<v Speaker 2>like the lowest thing. It seems like the only solution circumstance.

567
00:32:17.599 --> 00:32:21.720
<v Speaker 4>Yeah, and that brings us to the title of that

568
00:32:21.799 --> 00:32:25.720
<v Speaker 4>model balanced coupling. Once we have those three dimensions, once

569
00:32:25.720 --> 00:32:28.920
<v Speaker 4>we can evaluate them, we can say, okay, so we

570
00:32:29.000 --> 00:32:31.519
<v Speaker 4>have in aggression strength and we have distance, and we

571
00:32:31.680 --> 00:32:34.680
<v Speaker 4>have to be inversely proportional to each other. Okay, okay,

572
00:32:34.839 --> 00:32:37.559
<v Speaker 4>once one of them gets higher, the second one should

573
00:32:37.599 --> 00:32:41.200
<v Speaker 4>get lower. We can even find some middle ground. We

574
00:32:41.240 --> 00:32:45.680
<v Speaker 4>have middle amount of medium amount of knowledge, then medium

575
00:32:45.720 --> 00:32:51.759
<v Speaker 4>distance is okay too. But sometimes we're needed. We can

576
00:32:51.799 --> 00:32:56.160
<v Speaker 4>be a bit more pragmatic by introducing that third dimension

577
00:32:56.200 --> 00:33:01.440
<v Speaker 4>of volatility. And if components are not expected to change,

578
00:33:02.039 --> 00:33:05.359
<v Speaker 4>those components that are sharing the knowledge, then it can

579
00:33:05.400 --> 00:33:09.680
<v Speaker 4>be okay to allow them to share high amounts of

580
00:33:09.759 --> 00:33:11.519
<v Speaker 4>knowledge across big distances.

581
00:33:12.039 --> 00:33:14.240
<v Speaker 2>Right. Yeah, and well, and again you get into that

582
00:33:14.240 --> 00:33:16.319
<v Speaker 2>motion of hey, we're finding a lot of coupling between this.

583
00:33:16.519 --> 00:33:18.720
<v Speaker 2>Maybe we need to get this into the same team,

584
00:33:19.079 --> 00:33:21.400
<v Speaker 2>like a lawful lot of complexity would end if we

585
00:33:21.440 --> 00:33:24.400
<v Speaker 2>move that team member on that other team over with

586
00:33:24.559 --> 00:33:27.920
<v Speaker 2>us while this work is going on, and then communication

587
00:33:28.000 --> 00:33:31.240
<v Speaker 2>becomes easier. We can get through this period and decide

588
00:33:31.240 --> 00:33:36.160
<v Speaker 2>what happens from there, as opposed to, Hey, this is

589
00:33:36.559 --> 00:33:39.640
<v Speaker 2>complicated and it's distant, and we can't do anything about

590
00:33:39.640 --> 00:33:41.640
<v Speaker 2>that part, so let's minimize the volatility.

591
00:33:42.680 --> 00:33:45.920
<v Speaker 4>Yeah, And that's a very interesting comment because in the

592
00:33:45.960 --> 00:33:50.319
<v Speaker 4>book I'm talking about software design. However, we had a

593
00:33:50.359 --> 00:33:53.559
<v Speaker 4>conversation with a friend of mine, a Sonya and Tanzem

594
00:33:54.440 --> 00:33:59.920
<v Speaker 4>about the organizational design, and turns out we can use

595
00:34:01.319 --> 00:34:04.200
<v Speaker 4>the same model to evaluate the design of the organization.

596
00:34:04.400 --> 00:34:07.680
<v Speaker 4>Like if you have people in the same team who

597
00:34:07.720 --> 00:34:11.840
<v Speaker 4>are working on underlated things, which means they're not sharing

598
00:34:11.880 --> 00:34:14.480
<v Speaker 4>much knowledge between them, right, why do we need them

599
00:34:14.639 --> 00:34:15.400
<v Speaker 4>in one team?

600
00:34:15.800 --> 00:34:17.760
<v Speaker 2>Why? Yeah? Why are in the same team?

601
00:34:17.840 --> 00:34:18.079
<v Speaker 1>Yeah?

602
00:34:18.559 --> 00:34:21.719
<v Speaker 2>And the opposite you do you talk about Conway's law,

603
00:34:21.800 --> 00:34:26.599
<v Speaker 2>this idea that the team architecture also tends to dictate

604
00:34:26.599 --> 00:34:29.239
<v Speaker 2>the software architecture effectively, like if you if you have

605
00:34:29.400 --> 00:34:31.800
<v Speaker 2>three teams, you're going to make a three pass parser. Yeah,

606
00:34:32.519 --> 00:34:35.119
<v Speaker 2>that's just how it's going to happen, and now you're

607
00:34:35.159 --> 00:34:38.440
<v Speaker 2>talking about, Hey, as we get to the best architecture

608
00:34:38.480 --> 00:34:41.000
<v Speaker 2>on this, we could start shaping the team structure so

609
00:34:41.039 --> 00:34:42.679
<v Speaker 2>that Tonway's law doesn't fight us.

610
00:34:43.559 --> 00:34:43.800
<v Speaker 1>Yeah.

611
00:34:43.840 --> 00:34:45.079
<v Speaker 4>Absolutely, I think.

612
00:34:45.000 --> 00:34:48.280
<v Speaker 2>That's really interesting. And you've described a scenario now where

613
00:34:48.519 --> 00:34:50.880
<v Speaker 2>you might want to add a team member or even

614
00:34:50.960 --> 00:34:55.480
<v Speaker 2>separate a team. Both scenarios are reasonable, which is probably

615
00:34:55.519 --> 00:34:57.800
<v Speaker 2>a fairly good case. Then it's like, in both cases

616
00:34:57.800 --> 00:35:00.280
<v Speaker 2>you can see why you would change the organization to

617
00:35:00.360 --> 00:35:01.679
<v Speaker 2>reflect that intended art.

618
00:35:01.719 --> 00:35:05.000
<v Speaker 1>First we fix the architecture, then we fix the team architecture.

619
00:35:05.199 --> 00:35:06.760
<v Speaker 2>Perhaps, Yeah, I mean I think there's going to be

620
00:35:06.760 --> 00:35:09.800
<v Speaker 2>an oscillation back and forth, Like we don't always see

621
00:35:09.840 --> 00:35:11.679
<v Speaker 2>that these two things are going to end up coupled,

622
00:35:11.800 --> 00:35:16.079
<v Speaker 2>right as that as they requirements e merge and you

623
00:35:16.119 --> 00:35:18.239
<v Speaker 2>start seeing this is more and more and more coupled,

624
00:35:18.280 --> 00:35:21.559
<v Speaker 2>you might have as anario where it's like, yeah, okay,

625
00:35:21.599 --> 00:35:25.079
<v Speaker 2>we should probably bring these things together, but this participant

626
00:35:25.119 --> 00:35:28.159
<v Speaker 2>can't necessarily join that team in easily. Should we change

627
00:35:28.199 --> 00:35:30.719
<v Speaker 2>the team member into somebody you know, switch who's going

628
00:35:30.800 --> 00:35:32.760
<v Speaker 2>to work on that into someone in that other team,

629
00:35:33.159 --> 00:35:36.039
<v Speaker 2>because it'll make all of these other things easier, Like, yeah,

630
00:35:36.360 --> 00:35:38.840
<v Speaker 2>that's an overhead too to change team members like that,

631
00:35:39.239 --> 00:35:41.800
<v Speaker 2>but it might be less expensive than continuing in the

632
00:35:41.800 --> 00:35:43.239
<v Speaker 2>current the current layout.

633
00:35:43.480 --> 00:35:47.960
<v Speaker 4>Yeah, And as they say, organizational design always wins, right,

634
00:35:48.880 --> 00:35:55.599
<v Speaker 4>So we need that that way of evaluating the type

635
00:35:55.639 --> 00:35:58.679
<v Speaker 4>of knowledge that is being shared, whether it's across technical

636
00:35:58.760 --> 00:36:01.599
<v Speaker 4>components or across teams or team members.

637
00:36:01.719 --> 00:36:05.000
<v Speaker 1>Yeah, it's easier to change code than people.

638
00:36:05.079 --> 00:36:07.519
<v Speaker 2>But sometimes it's more efficient to change the people if

639
00:36:07.519 --> 00:36:09.920
<v Speaker 2>you can, Yeah, if you can. Like what I like

640
00:36:10.039 --> 00:36:13.960
<v Speaker 2>is we've created a reason to have that conversation. Yes, Like,

641
00:36:14.039 --> 00:36:16.639
<v Speaker 2>when I think in terms of balance company and balancing

642
00:36:16.679 --> 00:36:20.840
<v Speaker 2>these three numbers, one of the options suddenly becomes do

643
00:36:20.920 --> 00:36:23.920
<v Speaker 2>we change the team to compensate with this problem? Is

644
00:36:23.960 --> 00:36:26.239
<v Speaker 2>that even a possibility, because sometimes that'd be a very

645
00:36:26.239 --> 00:36:28.679
<v Speaker 2>easy solve, Like that person's always wanted to be on

646
00:36:28.719 --> 00:36:30.199
<v Speaker 2>that team, and now we have a good reason to

647
00:36:30.199 --> 00:36:34.280
<v Speaker 2>put them there, at least introducing that factor, like the

648
00:36:34.360 --> 00:36:35.920
<v Speaker 2>idea that we're going to use conways a lot in

649
00:36:36.000 --> 00:36:38.239
<v Speaker 2>our favor, and we're going to shuffle the team to

650
00:36:38.320 --> 00:36:41.800
<v Speaker 2>increase the quality of software. That's slick, man, that's good thinking.

651
00:36:42.119 --> 00:36:44.639
<v Speaker 1>It's been my experience, Richard, maybe years two and laid

652
00:36:44.719 --> 00:36:48.400
<v Speaker 1>for that matter, that it's easier to add people to

653
00:36:48.480 --> 00:36:52.559
<v Speaker 1>a team than to remove them, sure enough from a team,

654
00:36:53.000 --> 00:36:54.760
<v Speaker 1>and people don't like being removed.

655
00:36:55.599 --> 00:36:58.800
<v Speaker 2>I find depends on the person. But also like you

656
00:36:58.800 --> 00:37:01.079
<v Speaker 2>can work into more independent you don't need to be here.

657
00:37:01.320 --> 00:37:03.199
<v Speaker 1>Yeah, there's another team we want you to be on

658
00:37:03.239 --> 00:37:05.360
<v Speaker 1>because it'd be more effective there, and that kind of thing.

659
00:37:05.559 --> 00:37:09.239
<v Speaker 2>Yeah, this is the personality thing. But I just liked

660
00:37:09.239 --> 00:37:10.599
<v Speaker 2>that you could put it on the table now in

661
00:37:10.639 --> 00:37:14.440
<v Speaker 2>a coherent way. It's not political. I'm not after that

662
00:37:14.519 --> 00:37:17.159
<v Speaker 2>person or anything like that. I see an issue in

663
00:37:17.199 --> 00:37:22.039
<v Speaker 2>our architecture that is going to lead to consequences, and

664
00:37:22.119 --> 00:37:24.239
<v Speaker 2>maybe a change of team would mitigate that.

665
00:37:24.920 --> 00:37:25.400
<v Speaker 1>Interesting.

666
00:37:25.599 --> 00:37:30.000
<v Speaker 2>Yeah, I know, I'm shaking up. I'm excited. Thanks, Flat,

667
00:37:30.079 --> 00:37:32.480
<v Speaker 2>that's really interesting. That's a great way to talk about this.

668
00:37:33.719 --> 00:37:34.000
<v Speaker 1>Cool.

669
00:37:34.360 --> 00:37:37.280
<v Speaker 4>Yeah, it's important to have a framework to formulate these

670
00:37:37.360 --> 00:37:43.159
<v Speaker 4>kind of things. But yeah, you know, when I decided

671
00:37:43.199 --> 00:37:45.880
<v Speaker 4>I want to be a programmer, they told me that

672
00:37:45.920 --> 00:37:49.079
<v Speaker 4>you're going to work with computers, not with people. Biggest

673
00:37:49.119 --> 00:37:50.000
<v Speaker 4>lie of the century.

674
00:37:50.039 --> 00:37:56.159
<v Speaker 2>Big lie totally turned out. People use the software and

675
00:37:56.199 --> 00:37:57.639
<v Speaker 2>it ruins everything.

676
00:37:57.840 --> 00:37:59.840
<v Speaker 1>I know, if you just get rid of the people,

677
00:38:02.159 --> 00:38:03.000
<v Speaker 1>chopped so much.

678
00:38:03.519 --> 00:38:07.199
<v Speaker 2>Yeah, you know, as long as nobody uses software, it

679
00:38:07.320 --> 00:38:08.000
<v Speaker 2>works great.

680
00:38:08.320 --> 00:38:11.519
<v Speaker 1>I wonder why. That's why you have front end developers

681
00:38:11.559 --> 00:38:14.599
<v Speaker 1>who like people and back end developers who don't like people.

682
00:38:15.519 --> 00:38:18.199
<v Speaker 1>You know, people become DBAs because they just want to

683
00:38:18.239 --> 00:38:20.400
<v Speaker 1>talk to the database. That's it.

684
00:38:20.480 --> 00:38:21.960
<v Speaker 2>But I do have to talk to people. I get

685
00:38:22.000 --> 00:38:26.119
<v Speaker 2>to say no, no, no, you can't, no, you can't.

686
00:38:27.880 --> 00:38:31.519
<v Speaker 2>I'm sorry, we're digressing. There's more to this story. I

687
00:38:31.519 --> 00:38:32.920
<v Speaker 2>think you need to continue about it.

688
00:38:32.920 --> 00:38:35.880
<v Speaker 1>But you know, you open a Pandora's box though. If

689
00:38:36.280 --> 00:38:40.239
<v Speaker 1>you know architecture for both the teams and the code

690
00:38:40.320 --> 00:38:44.199
<v Speaker 1>has to work hand in hand. It's definitely Conway's law

691
00:38:44.199 --> 00:38:44.920
<v Speaker 1>applies here.

692
00:38:45.280 --> 00:38:54.039
<v Speaker 4>Yeah, yeah, absolutely absolutely, And the two are interconnected. And

693
00:38:54.079 --> 00:38:57.400
<v Speaker 4>that's what I love about that dimensional distance is that

694
00:38:57.440 --> 00:39:01.599
<v Speaker 4>it reflects it. It reflects organizational desig even though you're

695
00:39:01.639 --> 00:39:02.800
<v Speaker 4>looking just at the code.

696
00:39:03.079 --> 00:39:06.280
<v Speaker 1>So you're a consultant. You go into a company and

697
00:39:06.320 --> 00:39:12.519
<v Speaker 1>they have some horrible monolithic thing, or maybe they've got

698
00:39:12.559 --> 00:39:17.119
<v Speaker 1>micro services whatever, But you see the problems that you've

699
00:39:17.159 --> 00:39:24.039
<v Speaker 1>outlined here, and how do you go about convincing them

700
00:39:24.800 --> 00:39:28.639
<v Speaker 1>about this kind of stuff without sounding too academic? Right?

701
00:39:28.679 --> 00:39:32.199
<v Speaker 1>I mean, this is pretty technical stuff you're getting into here, right,

702
00:39:32.519 --> 00:39:37.719
<v Speaker 1>You've got formulas and stuff, and maybe you have some

703
00:39:37.760 --> 00:39:42.400
<v Speaker 1>stories from your experiences dealing with customers and how they've

704
00:39:42.639 --> 00:39:43.440
<v Speaker 1>worked around it.

705
00:39:43.599 --> 00:39:47.519
<v Speaker 4>Yeah. So the most common story is one of a

706
00:39:47.559 --> 00:39:51.400
<v Speaker 4>company that wanted micro services and ended up with distributed monelith,

707
00:39:51.480 --> 00:39:54.760
<v Speaker 4>and the hardest thing is to convince them to bring

708
00:39:54.840 --> 00:39:59.159
<v Speaker 4>back everything into the same code base, to redesign it

709
00:39:59.320 --> 00:40:03.159
<v Speaker 4>over time into a modular monelith, and then rebreak it

710
00:40:03.280 --> 00:40:04.360
<v Speaker 4>into micro services.

711
00:40:04.920 --> 00:40:08.719
<v Speaker 2>Interesting. Yeah, that doesn't seem like the right path, but

712
00:40:08.800 --> 00:40:10.800
<v Speaker 2>I can see why it would be right.

713
00:40:11.440 --> 00:40:14.920
<v Speaker 4>Yeah, because once you have it in the same code base,

714
00:40:15.199 --> 00:40:19.639
<v Speaker 4>you have shorter distance, which means it's easier to change,

715
00:40:20.119 --> 00:40:21.679
<v Speaker 4>to change things together.

716
00:40:21.480 --> 00:40:23.639
<v Speaker 1>If you need to. Productivity goes up. Yeah.

717
00:40:23.760 --> 00:40:27.920
<v Speaker 4>Now you re evaluate the boundaries of those services micro

718
00:40:28.000 --> 00:40:31.760
<v Speaker 4>services that you want to build, and once they have

719
00:40:31.840 --> 00:40:35.199
<v Speaker 4>that logical form of modules within the same model, if

720
00:40:35.599 --> 00:40:39.239
<v Speaker 4>it's okay to be wrong, that's right, a mistake that

721
00:40:39.599 --> 00:40:40.880
<v Speaker 4>is really easy to fix.

722
00:40:41.039 --> 00:40:43.480
<v Speaker 2>But you're also doing this very empirically. You know, if

723
00:40:43.480 --> 00:40:46.679
<v Speaker 2>you assemble them, they'll gather some momentum and life will

724
00:40:46.679 --> 00:40:49.159
<v Speaker 2>be easier for a while, but eventually you're going to

725
00:40:49.199 --> 00:40:51.960
<v Speaker 2>have a production issue of some kind that sort of

726
00:40:52.000 --> 00:40:55.360
<v Speaker 2>points to, here's a piece of code that's resonating and

727
00:40:55.400 --> 00:40:57.920
<v Speaker 2>if it were separated, it would cause less residence.

728
00:40:59.519 --> 00:41:03.360
<v Speaker 4>That's true. Yeah, that's true, But there are different ways

729
00:41:03.440 --> 00:41:10.599
<v Speaker 4>to There was a company I was working with. They

730
00:41:11.159 --> 00:41:13.840
<v Speaker 4>had that code base which was monolithic, but it was

731
00:41:13.880 --> 00:41:19.639
<v Speaker 4>still deployed as different services for that reason, not sually.

732
00:41:19.679 --> 00:41:22.519
<v Speaker 4>For that reason, they needed different levels of scale for

733
00:41:22.559 --> 00:41:26.679
<v Speaker 4>different components of that system. So the underlying code base

734
00:41:27.000 --> 00:41:31.480
<v Speaker 4>is monolithic. Whatever there is change like new deployment, we

735
00:41:31.559 --> 00:41:37.119
<v Speaker 4>already deploying all the services together like no exceptions, but

736
00:41:37.360 --> 00:41:42.760
<v Speaker 4>still were able to gain the benefits of a lower

737
00:41:43.119 --> 00:41:48.840
<v Speaker 4>cost of a design mistake and that advantage of kind

738
00:41:48.840 --> 00:41:54.440
<v Speaker 4>of reducing the operational the cost of operational failure.

739
00:41:55.159 --> 00:41:58.320
<v Speaker 1>Give me a story of where you found difficult people

740
00:41:58.519 --> 00:42:01.039
<v Speaker 1>who dug in their heels and said, you know, I

741
00:42:01.199 --> 00:42:05.760
<v Speaker 1>separated out these micro services because I read such and

742
00:42:05.840 --> 00:42:09.679
<v Speaker 1>such a book and you know this is sound architecture

743
00:42:09.679 --> 00:42:12.199
<v Speaker 1>and you don't know what you're talking about, and you know,

744
00:42:12.280 --> 00:42:15.920
<v Speaker 1>meanwhile it's really slow and brittle. I mean, how do

745
00:42:15.960 --> 00:42:17.119
<v Speaker 1>you deal with people like that?

746
00:42:17.599 --> 00:42:20.920
<v Speaker 4>So usually when they call me, these people have already

747
00:42:21.039 --> 00:42:30.920
<v Speaker 4>left the company. Ah really, well, maybe they were promoted

748
00:42:31.480 --> 00:42:32.960
<v Speaker 4>so that they.

749
00:42:34.559 --> 00:42:38.239
<v Speaker 1>Yeah, Gilbert Principle failing upward and moved to management.

750
00:42:38.480 --> 00:42:38.920
<v Speaker 2>There you go.

751
00:42:40.039 --> 00:42:43.639
<v Speaker 1>Yeah, I see, but you you have obviously at some

752
00:42:43.800 --> 00:42:47.440
<v Speaker 1>point experienced and pushback, right of course. Yeah.

753
00:42:47.480 --> 00:42:49.119
<v Speaker 2>But at the same time, they're not calling you because

754
00:42:49.159 --> 00:42:50.000
<v Speaker 2>things are going well.

755
00:42:50.280 --> 00:42:50.519
<v Speaker 1>Yeah.

756
00:42:51.119 --> 00:42:53.440
<v Speaker 2>Yeah, they never called me for that. It's like, hey,

757
00:42:53.639 --> 00:42:55.239
<v Speaker 2>I wanted to pay your fee and bring it in

758
00:42:55.280 --> 00:42:57.079
<v Speaker 2>for a week just to show you how well everything's going.

759
00:42:57.800 --> 00:43:01.039
<v Speaker 1>I think about Robert Irvine and restaurants impossible. How he

760
00:43:01.079 --> 00:43:03.559
<v Speaker 1>goes into these failing restaurants and they dig in their

761
00:43:03.559 --> 00:43:06.079
<v Speaker 1>heels and says, my food is great, and it's like, yeah,

762
00:43:06.119 --> 00:43:08.360
<v Speaker 1>I can tell your one customer loves it.

763
00:43:11.440 --> 00:43:14.440
<v Speaker 4>Well. You know what, if we're talking about pushbacks, then

764
00:43:14.599 --> 00:43:17.760
<v Speaker 4>I'll bring back the topic of domain dreaming design because

765
00:43:17.920 --> 00:43:21.719
<v Speaker 4>for some reason, the main driving design it's got this

766
00:43:21.960 --> 00:43:26.280
<v Speaker 4>reputation of being too complex, with too much, too many

767
00:43:26.320 --> 00:43:29.079
<v Speaker 4>patterns and if you apply them.

768
00:43:29.039 --> 00:43:31.639
<v Speaker 1>Driven because it makes your foot look big and it's

769
00:43:31.639 --> 00:43:33.440
<v Speaker 1>a it's a pistol, you know.

770
00:43:33.760 --> 00:43:40.280
<v Speaker 4>Yeah. Now, once you face that kind of pushback, what

771
00:43:40.360 --> 00:43:44.519
<v Speaker 4>I usually do is I started talking about the principles

772
00:43:44.719 --> 00:43:48.719
<v Speaker 4>of domain dreaming design without mentioning domaindreamine design without mentioning

773
00:43:48.920 --> 00:43:53.880
<v Speaker 4>concrete patterns like Okay, so we have this problem that

774
00:43:53.920 --> 00:43:57.800
<v Speaker 4>we have to address. So that's the root cause of

775
00:43:57.840 --> 00:44:01.159
<v Speaker 4>the issues you're facing. Now, maybe you want a brainstorm

776
00:44:01.199 --> 00:44:03.639
<v Speaker 4>what we can do. And there was a guy that

777
00:44:03.760 --> 00:44:07.760
<v Speaker 4>invented the aggregate pattern with a different name, but he

778
00:44:07.880 --> 00:44:10.119
<v Speaker 4>was so happy, and I said, okay, cool, let's go

779
00:44:10.159 --> 00:44:11.880
<v Speaker 4>on with it. Call it what a you wanted.

780
00:44:12.360 --> 00:44:14.880
<v Speaker 1>Yeah, yeah, yeah, Bob's pattern.

781
00:44:15.039 --> 00:44:17.559
<v Speaker 2>But yeah, you know it's people have their biases. So

782
00:44:17.559 --> 00:44:19.639
<v Speaker 2>if you leave the words out but still do the

783
00:44:19.679 --> 00:44:24.039
<v Speaker 2>work and get results. And maybe he retroduced the word later,

784
00:44:24.119 --> 00:44:26.760
<v Speaker 2>but it's not even important. The goal was to get solved,

785
00:44:26.960 --> 00:44:30.079
<v Speaker 2>so just find a way to get forward. The principles

786
00:44:30.079 --> 00:44:32.960
<v Speaker 2>are still their useful principles for some reason.

787
00:44:33.039 --> 00:44:35.760
<v Speaker 4>I don't know why, but this model of balanced coupling

788
00:44:35.840 --> 00:44:38.039
<v Speaker 4>is way easier for people to grasp and to start

789
00:44:38.119 --> 00:44:40.559
<v Speaker 4>using them. Domain dum in design, Yeah, I mean always

790
00:44:40.559 --> 00:44:41.840
<v Speaker 4>compared with do major in design.

791
00:44:42.119 --> 00:44:46.000
<v Speaker 1>I'm getting that. Yeah, I'm getting that. Four levels. That's

792
00:44:46.039 --> 00:44:46.800
<v Speaker 1>all you need to know.

793
00:44:47.159 --> 00:44:51.000
<v Speaker 2>Yeah, just that conversation of sorting your problems into these

794
00:44:51.039 --> 00:44:53.880
<v Speaker 2>different categories and then saying and then you have it

795
00:44:53.880 --> 00:44:56.519
<v Speaker 2>approach strategy for each one. It's different.

796
00:44:57.960 --> 00:45:02.519
<v Speaker 4>Yeah, and if you look into pretty much almost all

797
00:45:02.719 --> 00:45:06.159
<v Speaker 4>patterns from domain dreaming design, they have that balancing behind

798
00:45:06.159 --> 00:45:10.960
<v Speaker 4>the scenes. If you have, for example, Eric Evans always

799
00:45:11.079 --> 00:45:14.360
<v Speaker 4>says that not all of our system is going to

800
00:45:14.400 --> 00:45:17.599
<v Speaker 4>be well designed. It means that supporting subdomains are not

801
00:45:17.679 --> 00:45:21.159
<v Speaker 4>that important. It's okay to around some corners. What about

802
00:45:21.199 --> 00:45:25.039
<v Speaker 4>supporting subdomains. They're not business critical, so they're not going

803
00:45:25.079 --> 00:45:28.079
<v Speaker 4>to change that much, which means their volatility is going

804
00:45:28.119 --> 00:45:31.960
<v Speaker 4>to be much lower than core subdomins. So again we're

805
00:45:32.000 --> 00:45:36.480
<v Speaker 4>getting that balance. We can introduce some complexity because we

806
00:45:36.519 --> 00:45:41.880
<v Speaker 4>have lower volatility, but when we're talking about high volatility

807
00:45:42.000 --> 00:45:46.679
<v Speaker 4>of course subdomains, then yeah, we should keep things as

808
00:45:46.920 --> 00:45:50.039
<v Speaker 4>well designed as possible. Sure we have those patterns for

809
00:45:50.239 --> 00:45:53.039
<v Speaker 4>encapsulating models in bounded contexts, etc.

810
00:45:53.400 --> 00:45:57.440
<v Speaker 2>You're also learning to pick your fights right. You get

811
00:45:57.440 --> 00:46:00.360
<v Speaker 2>people together that be architecturally absolutist in everything has to

812
00:46:00.360 --> 00:46:03.320
<v Speaker 2>be built the same way, where by going through this

813
00:46:03.400 --> 00:46:07.519
<v Speaker 2>coupling practice and figuring out what's actually going to be problematic,

814
00:46:07.760 --> 00:46:09.239
<v Speaker 2>only fight for the ones that are going to have

815
00:46:09.280 --> 00:46:13.199
<v Speaker 2>the biggest harm if they are done poorly. The edge

816
00:46:13.199 --> 00:46:15.480
<v Speaker 2>cases can be a little can be weaker because the

817
00:46:15.519 --> 00:46:18.639
<v Speaker 2>consequences are small. But where the consequences are big, then

818
00:46:18.679 --> 00:46:21.480
<v Speaker 2>you can push harder and spend more time, even do

819
00:46:21.679 --> 00:46:24.960
<v Speaker 2>spikes to evaluate how couple this is really going to be.

820
00:46:25.119 --> 00:46:28.320
<v Speaker 2>What are the consequences of separating it? Like, it's worth

821
00:46:28.360 --> 00:46:29.719
<v Speaker 2>spending time on that, just you don't have to do

822
00:46:29.719 --> 00:46:30.280
<v Speaker 2>it for everything.

823
00:46:31.800 --> 00:46:36.719
<v Speaker 4>Yeah, and volatility, that dimension of changes or dimension of

824
00:46:36.760 --> 00:46:40.480
<v Speaker 4>time helps a lot here because once you spot the

825
00:46:40.599 --> 00:46:43.800
<v Speaker 4>high volatility. By the way, how do you evaluate volatility

826
00:46:44.440 --> 00:46:48.679
<v Speaker 4>and different ways different models. I prefer the management design subdomains.

827
00:46:49.440 --> 00:46:53.000
<v Speaker 4>And once you spot a high volatility, then yeah, you

828
00:46:53.079 --> 00:46:56.079
<v Speaker 4>have a low hanging through there things that first.

829
00:46:56.320 --> 00:46:59.599
<v Speaker 2>Yeah, Well, and it also speaks to when we're going

830
00:46:59.639 --> 00:47:02.280
<v Speaker 2>to sign a new piece of this app and we

831
00:47:02.360 --> 00:47:05.280
<v Speaker 2>see high volatility. Now I certainly have a new opinion

832
00:47:05.320 --> 00:47:07.880
<v Speaker 2>about where should it reside based on where what the

833
00:47:07.920 --> 00:47:10.880
<v Speaker 2>coupling looks like. It's like, you know, at least initially,

834
00:47:10.920 --> 00:47:13.119
<v Speaker 2>I think we should start this in this team where

835
00:47:13.159 --> 00:47:15.239
<v Speaker 2>it's close to all the pieces it's going to touch.

836
00:47:15.840 --> 00:47:19.119
<v Speaker 2>You know, if that changes, we can revise that but

837
00:47:19.239 --> 00:47:22.239
<v Speaker 2>for the moment, especially when say the design is immature,

838
00:47:22.360 --> 00:47:26.079
<v Speaker 2>it's a new area, Minimizing distance takes a lot of

839
00:47:26.159 --> 00:47:26.960
<v Speaker 2>risk off the table.

840
00:47:27.480 --> 00:47:27.679
<v Speaker 1>Yeah.

841
00:47:27.719 --> 00:47:31.440
<v Speaker 4>Well, let's be honest here, it's not always possible. Sometimes

842
00:47:31.480 --> 00:47:37.920
<v Speaker 4>when you minimize the distance, you are introducing accidental complexity, Right,

843
00:47:39.119 --> 00:47:42.760
<v Speaker 4>So I always strive for at least logical boundaries within

844
00:47:42.800 --> 00:47:46.800
<v Speaker 4>that monolith. Sure, and then we have that distance. It's

845
00:47:46.880 --> 00:47:51.760
<v Speaker 4>going to be significantly lower compared to the initial distribute monelith,

846
00:47:51.840 --> 00:47:55.519
<v Speaker 4>of course, but still we can talk about different distances

847
00:47:55.599 --> 00:47:58.679
<v Speaker 4>within that code base, within that monelith. If we're looking

848
00:47:58.679 --> 00:48:01.719
<v Speaker 4>at the same module, the same logical boundary, the distance

849
00:48:01.840 --> 00:48:06.159
<v Speaker 4>is lower compared to different logical boundaries within it.

850
00:48:06.599 --> 00:48:08.599
<v Speaker 2>Yeah, I appreciate that. That's good.

851
00:48:08.719 --> 00:48:11.079
<v Speaker 1>Yeah, So is there anything else that you want to

852
00:48:11.119 --> 00:48:14.159
<v Speaker 1>cover before we say goodbye? Any shout outs or anything

853
00:48:14.400 --> 00:48:15.079
<v Speaker 1>shut outs?

854
00:48:15.800 --> 00:48:19.159
<v Speaker 4>Not surely. I just want to remind again that there

855
00:48:19.239 --> 00:48:26.719
<v Speaker 4>is more to it. There are degrees for the three

856
00:48:27.480 --> 00:48:29.480
<v Speaker 4>levels of integration strength.

857
00:48:30.039 --> 00:48:32.239
<v Speaker 1>Right, that's the one you said would take another hour

858
00:48:32.320 --> 00:48:32.920
<v Speaker 1>to explain.

859
00:48:33.519 --> 00:48:38.360
<v Speaker 4>Yeah, they provide more detail and they also kind of

860
00:48:38.400 --> 00:48:41.639
<v Speaker 4>help you to identify those specific cases, whether it's functional

861
00:48:41.639 --> 00:48:42.719
<v Speaker 4>coupling or model coupling.

862
00:48:42.880 --> 00:48:48.800
<v Speaker 1>All right, well, Vlad Honenoff. His new book is Balancing

863
00:48:48.920 --> 00:48:53.719
<v Speaker 1>Coupling and Software Design. Go check it out. It's a

864
00:48:53.719 --> 00:48:58.440
<v Speaker 1>fascinating subject and we've already had our eyes open. And

865
00:48:58.840 --> 00:49:01.559
<v Speaker 1>thank you Vlad for talking to us today. Thank you

866
00:49:01.639 --> 00:49:03.719
<v Speaker 1>so much for having me bet all right, we'll talk

867
00:49:03.760 --> 00:49:07.239
<v Speaker 1>to you, dear listener, next time on dot net rocks.

868
00:49:27.400 --> 00:49:30.320
<v Speaker 1>Dot NetRocks is brought to you by Franklin's Net and

869
00:49:30.400 --> 00:49:34.320
<v Speaker 1>produced by Pop Studios, a full service audio, video and

870
00:49:34.400 --> 00:49:38.679
<v Speaker 1>post production facility located physically in New London, Connecticut, and

871
00:49:38.760 --> 00:49:43.400
<v Speaker 1>of course in the cloud online at pwop dot com.

872
00:49:43.599 --> 00:49:45.719
<v Speaker 3>Visit our website at d O T N E t

873
00:49:45.960 --> 00:49:49.960
<v Speaker 3>R O c k S dot com for RSS feeds, downloads,

874
00:49:50.119 --> 00:49:53.800
<v Speaker 3>mobile apps, comments, and access to the full archives going

875
00:49:53.840 --> 00:49:57.199
<v Speaker 3>back to show number one, recorded in September.

876
00:49:56.679 --> 00:49:59.199
<v Speaker 1>Two thousand and two. And make sure you check out

877
00:49:59.199 --> 00:50:02.360
<v Speaker 1>our sponsors. They keep us in business. Now, go write

878
00:50:02.400 --> 00:50:04.199
<v Speaker 1>some code. See you next time.

879
00:50:05.079 --> 00:50:06.559
<v Speaker 3>You got your middle.

880
00:50:06.400 --> 00:50:14.679
<v Speaker 1>Vands do the same. This is hard than my Texas