1
00:00:00,040 --> 00:00:03,800
Welcome to another deep dive. 
Today we're taking a plunge into

2
00:00:03,800 --> 00:00:07,080
something pretty fundamental in 
software engineering, Clean 

3
00:00:07,080 --> 00:00:09,600
Architecture. 
Yeah, it comes up a lot. 

4
00:00:09,600 --> 00:00:11,960
It really does. 
And it's not just, you know, a 

5
00:00:11,960 --> 00:00:14,960
buzzword. 
It's a real approach to building

6
00:00:14,960 --> 00:00:17,640
software that's robust, 
adaptable. 

7
00:00:18,000 --> 00:00:21,280
Our guide today is Software 
Engineering a Modern Approach by

8
00:00:21,280 --> 00:00:24,400
Marco Tulio Valente. 
Specifically Chapter 7, right? 

9
00:00:24,560 --> 00:00:26,520
The one on building with clean 
architecture. 

10
00:00:26,600 --> 00:00:28,240
Exactly. 
And of course, you can't really 

11
00:00:28,240 --> 00:00:30,960
talk about clean architecture 
without mentioning Robert Martin

12
00:00:30,960 --> 00:00:33,920
or Uncle Bob as most people know
him. 

13
00:00:33,920 --> 00:00:35,840
True, he really championed this 
philosophy. 

14
00:00:35,920 --> 00:00:37,680
And the goals listed in the 
source? 

15
00:00:37,680 --> 00:00:41,160
They're ambitious, high 
reusability, strong cohesion, 

16
00:00:41,320 --> 00:00:44,400
technology independence and 
great testability. 

17
00:00:44,520 --> 00:00:46,640
It sounds like the Holy Grail of
software design. 

18
00:00:46,640 --> 00:00:47,360
Almost. 
It does. 

19
00:00:47,360 --> 00:00:50,080
So the big question for you 
listening in is probably OK, 

20
00:00:50,080 --> 00:00:53,120
how? 
How does 1 architectural pattern

21
00:00:53,120 --> 00:00:56,560
deliver all of that? 
What's the secret sauce here? 

22
00:00:56,640 --> 00:01:00,560
Well, it's a great question and 
fundamentally clean 

23
00:01:00,560 --> 00:01:03,360
architecture. 
It's a layered architecture, a 

24
00:01:03,400 --> 00:01:06,280
sophisticated 1, sure, but 
layers are key. 

25
00:01:06,520 --> 00:01:10,160
It's designed specifically to 
make software resilient, 

26
00:01:10,560 --> 00:01:12,440
adaptable. 
And those diagrams, you always 

27
00:01:12,440 --> 00:01:15,360
see the concentric circles. 
Yeah, those circles are actually

28
00:01:15,360 --> 00:01:17,040
crucial. 
They're not just decoration, 

29
00:01:17,320 --> 00:01:21,680
they visually represent the core
principles, how the separation 

30
00:01:21,680 --> 00:01:24,040
works. 
Strategic separation, OK, I like

31
00:01:24,040 --> 00:01:26,040
that. 
So to get it, we need to start 

32
00:01:26,040 --> 00:01:28,200
right at the center. 
Yeah, the absolute core. 

33
00:01:28,200 --> 00:01:30,680
Exactly. 
Go right to the middle, that 

34
00:01:30,760 --> 00:01:33,320
innermost layer. 
That's where the most stable 

35
00:01:33,320 --> 00:01:36,400
parts of your application live. 
The core business concerns. 

36
00:01:36,400 --> 00:01:38,360
The real essence of what the 
software is for. 

37
00:01:38,360 --> 00:01:41,000
Like totally separate from any 
specific tech. 

38
00:01:41,000 --> 00:01:43,400
Precisely. 
And in that core, there are 

39
00:01:43,400 --> 00:01:46,560
basically two kinds of classes. 
First, you've got entities. 

40
00:01:46,720 --> 00:01:49,120
OK, These are classes often 
shared across multiple systems 

41
00:01:49,120 --> 00:01:51,600
in an organization. 
Think about university example 

