1
00:00:00,040 --> 00:00:03,280
Welcome to the Dee dive. 
Today we're really getting into 

2
00:00:03,280 --> 00:00:06,920
a core concept in software, 
something fundamental to well, 

3
00:00:07,200 --> 00:00:10,120
retty much everything digital. 
And here's the thing, it's 

4
00:00:10,120 --> 00:00:15,200
crucial because architectural 
decisions in software, they are 

5
00:00:15,360 --> 00:00:17,680
incredibly hard to change later 
on. 

6
00:00:18,120 --> 00:00:20,960
Really hard. 
And the the negative effects, 

7
00:00:21,080 --> 00:00:24,360
they can sort of bubble under 
the surface for years, maybe 

8
00:00:24,360 --> 00:00:26,760
even decades, before you really 
see the problem. 

9
00:00:26,760 --> 00:00:28,520
Absolutely. 
It's like setting the foundation

10
00:00:28,520 --> 00:00:30,120
of a building, isn't it? 
Exactly. 

11
00:00:30,120 --> 00:00:32,759
Take Linus Torvalds, right, the 
creator of Linux. 

12
00:00:33,360 --> 00:00:38,280
After something like 15 years, 
he he famously called the Linux 

13
00:00:38,280 --> 00:00:41,960
Colonel huge and bloated, right?
And that comment, it just 

14
00:00:41,960 --> 00:00:45,080
perfectly highlights how these 
early architectural choices, 

15
00:00:45,080 --> 00:00:47,040
they have such long lasting 
consequences. 

16
00:00:47,040 --> 00:00:49,960
They really do. 
So our mission today, our focus,

17
00:00:49,960 --> 00:00:53,240
is to unpack one key idea 
designed to handle this 

18
00:00:53,240 --> 00:00:56,600
complexity, to let software 
systems actually evolve 

19
00:00:56,600 --> 00:00:58,040
gracefully. 
We're talking about layered 

20
00:00:58,040 --> 00:00:59,640
architecture. 
We're going to dig into the 

21
00:00:59,640 --> 00:01:02,160
principles, the benefits, which 
are often bigger than you might 

22
00:01:02,160 --> 00:01:04,800
think, and you know how it 
actually gets used out there. 

23
00:01:05,080 --> 00:01:07,280
And that's so important, 
understanding these concepts. 

24
00:01:07,280 --> 00:01:10,000
It's not just about definitions,
it's about grasping why they 

25
00:01:10,000 --> 00:01:13,400
exist. 
They're essentially smart ways 

26
00:01:13,400 --> 00:01:17,240
to deal with just the sheer 
amount of information and 

27
00:01:17,240 --> 00:01:19,680
complexity you face when 
designing big systems. 

28
00:01:19,680 --> 00:01:20,520
OK. 
Great point. 

29
00:01:20,880 --> 00:01:24,880
SO with that in mind, let's 
start peeling back the layers. 

30
00:01:24,880 --> 00:01:27,880
Yeah, I said define what layered
architecture actually is. 

31
00:01:27,880 --> 00:01:28,560
Yeah, nice. 
One it's. 

32
00:01:28,920 --> 00:01:30,840
Definitely not new. 
Yeah, it's one of the most 

33
00:01:30,840 --> 00:01:33,680
common patterns out there, and 
it's history goes way back. 

34
00:01:34,000 --> 00:01:37,680
We're talking the 1960s, 
seventies, the era of the first 

35
00:01:37,680 --> 00:01:40,200
really large software system. 
Right, it's foundational. 

36
00:01:40,360 --> 00:01:44,320
At its core, it's basically a 
method for organizing your code,

37
00:01:44,320 --> 00:01:46,800
your classes, into these 
distinct groups. 

38
00:01:46,800 --> 00:01:49,760
These modules we call layers. 
Think of it like a cake. 

39
00:01:49,760 --> 00:01:52,320
Maybe you've got these layers. 
Stack one on on top of the 

40
00:01:52,320 --> 00:01:55,320
other, hierarchically arranged. 
A good analogy, but. 

41
00:01:55,320 --> 00:01:58,240
Here's the crucial part. 
Unlike Cake, there's a very 

42
00:01:58,240 --> 00:02:01,360
strict rule. 
A really strict 1A layer can 

43
00:02:01,360 --> 00:02:05,160
only use services. 
So calling methods, creating 

