1
00:00:00,100 --> 00:00:01,790
Welcome to the architecture 
corner. 

2
00:00:01,880 --> 00:00:04,710
Today we're jumping into 
something that, well, I guess 

3
00:00:04,720 --> 00:00:06,440
people really talking in 
software development. 

4
00:00:06,450 --> 00:00:09,450
We're looking at finding that 
sweet spot, that balance with 

5
00:00:09,460 --> 00:00:13,230
all these popular patterns, 
things like solid, clean code, 

6
00:00:13,280 --> 00:00:16,630
hexagonal architecture, domain 
driven design. 

7
00:00:16,640 --> 00:00:18,770
It feels like you're always 
caught between the people 

8
00:00:18,840 --> 00:00:23,330
shouting always use this and the
one saying never touch that. 

9
00:00:23,400 --> 00:00:27,190
Right, absolutely. 
And our goal here is really to 

10
00:00:27,200 --> 00:00:30,070
cut through some of that noise. 
We want to explore why. 

11
00:00:30,080 --> 00:00:32,940
Just saying always or never 
doesn't really help. 

12
00:00:32,950 --> 00:00:35,680
It almost always comes down to 
understanding your specific 

13
00:00:35,690 --> 00:00:38,520
situation, your context. 
That's what guides the really 

14
00:00:38,530 --> 00:00:40,710
effective decisions. 
Think about it, are you 

15
00:00:40,720 --> 00:00:42,960
building, say, a quick internal 
prototype? 

16
00:00:43,030 --> 00:00:46,160
Or is it the core payment system
for a huge online bank? 

17
00:00:46,170 --> 00:00:47,680
The way you'd use these 
patterns? 

18
00:00:47,890 --> 00:00:49,810
Totally different. 
That's a really good way to put 

19
00:00:49,820 --> 00:00:52,840
it because you see these 
discussions online and they get 

20
00:00:52,850 --> 00:00:56,620
so intense, often driven by, you
know, someone specific past 

21
00:00:56,630 --> 00:00:59,960
project or experience. 
So OK, let's unpack the first 

22
00:00:59,970 --> 00:01:02,050
side. 
You have the critics, the ones 

23
00:01:02,060 --> 00:01:04,080
who say these patterns just add 
complexity. 

24
00:01:04,090 --> 00:01:06,800
We don't need to talk about 
increasing cognitive load. 

25
00:01:06,810 --> 00:01:07,900
Right. 
Yeah, exactly. 

26
00:01:07,910 --> 00:01:10,890
Cognitive load, basically how 
much a developer has to keep in 

27
00:01:10,900 --> 00:01:13,700
their head just to understand or
change something. 

28
00:01:13,930 --> 00:01:16,960
And they do have a point 
sometimes if like a simple 

29
00:01:16,970 --> 00:01:19,860
request has to go through 5 
layers of abstraction, tons of 

30
00:01:19,870 --> 00:01:23,300
interfaces mapping this to that 
for something that could be 

31
00:01:23,310 --> 00:01:26,740
well, simpler, that is a lot of 
mental overhead. 

32
00:01:26,750 --> 00:01:31,280
It can make the code harder to 
grasp, slower to work with for, 

33
00:01:31,290 --> 00:01:34,010
let's say a smaller application,
all that structure, that sort of

34
00:01:34,020 --> 00:01:36,130
ceremony, it really might do 
more harm than good. 

35
00:01:36,360 --> 00:01:37,930
OK, so that's the keep it 
simple. 

36
00:01:37,940 --> 00:01:40,550
Maybe too simple right side. 
But then you've got the other 

37
00:01:40,560 --> 00:01:44,030
camp, equally passionate, saying
you should use things like 

38
00:01:44,040 --> 00:01:47,130
hexagonal architecture or DVD. 
Almost like it's a rule. 

39
00:01:47,180 --> 00:01:49,570
Right, and their argument 
focuses on the benefits. 

40
00:01:49,580 --> 00:01:52,410
You get. 
Clear responsibilities for 

41
00:01:52,420 --> 00:01:55,990
different code parts, good 
isolation, so changes here don't

42
00:01:56,000 --> 00:01:57,970
accidentally break things over 
there. 

43
00:01:58,040 --> 00:02:00,990
They see these patterns as sort 
of established best practices 

44
00:02:01,000 --> 00:02:03,610
for building solid, maintainable
software. 

45
00:02:03,700 --> 00:02:06,250
The danger, though, is when it 
becomes dogmatic. 

46
00:02:06,300 --> 00:02:08,910
You know, just using the pattern
because it's the pattern, 

47
00:02:09,030 --> 00:02:11,990
without really asking why it's 
the right choice for this 

48
00:02:12,000 --> 00:02:14,510
specific project. 
You might get perfect isolation,

49
00:02:14,520 --> 00:02:17,570
sure, but maybe it's massively 
overengineered for what you 

50
00:02:17,580 --> 00:02:19,430
actually needed. 
What's the trade off there? 

51
00:02:19,440 --> 00:02:21,230
That. 
Really is the crux of it, isn't 

52
00:02:21,240 --> 00:02:22,510
it? 
It feels like you can't win 

53
00:02:22,520 --> 00:02:24,450
sometimes. 
How do we reconcile? 

54
00:02:24,460 --> 00:02:27,690
These both sound kind of right 
in their own way. 

55
00:02:27,760 --> 00:02:30,550
And they are, sort of. 
This is where we have to hammer 