42
00:01:51,600 --> 00:01:53,760
from the source. 
Entities would be things like 

43
00:01:53,760 --> 00:01:56,680
student, instructor, course, 
department. 

44
00:01:56,760 --> 00:01:59,280
Things that lots of different 
parts of the university system 

45
00:01:59,280 --> 00:02:02,720
would need to know about, right?
And importantly, they don't just

46
00:02:02,720 --> 00:02:05,520
hold data, they also implement 
generic business rules. 

47
00:02:06,120 --> 00:02:09,240
The source gives the example. 
Maybe a rule like every 

48
00:02:09,240 --> 00:02:11,520
instructor must belong to 
exactly 1 department. 

49
00:02:11,520 --> 00:02:13,480
That's a core business fact. 
Got it. 

50
00:02:13,480 --> 00:02:16,200
Not tied to how you store 
instructors, just a. 

51
00:02:16,200 --> 00:02:19,520
Rule exactly. 
Then still in that inner circle 

52
00:02:19,520 --> 00:02:21,720
you have use cases. 
Use cases. 

53
00:02:22,040 --> 00:02:24,720
OK, these classes handle the 
specific operations for this 

54
00:02:24,720 --> 00:02:28,240
system's domain. 
Sticking with the university use

55
00:02:28,240 --> 00:02:31,160
cases might be things like 
creating a new class, enrolling 

56
00:02:31,160 --> 00:02:34,280
a student, cancelling an 
enrollment, maybe recording 

57
00:02:34,280 --> 00:02:38,560
subjects covered in a lecture. 
So the actions, the verbs kind 

58
00:02:38,600 --> 00:02:41,520
of to the entities nouns. 
That's a good way to put it. 

59
00:02:41,760 --> 00:02:44,840
These are the specific processes
the system enables. 

60
00:02:44,920 --> 00:02:47,680
So these central layers, I mean,
this is where the real value, 

61
00:02:47,960 --> 00:02:50,040
the intellectual property lives,
right? 

62
00:02:50,120 --> 00:02:53,360
Free from all the messy details 
of databases or I don't know, 

63
00:02:53,440 --> 00:02:56,280
front end frameworks. 
Exactly, Imagine trying to 

64
00:02:56,280 --> 00:02:59,080
change a core policy and finding
it tangled up with sequel 

65
00:02:59,080 --> 00:03:00,560
statements. 
It's a common headache. 

66
00:03:01,120 --> 00:03:04,240
Clean Architecture keeps these 
rules pure insulated. 

67
00:03:04,680 --> 00:03:07,200
You define the business first, 
then worry about tech. 

68
00:03:07,440 --> 00:03:10,560
OK, That makes a lot of sense. 
So moving out one layer from 

69
00:03:10,560 --> 00:03:14,680
that core, we get to the 
adapters, what role do they 

70
00:03:14,680 --> 00:03:16,760
play? 
They sound like middle men. 

71
00:03:16,840 --> 00:03:20,680
They are crucial intermediaries,
maybe skilled translators is 

72
00:03:20,800 --> 00:03:23,320
good analogy. 
They manage the conversation 

73
00:03:23,320 --> 00:03:25,360
between the inner core and the 
outside world. 

74
00:03:26,040 --> 00:03:30,200
So adapters are classes and 
interfaces that well they adapt.

75
00:03:30,600 --> 00:03:33,320
They mediate between the 
external parts like UIS, 

76
00:03:33,560 --> 00:03:38,160
databases, external services and
that central business logic, the

77
00:03:38,160 --> 00:03:41,880
use cases and entities. 
So take a system with a REST API

78
00:03:42,240 --> 00:03:44,960
that the source mentions this. 
The adapters would be the 

79
00:03:44,960 --> 00:03:47,120
classes implementing those API 
endpoints. 

80
00:03:47,600 --> 00:03:50,440
They get a request, figure out 
which use case needs it and pass

81
00:03:50,440 --> 00:03:51,880
it. 
On and then handle the response 