44
00:02:05,160 --> 00:02:08,320
objects, extending classes, 
declaring parameters, even 

45
00:02:08,320 --> 00:02:11,000
throwing exceptions only from 
the layer immediately below it. 

46
00:02:11,240 --> 00:02:13,680
That's the key constraint. 
Yeah, no skipping. 

47
00:02:13,880 --> 00:02:17,800
You can't reach down to levels. 
It's strictly one way direct 

48
00:02:17,800 --> 00:02:20,240
communication layer to layer 
downwards. 

49
00:02:20,640 --> 00:02:24,000
This discipline is what stops 
everything becoming a tangled 

50
00:02:24,000 --> 00:02:25,920
mess. 
And it sounds simple, but that 

51
00:02:25,920 --> 00:02:29,080
rule is incredibly powerful. 
It's how you partition the 

52
00:02:29,080 --> 00:02:31,760
enormous complexity of building 
a whole system. 

53
00:02:32,040 --> 00:02:37,120
You break it into these smaller,
more focused components and this

54
00:02:37,120 --> 00:02:40,520
layering it imposes discipline 
on how these components depend 

55
00:02:40,520 --> 00:02:44,320
on each other, which in turn 
makes the system much easier to 

56
00:02:44,320 --> 00:02:47,720
understand, much easier to 
maintain, and critically, easier

57
00:02:47,720 --> 00:02:50,360
to evolve over time. 
That's huge for long term 

58
00:02:50,360 --> 00:02:52,200
projects. 
Can you give an example of that 

59
00:02:52,200 --> 00:02:52,840
benefit? 
Sure. 

60
00:02:53,000 --> 00:02:55,960
Let's say you need to swap out 
how your system communicates 

61
00:02:55,960 --> 00:02:58,080
over the network. 
Maybe you want to switch from 

62
00:02:58,480 --> 00:03:01,720
TCP to UDP. 
OK, because of the layering, you

63
00:03:01,720 --> 00:03:04,400
can potentially make that change
within its specific layer 

64
00:03:04,400 --> 00:03:07,120
without, you know, having to 
rewrite large parts of the 

65
00:03:07,120 --> 00:03:09,240
layers above it. 
The interface stays the same, 

66
00:03:09,240 --> 00:03:11,320
but the implementation behind it
changes. 

67
00:03:11,880 --> 00:03:13,600
I see. 
So it isolates the change. 

68
00:03:13,800 --> 00:03:16,440
Exactly, and it also really 
helps with reuse. 

69
00:03:16,440 --> 00:03:20,280
Think about application 
protocols like HTCP for the web,

70
00:03:20,320 --> 00:03:23,560
SMTP for e-mail, DHTP for 
network configuration. 

71
00:03:23,880 --> 00:03:26,720
They can all use the same 
transport layer underneath like 

72
00:03:26,720 --> 00:03:29,280
TCP. 
They don't each need to reinvent

73
00:03:29,280 --> 00:03:31,800
how to reliably send data 
packets. 

74
00:03:31,800 --> 00:03:33,040
Right, that saves a ton of 
effort. 

75
00:03:33,160 --> 00:03:35,920
A massive efficiency gain, 
faster development, more 

76
00:03:35,920 --> 00:03:38,960
reliable systems because you're 
reusing proven components. 

77
00:03:39,320 --> 00:03:41,280
That's a perfect segue, 
actually, because network 

78
00:03:41,280 --> 00:03:45,640
protocols are probably the most 
common everyday example of 

79
00:03:45,640 --> 00:03:47,680
layered architecture we all 
interact with. 

80
00:03:47,800 --> 00:03:49,480
Definitely. 
Like when you browse a website, 

81
00:03:49,720 --> 00:03:51,680
your browser's using HTTP, 
right? 

82
00:03:51,840 --> 00:03:53,960
The hypertext transfer protocol 
that's sitting at the 

83
00:03:53,960 --> 00:03:57,120
application layer. 
But HTTP doesn't just magically 

84
00:03:57,120 --> 00:03:59,720
send data, it works with the 
layers below it. 

85
00:04:00,200 --> 00:04:02,920
It relies on PCP, the 
transmission control protocol, 

86
00:04:02,920 --> 00:04:04,800
the transport layer, and then 
TCP. 

87
00:04:05,240 --> 00:04:08,120
It hands things off to I the 
Internet Protocol at the network

88
00:04:08,120 --> 00:04:09,760
layer. 
Getting closer to the wire. 