56
00:02:30,560 --> 00:02:33,730
home the idea of context. 
Neither viewpoint is just plain 

57
00:02:33,740 --> 00:02:35,610
wrong. 
Are playing right without 

58
00:02:35,620 --> 00:02:38,470
considering the specifics, the 
projects needs, the team's 

59
00:02:38,480 --> 00:02:41,910
experience, the expected 
lifespan, the budget, all of it 

60
00:02:41,920 --> 00:02:44,090
matters. 
These patterns, these 

61
00:02:44,100 --> 00:02:45,950
architectures, they're powerful 
tools. 

62
00:02:45,960 --> 00:02:49,250
They're valuable, but only when 
they're really understood and 

63
00:02:49,260 --> 00:02:52,050
applied appropriately. 
The problems usually pop up when

64
00:02:52,060 --> 00:02:54,710
people rush in, maybe grab a 
pattern because it's popular 

65
00:02:54,780 --> 00:02:57,530
without fully getting the 
implications, or crucially, 

66
00:02:57,540 --> 00:03:00,320
without feedback loops to see if
it's actually working well. 

67
00:03:00,440 --> 00:03:03,440
So it's less about knowing the 
patterns name and more about 

68
00:03:03,450 --> 00:03:05,910
knowing when and how much of it 
to apply. 

69
00:03:06,210 --> 00:03:09,380
Could you maybe give an example?
Like how would context lead you 

70
00:03:09,390 --> 00:03:12,090
to adapt or simplify? 
What is just enough ceremony to 

71
00:03:12,100 --> 00:03:14,160
look? 
Like, OK, yeah, let's take that 

72
00:03:14,170 --> 00:03:18,300
internal admin tool versus say a
big public ecommerce site. 

73
00:03:18,390 --> 00:03:22,780
Both need to manage users, maybe
save data for the internal tool,

74
00:03:22,830 --> 00:03:25,940
maybe just for a dozen users 
doing full blown domain driven 

75
00:03:25,950 --> 00:03:29,440
design with complex models, 
repositories, layers of mapping.

76
00:03:29,530 --> 00:03:32,640
Probably overkill, right? 
You might simplify a lot, maybe 

77
00:03:32,650 --> 00:03:34,980
use simpler data objects, basic 
service layer. 

78
00:03:34,990 --> 00:03:38,210
You trade off some purity for 
speed and less complexity. 

79
00:03:38,220 --> 00:03:41,340
That's just enough there. 
But for the high traffic 

80
00:03:41,350 --> 00:03:45,200
ecommerce site needs to be super
robust, scalable, easy to change

81
00:03:45,210 --> 00:03:47,860
parts independently. 
There the investment in 

82
00:03:47,870 --> 00:03:50,940
something like hexagonal 
architecture or D, that upfront 

83
00:03:50,950 --> 00:03:53,580
ceremony probably pays off big 
time in the long run. 

84
00:03:53,590 --> 00:03:56,940
So the scale, the team, the 
future needs, they dictate how 

85
00:03:56,950 --> 00:03:59,700
much structure is just enough. 
That makes it much clearer. 

86
00:03:59,750 --> 00:04:02,120
It's not about having the 
fanciest tools, but about being 

87
00:04:02,130 --> 00:04:04,900
a good craftsperson who knows 
when to use which one. 

88
00:04:04,950 --> 00:04:07,940
So the big take away seems to be
really understand your specific 

89
00:04:07,950 --> 00:04:11,420
situation, grasp the principles 
behind the patterns, and always,

90
00:04:11,430 --> 00:04:12,920
always think about the 
tradeoffs. 

91
00:04:13,050 --> 00:04:15,420
Precisely. 
And getting that understanding, 

92
00:04:15,490 --> 00:04:18,250
that's not optional. 
It's an ongoing process. 

93
00:04:18,260 --> 00:04:21,300
You have to keep learning, keep 
evaluating, avoid just doing 

94
00:04:21,310 --> 00:04:24,130
things by rote. 
That kind of thoughtful, 

95
00:04:24,140 --> 00:04:27,850
adaptive approach is how you 
actually get the benefits, the 

96
00:04:27,860 --> 00:04:30,430
maintainability, the clarity 
with church, the right amount of

97
00:04:30,440 --> 00:04:34,290
effort that just enough ceremony
for your project to succeed. 

98
00:04:34,560 --> 00:04:38,670
So we've seen why just blindly 
following or completely 

99
00:04:38,680 --> 00:04:41,570
rejecting these software 
patterns doesn't really work 

100
00:04:41,580 --> 00:04:43,550
out. 
The key, as author Mario 

101
00:04:43,560 --> 00:04:45,930
Bittencourt really highlights, 
is that deep understanding of 

102
00:04:45,940 --> 00:04:48,540
your context and the the why 
behind the tools. 

103
00:04:48,550 --> 00:04:50,990
Maybe something for you, the 
listener, to think about where 

104
00:04:51,000 --> 00:04:53,770
in your own work it's stepping 
back and really looking at the 

105
00:04:53,780 --> 00:04:56,430
context lead to a better, maybe 
simpler solution. 

106
00:04:56,540 --> 00:04:58,790
You can find more details about 
this discussion LinkedIn the 

107
00:04:58,800 --> 00:05:01,880
description, and Please remember
to subscribe for free to the 

108
00:05:01,890 --> 00:05:03,590
Architecture Corner newsletter 
over at 

109
00:05:03,600 --> 00:05:05,330
architecturecorner.substrate.com.