82
00:03:51,880 --> 00:03:52,840
coming back. 
Exactly. 

83
00:03:52,840 --> 00:03:55,440
They take the result from the 
use case, maybe format it as 

84
00:03:55,440 --> 00:03:57,640
Jason, and send it back to the 
front end. 

85
00:03:57,920 --> 00:04:00,200
It ensures the core logic 
doesn't need to know anything 

86
00:04:00,200 --> 00:04:03,200
about Http://orjason. 
Like skilled translators, as you

87
00:04:03,200 --> 00:04:05,840
said, making sure everyone 
understands each other even if 

88
00:04:05,840 --> 00:04:08,920
they speak different technical 
languages, keeps the core clean.

89
00:04:08,920 --> 00:04:10,520
Precisely, it protects that 
core. 

90
00:04:10,760 --> 00:04:15,760
OK, so that naturally leads us 
to the outermost layer, the edge

91
00:04:15,760 --> 00:04:18,200
of the circles. 
This is where What did the 

92
00:04:18,200 --> 00:04:21,839
source say all the details go? 
That's the phrase, and it's very

93
00:04:21,839 --> 00:04:23,960
apartment. 
This outer layer is home to 

94
00:04:24,480 --> 00:04:27,480
classes from libraries, 
frameworks, external systems, 

95
00:04:27,760 --> 00:04:29,680
all the specific technologies 
you're using. 

96
00:04:29,680 --> 00:04:32,280
So like. 
Database drivers, E-mail 

97
00:04:32,280 --> 00:04:33,400
library. 
Exactly. 

98
00:04:33,480 --> 00:04:36,840
Databases, e-mail services, 
payment gateway integrations, 

99
00:04:36,840 --> 00:04:38,520
maybe talking to specific 
hardware. 

100
00:04:38,520 --> 00:04:41,560
The university example mentioned
using a third party credit card 

101
00:04:41,560 --> 00:04:43,080
provider for extension courses, 
right? 

102
00:04:43,480 --> 00:04:45,840
The class this is for that 
specific provider would live out

103
00:04:45,840 --> 00:04:48,320
here. 
They're details from the core 

104
00:04:48,320 --> 00:04:52,160
business perspective. 
Uncle Bob in his own book really

105
00:04:52,160 --> 00:04:54,240
hammers this home. 
He says the frameworks and 

106
00:04:54,240 --> 00:04:56,240
drivers layer is where all the 
details go. 

107
00:04:56,520 --> 00:04:58,840
The web is a detail, the 
database is a detail. 

108
00:04:58,920 --> 00:05:01,560
We keep these things on the 
outside where they can do little

109
00:05:01,560 --> 00:05:02,720
harm. 
Little harm. 

110
00:05:02,760 --> 00:05:05,160
I like that it implies they 
could do harm if they were mixed

111
00:05:05,160 --> 00:05:07,080
in with the core logic. 
They absolutely could. 

112
00:05:07,240 --> 00:05:10,120
Changes in those details could 
ripple inwards and break things.

113
00:05:10,320 --> 00:05:15,280
So the big take away here is 
your core business logic. 

114
00:05:15,720 --> 00:05:18,760
Those entities and use cases, 
they just don't care. 

115
00:05:19,160 --> 00:05:23,040
SQL no SQL, send grid, mail gun 
doesn't matter to the core. 

116
00:05:23,040 --> 00:05:25,200
Correct. 
That core is insulated, 

117
00:05:25,200 --> 00:05:27,320
protected. 
Focus purely on the business 

118
00:05:27,320 --> 00:05:28,600
rules. 
That's how you get that 

119
00:05:28,600 --> 00:05:31,560
technology independence. 
You can swap out details more 

120
00:05:31,560 --> 00:05:33,800
easily. 
That sounds incredibly powerful 

121
00:05:33,800 --> 00:05:38,320
for future proofing, but OK, 
this strict separation, how is 

122
00:05:38,320 --> 00:05:42,480
it actually enforced, especially
if, say, a use case needs to 

123
00:05:42,480 --> 00:05:44,000
trigger something in an outer 
layer? 