89
00:04:09,920 --> 00:04:12,200
Exactly. 
And then I uses something like 

90
00:04:12,200 --> 00:04:16,079
Ethernet at the communication 
layer to actually push the bits 

91
00:04:16,279 --> 00:04:19,440
over the physical network, the 
cable or Wi-Fi. 

92
00:04:19,839 --> 00:04:23,760
It's this really elegant stack. 
It is, and connecting this back 

93
00:04:23,760 --> 00:04:26,840
historically, one of the most 
influential early examples was 

94
00:04:26,840 --> 00:04:29,360
from Edgar Dykstra, a real 
pioneer. 

95
00:04:29,720 --> 00:04:31,720
Dykstra, 1968. 
That's the one. 

96
00:04:31,840 --> 00:04:37,400
He was designing an operating 
system called the HETHE and he 

97
00:04:37,400 --> 00:04:39,520
explicitly proposed using 
layers. 

98
00:04:39,680 --> 00:04:43,760
His system had, let's see, layer
0 for multi programming, kind of

99
00:04:43,760 --> 00:04:46,400
the course scheduler. 
Then layer one handled memory 

100
00:04:46,400 --> 00:04:49,880
allocation, layer 2 was for 
inter process communication, 

101
00:04:50,240 --> 00:04:54,160
layer 3 managed IO input output 
and then layer 4 at the top was 

102
00:04:54,160 --> 00:04:57,320
where the user programs ran. 
Wow, quite defined even back 

103
00:04:57,320 --> 00:04:58,280
then. 
Very. 

104
00:04:58,560 --> 00:05:01,520
And Dijkstra's conclusion from 
building the AP was absolutely 

105
00:05:01,520 --> 00:05:03,320
critical. 
He found that the benefits of 

106
00:05:03,320 --> 00:05:05,960
structuring things this way 
hierarchically become more 

107
00:05:05,960 --> 00:05:08,680
important increasingly title as 
the project gets bigger and more

108
00:05:08,680 --> 00:05:10,560
complex, which. 
Brings us right back to our 

109
00:05:10,560 --> 00:05:13,080
starting point about managing 
complexity in large systems. 

110
00:05:13,280 --> 00:05:16,200
Precisely. 
It underscores why these 

111
00:05:16,200 --> 00:05:18,800
architectural patterns aren't 
just academic exercises. 

112
00:05:19,080 --> 00:05:21,960
They're practical necessities 
for building robust software. 

113
00:05:22,080 --> 00:05:23,880
OK, so let's shift gears 
slightly. 

114
00:05:24,200 --> 00:05:27,760
We've talked principles, 
history, networking examples. 

115
00:05:28,040 --> 00:05:32,080
Now let's look at a really 
common specific layered pattern,

116
00:05:32,200 --> 00:05:35,520
especially in business 
applications, the three tier 

117
00:05:35,520 --> 00:05:38,000
architecture. 
Yes, very common in enterprise 

118
00:05:38,000 --> 00:05:39,360
systems. 
Yeah, you see it everywhere. 

119
00:05:39,640 --> 00:05:43,160
But it wasn't always like this. 
If you go back before, say, the 

120
00:05:43,160 --> 00:05:46,840
late 1980s, most enterprise 
applications, think payroll 

121
00:05:46,840 --> 00:05:49,800
systems, inventory management, 
they were monolithic. 

122
00:05:49,840 --> 00:05:51,440
Right, big single chunks of 
code. 

123
00:05:51,600 --> 00:05:54,160
Exactly. 
Running on mainframes and users 

124
00:05:54,160 --> 00:05:56,400
connected through dumb 
terminals, basically just 

125
00:05:56,400 --> 00:05:59,200
screens and keyboards with no 
real processing power 

126
00:05:59,200 --> 00:06:01,640
themselves. 
But then networks got faster, 

127
00:06:01,640 --> 00:06:04,400
hardware got cheaper and more 
powerful, and it became 

128
00:06:04,400 --> 00:06:06,840
practical to actually split 
these applications up, 

129
00:06:07,160 --> 00:06:09,000
distribute them across different
machines. 

130
00:06:09,000 --> 00:06:10,640
And that's where 3 Tier really 
took off. 

131
00:06:10,640 --> 00:06:13,000
It offered a more flexible way 
to build these distributed 

132
00:06:13,000 --> 00:06:15,000
systems. 
So let's breakdown those 3 