124
00:05:44,200 --> 00:05:46,000
This leads us to the dependency 
rule, right? 

125
00:05:46,000 --> 00:05:48,120
Yes, the dependency rule is 
absolutely fundamental. 

126
00:05:48,120 --> 00:05:51,000
It's the bedrock principle that 
makes this architecture work. 

127
00:05:51,480 --> 00:05:54,640
So what is it exactly? 
Simply put, code in an inner 

128
00:05:54,640 --> 00:05:57,000
layer cannot reference anything 
in an outer layer. 

129
00:05:57,320 --> 00:05:59,240
No direct dependencies pointing 
inwards. 

130
00:05:59,240 --> 00:06:01,080
Nothing. 
No classes functions. 

131
00:06:01,080 --> 00:06:03,080
Nothing. 
Uncle Bob is very clear. 

132
00:06:03,320 --> 00:06:06,320
Nothing in an inner circle can 
know anything at all about 

133
00:06:06,320 --> 00:06:09,000
something in an outer circle. 
In particular, the name of 

134
00:06:09,000 --> 00:06:11,320
something declared in an outer 
circle must not be mentioned by 

135
00:06:11,320 --> 00:06:13,240
the code. 
In an inner circle that 

136
00:06:13,240 --> 00:06:15,640
includes, yeah, functions, 
classes, variables, anything 

137
00:06:15,640 --> 00:06:17,040
named. 
Wow, that's strict. 

138
00:06:17,120 --> 00:06:19,320
It has to be. 
The benefit is huge. 

139
00:06:19,960 --> 00:06:23,040
It makes those inner layers, the
entities and use cases, 

140
00:06:23,240 --> 00:06:26,440
incredibly stable. 
They don't change just because 

141
00:06:26,440 --> 00:06:29,640
you decided to switch database 
vendors or adopt A new 

142
00:06:29,640 --> 00:06:31,400
JavaScript framework. 
Because they literally don't 

143
00:06:31,400 --> 00:06:32,640
know about them. 
Exactly. 

144
00:06:33,160 --> 00:06:36,040
The business logic is shielded 
from technological churn. 

145
00:06:36,480 --> 00:06:39,400
You avoid those cascading 
changes where updating a library

146
00:06:39,400 --> 00:06:42,160
forces changes deep in your core
logic. 

147
00:06:42,200 --> 00:06:43,920
OK. 
So that's what really keeps the 

148
00:06:43,920 --> 00:06:46,760
core clean. 
It's this strict dependency 

149
00:06:46,760 --> 00:06:49,640
management discipline is key it 
sounds like. 

150
00:06:49,640 --> 00:06:51,080
It definitely requires 
discipline. 

151
00:06:51,080 --> 00:06:55,040
But then the obvious question 
arises, what if an inner layer, 

152
00:06:55,040 --> 00:06:58,440
like a use case for enrolling a 
student, needs to do something 

153
00:06:58,440 --> 00:07:01,760
that involves an outer layer, 
like sending a confirmation 

154
00:07:01,760 --> 00:07:04,120
e-mail? 
The e-mail service logic is way 

155
00:07:04,120 --> 00:07:07,120
out there in the details layer. 
A direct call is forbidden by 

156
00:07:07,120 --> 00:07:09,240
the rule. 
Right, direct calls would break 

157
00:07:09,240 --> 00:07:11,120
the architecture. 
So how do you solve that? 

158
00:07:11,120 --> 00:07:14,080
How does the inside talk to the 
outside without violating the 

159
00:07:14,080 --> 00:07:16,320
rule? 
This is where the elegance of 

160
00:07:16,320 --> 00:07:19,160
Inversion of Control comes in, 
usually implemented with 

161
00:07:19,160 --> 00:07:20,720
interface. 
In version of control. 

162
00:07:20,720 --> 00:07:23,440
OK, how does that work here? 
So instead of the use case 

163
00:07:23,440 --> 00:07:27,120
directly calling say a mail 
service simple class in the 