133
00:06:15,000 --> 00:06:16,000
tiers. 
What are they? 

134
00:06:16,080 --> 00:06:19,800
OK, so tier one at the top is 
the user interface, sometimes 

135
00:06:19,800 --> 00:06:22,400
called the presentation layer. 
What the user sees and 

136
00:06:22,400 --> 00:06:23,560
interacts. 
With exactly. 

137
00:06:23,640 --> 00:06:27,160
It's responsible for showing 
data to the user, getting their 

138
00:06:27,160 --> 00:06:30,640
input, handling things like 
button clicks, form submissions.

139
00:06:30,640 --> 00:06:34,640
So if we think about an academic
system, again, an instructor 

140
00:06:34,640 --> 00:06:38,200
entering grades, that form they 
use with the student names, the 

141
00:06:38,200 --> 00:06:41,440
grade fields, that's all part of
the user interface layer. 

142
00:06:41,480 --> 00:06:43,960
Got it. 
Tier one dot UI What's next? 

143
00:06:44,360 --> 00:06:46,520
Tier 2 is the Business Logic 
layer. 

144
00:06:46,840 --> 00:06:49,400
You might also hear it called 
the Application layer. 

145
00:06:49,400 --> 00:06:51,440
This is really the engine of the
system or the. 

146
00:06:51,440 --> 00:06:53,840
Rules live. 
Precisely, it implements the 

147
00:06:53,840 --> 00:06:56,280
system score business rules and 
processes. 

148
00:06:56,480 --> 00:07:00,200
So back to the grading example. 
This layer would handle things 

149
00:07:00,200 --> 00:07:02,520
like checking if the grade 
entered is valid. 

150
00:07:02,720 --> 00:07:05,680
Is it between zero and the 
maximum possible score for that 

151
00:07:05,680 --> 00:07:06,680
exam? 
Makes sense. 

152
00:07:06,680 --> 00:07:09,960
Or another rule might be after 
grade is successfully saved, 

153
00:07:10,120 --> 00:07:12,600
automatically send an e-mail 
notification to the student. 

154
00:07:13,040 --> 00:07:15,840
All that logic resides here in 
the business logic layer. 

155
00:07:15,840 --> 00:07:18,240
OK, UI business logic. 
What's the third tier? 

156
00:07:18,400 --> 00:07:21,520
The third tier at the bottom is 
the database layer. 

157
00:07:22,160 --> 00:07:25,120
Its job is pretty 
straightforward, store and 

158
00:07:25,120 --> 00:07:27,000
manage the data. 
Persistence. 

159
00:07:27,040 --> 00:07:30,280
Right, so after the instructor 
enters the grades and the 

160
00:07:30,280 --> 00:07:34,120
business logic layer validates 
them, this layer is responsible 

161
00:07:34,120 --> 00:07:37,600
for actually saving those grades
permanently into the database. 

162
00:07:37,840 --> 00:07:40,320
And a key thing here is that 
this is usually a distributed 

163
00:07:40,320 --> 00:07:42,040
setup, right? 
These aren't all running on one 

164
00:07:42,040 --> 00:07:43,840
machine. 
Crucial point. 

165
00:07:44,280 --> 00:07:49,400
In a typical 3 tier setup, the 
user interface runs on the 

166
00:07:49,400 --> 00:07:51,360
client machine, your laptop, 
your phone. 

167
00:07:51,960 --> 00:07:54,880
The business logic runs on a 
separate application server, 

168
00:07:54,920 --> 00:07:58,240
often a pretty powerful machine 
or cluster of machines, and the 

169
00:07:58,240 --> 00:08:02,080
database that runs on its own 
dedicated database server, or 

170
00:08:02,080 --> 00:08:05,640
maybe a cluster of database 
servers optimized specifically 

171
00:08:05,640 --> 00:08:08,480
for handling data storage and 
retrieval efficiently and 

172
00:08:08,480 --> 00:08:09,360
securely. 
So. 

173
00:08:09,800 --> 00:08:12,360
Physically separate components 
communicating over a network. 

174
00:08:12,360 --> 00:08:14,600
Exactly. 
And within that middle tier, the

175
00:08:14,600 --> 00:08:17,960
business logic, you often find 
further organization. 

176
00:08:17,960 --> 00:08:20,320
You might see, for example, 
something called a facade. 