164
00:07:27,120 --> 00:07:28,840
outer layer. 
Which you can't do which. 

165
00:07:28,840 --> 00:07:31,280
You can't do. 
Instead you define an interface 

166
00:07:31,280 --> 00:07:33,800
right there in the inner use 
case layer, let's call it Mail 

167
00:07:33,800 --> 00:07:36,560
Service interface. 
It just defines what needs to be

168
00:07:36,560 --> 00:07:39,440
done, like a method send 
recipient message. 

169
00:07:39,600 --> 00:07:43,360
So the use case only knows about
this abstract interface defined 

170
00:07:43,360 --> 00:07:46,480
right next to it. 
Precisely the use case depends 

171
00:07:46,480 --> 00:07:49,920
only on this abstraction. 
Mail service interface, then way

172
00:07:49,920 --> 00:07:51,720
out in the external frameworks 
layer. 

173
00:07:52,200 --> 00:07:55,440
Your concrete mail service 
simple class implements that 

174
00:07:55,440 --> 00:07:57,000
mail service interface. 
I see. 

175
00:07:57,000 --> 00:07:58,800
So the dependency arrow is 
flipped. 

176
00:07:58,800 --> 00:08:02,400
The outer layer implementation 
now depends on the inner layer 

177
00:08:02,400 --> 00:08:03,520
interface. 
Exactly. 

178
00:08:03,560 --> 00:08:05,760
The control of which 
implementation gets used is 

179
00:08:05,760 --> 00:08:07,640
inverted. 
The inner layer defines the 

180
00:08:07,640 --> 00:08:10,120
contract, the interface. 
The outer layer provides the 

181
00:08:10,120 --> 00:08:12,800
implementation. 
The source has a class diagram 

182
00:08:12,800 --> 00:08:15,800
showing this flow, how the 
dependencies point inwards 

183
00:08:15,800 --> 00:08:19,040
towards abstractions. 
That is genuinely clever because

184
00:08:19,040 --> 00:08:21,880
the use case can trigger the 
e-mail sending via the 

185
00:08:21,880 --> 00:08:25,120
interface, but it has zero 
knowledge of how it's sent or 

186
00:08:25,120 --> 00:08:28,480
which service is doing it. 
The separation is maintained. 

187
00:08:28,520 --> 00:08:31,000
Perfectly maintained. 
You could swap mail service 

188
00:08:31,000 --> 00:08:34,159
input for another mail service 
input tomorrow, and as long as 

189
00:08:34,159 --> 00:08:37,120
it implement the mail service 
interface, the use case layer 

190
00:08:37,120 --> 00:08:39,120
doesn't change. 
Not one line of code. 

191
00:08:39,240 --> 00:08:42,480
That's the real power, 
adaptability without rewriting 

192
00:08:42,480 --> 00:08:45,480
your core logic. 
OK, so we've walked through the 

193
00:08:45,480 --> 00:08:48,720
layers, the crucial dependency 
rule and this smart inversion of

194
00:08:48,720 --> 00:08:50,720
control solution. 
Let's zoom out. 

195
00:08:50,920 --> 00:08:54,120
Why go through all this effort? 
What's the big picture benefit 

196
00:08:54,120 --> 00:08:56,040
for you, the listener, The 
developer? 

197
00:08:56,040 --> 00:08:59,080
Well, it connects directly back 
to those core software 

198
00:08:59,080 --> 00:09:02,000
engineering concepts we always 
talk about and that the source 

199
00:09:02,000 --> 00:09:04,240
emphasizes. 
Clean architecture isn't just 

200
00:09:04,240 --> 00:09:06,840
some isolated idea, it's 
strongly promotes things like 

201
00:09:07,000 --> 00:09:10,160
high cohesion within layers, 
loose coupling between layers, 

202
00:09:10,360 --> 00:09:13,040
and a very clear separation of 
concerns makes sense. 

203
00:09:13,280 --> 00:09:16,560
It also heavily relies on 
principles like single 

204
00:09:16,560 --> 00:09:21,320
responsibility, each layer, each
class having a clear purpose and

205
00:09:21,320 --> 00:09:24,280
as we just saw dependency 
inversion and we talked about 

206
00:09:24,280 --> 00:09:26,160
the adapter pattern being used 
explicitly. 

207
00:09:26,160 --> 00:09:28,400
So it brings together a lot of 
best practices. 

208
00:09:28,400 --> 00:09:31,280
It really does, and the source 
boils down the recommendations 

209
00:09:31,280 --> 00:09:34,160
quite nicely. 
First, start by defining your 

210
00:09:34,160 --> 00:09:36,680
entities, those core data 
structures and generic rules. 

211
00:09:36,680 --> 00:09:40,240
Right, the shared stuff. 
Then focus on the use cases this

212
00:09:40,520 --> 00:09:44,000
specific business operations for
this application, but keep them 

213
00:09:44,040 --> 00:09:48,080
totally technology agnostic. 
Remember the web is a detail, 

214
00:09:48,440 --> 00:09:50,040
the database is a detail. 
Keep. 

215
00:09:50,040 --> 00:09:51,640
Chanting that mantra. 
Pretty much. 

216
00:09:52,120 --> 00:09:55,360
And finally, design the adapter 
classes, those intermediaries 

217
00:09:55,640 --> 00:09:58,400
that handle the translation 
between the pure core and the 

218
00:09:58,400 --> 00:10:01,880
messy outside world. 
Entities use cases, then 

219
00:10:01,880 --> 00:10:05,320
adapters focus inward, then 
build the bridges outward. 

220
00:10:05,400 --> 00:10:06,680
That's a great way to summarize 
it. 

221
00:10:06,760 --> 00:10:09,320
And if you follow that path, the
ultimate benefit is an 

222
00:10:09,320 --> 00:10:11,800
architecture that cleanly 
separates business interests 

223
00:10:12,120 --> 00:10:14,280
from technology interests. 
Which means which means your 

224
00:10:14,280 --> 00:10:16,280
system becomes way easier to 
test. 

225
00:10:16,920 --> 00:10:20,240
You can test core logic without 
databases or UIS. 

226
00:10:20,640 --> 00:10:24,240
And crucially, it's far easier 
to adapt to new technologies 

227
00:10:24,240 --> 00:10:26,400
down the road. 
You're not locked in. 

228
00:10:26,720 --> 00:10:30,640
So less pain when the next big 
framework arrives or when you 

229
00:10:30,640 --> 00:10:33,240
need to switch cloud providers 
or database types. 

230
00:10:33,240 --> 00:10:35,200
Exactly. 
It's about building for change, 

231
00:10:35,200 --> 00:10:38,560
building for the long term. 
It's about protecting your core 

232
00:10:38,560 --> 00:10:41,480
business value from the 
turbulence of technology trends.

233
00:10:41,880 --> 00:10:44,080
Easier testing, easier 
adaptation. 

234
00:10:44,400 --> 00:10:47,760
That's the promise, and when 
done well, Clean Architecture 

235
00:10:47,760 --> 00:10:49,400
delivers. 
It sounds like it's about 

236
00:10:49,400 --> 00:10:52,760
building software that embraces 
change, not fights it. 

237
00:10:52,920 --> 00:10:55,600
That's it perfectly. 
In today's tech landscape, which

238
00:10:55,600 --> 00:10:57,640
just keeps evolving faster and 
faster. 

239
00:10:57,760 --> 00:11:00,960
Building software that embraces 
change, well, it isn't just good

240
00:11:00,960 --> 00:11:03,600
practice anymore, It's pretty 
essential for longevity. 

241
00:11:03,800 --> 00:11:06,120
A really powerful idea to keep 
in mind. 

242
00:11:06,160 --> 00:11:08,320
Thank you for joining us on this
deep dive into Clean 

243
00:11:08,320 --> 00:11:10,200
architecture today. 
Hopefully you feel a bit more 

244
00:11:10,200 --> 00:11:12,760
equipped to think about these 
layers and dependencies in your 

245
00:11:12,760 --> 00:11:13,520
own projects.