177
00:08:20,480 --> 00:08:23,720
Yeah, it's a design pattern. 
It basically provides A simpler 

178
00:08:23,720 --> 00:08:27,600
unified entry point to a 
potentially complex set of 

179
00:08:27,600 --> 00:08:31,320
underlying business operations. 
Makes it easier for the UI 

180
00:08:31,320 --> 00:08:34,360
layer, the client, to talk to 
the business logic without 

181
00:08:34,360 --> 00:08:36,080
needing to know all the 
intricate details. 

182
00:08:36,080 --> 00:08:37,760
That's sort of. 
Like a simplified menu for the 

183
00:08:37,760 --> 00:08:41,120
complex kitchen behind it. 
Do an analogy and you'd also 

184
00:08:41,120 --> 00:08:43,520
typically find a persistence 
module in there. 

185
00:08:44,000 --> 00:08:47,040
It's job is specifically to 
handle all the communication 

186
00:08:47,040 --> 00:08:49,360
with the database layer. 
Talking SQL, handling 

187
00:08:49,360 --> 00:08:52,200
connections, that sort of thing.
So it isolates the database 

188
00:08:52,200 --> 00:08:53,760
details from the core business 
rules. 

189
00:08:53,760 --> 00:08:55,800
Exactly. 
Keeps concerns separate. 

190
00:08:55,800 --> 00:08:59,280
The business rules shouldn't 
need to know how data is saved, 

191
00:08:59,280 --> 00:09:01,960
just that it gets saved. 
Makes sense for maintainability.

192
00:09:02,240 --> 00:09:04,920
Now you mentioned 3 tier. 
Is there such a thing as 2 tier?

193
00:09:05,040 --> 00:09:08,240
Oh yeah, definitely 2 tier 
architectures exist too. 

194
00:09:08,280 --> 00:09:11,480
In that model, you basically 
combine the user interface and 

195
00:09:11,480 --> 00:09:13,800
the business logic into a single
layer. 

196
00:09:13,960 --> 00:09:15,920
OK, so UI and rules run 
together. 

197
00:09:16,080 --> 00:09:18,760
Right, typically they run 
together on the client machine 

198
00:09:18,920 --> 00:09:21,880
and then the database is the 
second separate tier, usually on

199
00:09:21,880 --> 00:09:23,760
a server. 
What's the downside there? 

200
00:09:24,360 --> 00:09:27,360
Seems simpler. 
It can be simpler initially, but

201
00:09:27,360 --> 00:09:30,920
the big disadvantage is that all
the processing work displaying 

202
00:09:30,920 --> 00:09:33,800
the interface and executing the 
business rules happens on the 

203
00:09:33,800 --> 00:09:34,520
client machine. 
AH. 

204
00:09:35,480 --> 00:09:37,800
So the user's computer needs to 
be more powerful. 

205
00:09:37,800 --> 00:09:39,960
Exactly. 
It puts a much heavier 

206
00:09:39,960 --> 00:09:43,680
computational load on the client
machines, which might not always

207
00:09:43,680 --> 00:09:47,560
be desirable or feasible, 
especially if you have many 

208
00:09:47,560 --> 00:09:52,000
users or less powerful client 
devices. 3 tier distributes that

209
00:09:52,000 --> 00:09:54,240
load more effectively. 
Right, that makes a lot of 

210
00:09:54,240 --> 00:09:56,600
sense. 
Well, as we wrap up this deep 

211
00:09:56,600 --> 00:09:59,240
dive, it's really clear that 
layered architectures aren't 

212
00:09:59,240 --> 00:10:03,360
just some theoretical thing, 
they're they're fundamental to 

213
00:10:03,360 --> 00:10:06,360
building software that can 
actually scale and last. 

214
00:10:06,960 --> 00:10:08,960
Absolutely. 
Understanding these patterns 

215
00:10:08,960 --> 00:10:11,440
like layered and three tier, it 
really gives you a blueprint. 

216
00:10:11,600 --> 00:10:14,800
It helps you understand how 
complex software is put together

217
00:10:14,800 --> 00:10:17,840
and why it's designed that way. 
It's valuable knowledge for 

218
00:10:17,840 --> 00:10:21,240
anyone working with or even just
using modern software systems. 

219
00:10:21,440 --> 00:10:23,960
Thanks for joining us for this 
look into layered architectures.

220
00:10:23,960 --> 00:10:24,680
Thanks for having me.