1
00:00:00,000 --> 00:00:03,000
Hey, a quick message, for those 
of you who are listening to this

2
00:00:03,000 --> 00:00:07,500
episode on Spotify, I have a 
small favor to ask Spotify. 

3
00:00:07,500 --> 00:00:11,000
Now allows mobile users to rate 
podcasts, I would really 

4
00:00:11,000 --> 00:00:13,500
appreciate it. 
If you can take a quick pass to 

5
00:00:13,500 --> 00:00:16,100
go to the technique Journal 
podcast page, and leave your 

6
00:00:16,100 --> 00:00:18,700
favorite show, your best rating 
on Spotify. 

7
00:00:19,200 --> 00:00:21,800
It will help me a lot to get 
this podcast to reach more 

8
00:00:21,800 --> 00:00:24,300
people on the platform. 
Thanks a lot. 

9
00:00:26,900 --> 00:00:30,500
Today's clip is from package, 
you know, episode 76 Six with 

10
00:00:30,500 --> 00:00:34,300
blood like Conan off the author 
of learning domain driven design

11
00:00:34,700 --> 00:00:37,300
in this clip. 
Bloody shared why understanding 

12
00:00:37,300 --> 00:00:41,500
business domain is crucial in 
software engineering and how DDD

13
00:00:41,500 --> 00:00:44,300
can help build the shared 
understanding between the domain

14
00:00:44,300 --> 00:00:48,100
experts and software Engineers. 
Vlad also explained the 

15
00:00:48,100 --> 00:00:53,200
importance of dedede's strategic
design So I read that particular

16
00:00:53,200 --> 00:00:56,500
preface in the book as well. 
Your story about starting in 

17
00:00:56,500 --> 00:01:00,000
this new company and you thought
that you will learn a lot of 

18
00:01:00,000 --> 00:01:03,600
things about software, and the 
business logic, which apparently

19
00:01:03,600 --> 00:01:07,900
was not emphasized and actually 
bdd actually emphasize these 

20
00:01:07,900 --> 00:01:11,500
importance of business logic or 
domain in this particular sense.

21
00:01:11,700 --> 00:01:15,200
Why do you think domain is still
the key thing in software? 

22
00:01:15,200 --> 00:01:17,300
Because these days a lot of 
Technologies, right? 

23
00:01:17,300 --> 00:01:20,500
So there are plenty abundant 
Frameworks programming language 

24
00:01:20,800 --> 00:01:23,400
cloud. 
Rubber that is, why do you think

25
00:01:23,400 --> 00:01:26,400
business logic is still the tea 
in this modern era? 

26
00:01:27,100 --> 00:01:30,200
Yeah, so business logic is hard 
of software. 

27
00:01:30,200 --> 00:01:33,900
For reason is the reason suffers
being built, you're not building

28
00:01:33,900 --> 00:01:38,400
software to demonstrate how fast
and scalable your databases or 

29
00:01:38,400 --> 00:01:42,200
how sexy your user interfaces 
your billing software for 

30
00:01:42,200 --> 00:01:44,100
solving a particular business 
problem. 

31
00:01:44,300 --> 00:01:47,000
This problem can be making 
someone more efficient 

32
00:01:47,000 --> 00:01:50,100
streamlining, business 
processes, nowadays, many 

33
00:01:50,100 --> 00:01:53,200
businesses are built on. 
On software, that's their 

34
00:01:53,200 --> 00:01:55,400
business domain. 
So that's where a business logic

35
00:01:55,400 --> 00:01:58,000
steps in. 
If you've got everything right, 

36
00:01:58,000 --> 00:02:01,200
except for business logic, 
you'll get technology demo for 

37
00:02:01,200 --> 00:02:05,000
computer game looks nice, but 
you look at it for a few minutes

38
00:02:05,000 --> 00:02:07,200
and then you get bored because 
it's meaningless. 

39
00:02:08,300 --> 00:02:11,600
So, you also mentioned in the 
book that actually DDD brings 

40
00:02:11,600 --> 00:02:15,300
not just software developers as 
the important actors in the 

41
00:02:15,300 --> 00:02:18,800
software development life cycle.
But actually also the business 

42
00:02:18,800 --> 00:02:22,600
domain experts tell us more 
about this, Business domain 

43
00:02:22,600 --> 00:02:25,700
experts should be involved in 
the overall software development

44
00:02:25,700 --> 00:02:28,800
life cycle. 
We are so, that's actually the 

45
00:02:28,800 --> 00:02:32,200
biggest lie of software 
engineering and it's to be a 

46
00:02:32,208 --> 00:02:35,300
software engineer. 
You have to write code and I am 

47
00:02:35,300 --> 00:02:39,300
an introvert to the Bone. 
After some time, realized, hey, 

48
00:02:39,300 --> 00:02:42,100
we're not trading called, for 
the sake of writing code, we are

49
00:02:42,108 --> 00:02:44,800
writing code to solve a problem 
for someone. 

50
00:02:45,100 --> 00:02:47,300
This, someone they are a domain 
experts. 

51
00:02:47,800 --> 00:02:50,400
There are people who have the 
most knowledge about the 

52
00:02:50,400 --> 00:02:53,300
business domain that we We're 
modeling and implemented in 

53
00:02:53,300 --> 00:02:55,800
code. 
So, in order to efficiently, 

54
00:02:55,800 --> 00:02:59,400
solve that problem, we have to 
communicate with them, talk with

55
00:02:59,400 --> 00:03:02,500
that, we have to be effective in
that communication and 

56
00:03:02,500 --> 00:03:06,200
collaboration with people. 
So, software engineering is not 

57
00:03:06,200 --> 00:03:09,100
only about code. 
That's why interactions with 

58
00:03:09,100 --> 00:03:12,400
domain experts plays, a key role
in implementing software. 

59
00:03:12,400 --> 00:03:16,200
You have to make sure that you 
understand the problem, you're 

60
00:03:16,200 --> 00:03:19,100
solving, that's critical. 
You cannot provide a software 

61
00:03:19,100 --> 00:03:21,000
solution without understanding 
the problem. 

62
00:03:21,000 --> 00:03:22,900
First. 
There is going to be a wrong 

63
00:03:22,900 --> 00:03:24,200
solution. 
Always going to be the right 

64
00:03:24,200 --> 00:03:27,900
solution but for a different 
problem and both are useless. 

65
00:03:28,700 --> 00:03:30,500
Yep. 
And that's a critical point in 

66
00:03:30,500 --> 00:03:31,800
the book that you mention as 
well. 

67
00:03:31,900 --> 00:03:36,100
If you fail to understand the 
business problem or maybe the 

68
00:03:36,100 --> 00:03:38,600
problem per se, the user 
problems or the customer 

69
00:03:38,600 --> 00:03:42,400
problems, you will eventually 
write a suboptimal solution, 

70
00:03:42,600 --> 00:03:44,900
even though your technology 
might be Advanced the most 

71
00:03:45,000 --> 00:03:48,400
advanced in the current ERA, but
your software is always 

72
00:03:48,400 --> 00:03:51,000
suboptimal. 
What do you mean by this can 

73
00:03:51,000 --> 00:03:53,100
technology? 
We actually solve how your 

74
00:03:53,100 --> 00:03:56,300
software is being written, why? 
It's always be suboptimal. 

75
00:03:57,000 --> 00:03:59,400
Yeah. 
So if we take this name of this 

76
00:03:59,400 --> 00:04:03,200
methodology domain-driven 
design, I prefer to expand it a 

77
00:04:03,208 --> 00:04:07,400
bit and say, business domain 
driven software design. 

78
00:04:07,700 --> 00:04:09,700
So we have three components 
here. 

79
00:04:09,700 --> 00:04:12,600
First of all, we have business 
domain that we have to grasp. 

80
00:04:12,600 --> 00:04:16,399
We have to understand, second, 
we have software design, that's 

81
00:04:16,399 --> 00:04:19,700
what we are building here. 
And we have that word driven in 

82
00:04:19,700 --> 00:04:23,200
the middle which means in 
Mathematical language, slyke 

83
00:04:23,400 --> 00:04:26,700
sorcerer design equals function 
of business domain. 

84
00:04:26,700 --> 00:04:29,700
So if you don't get that 
business domain, dried and 

85
00:04:29,700 --> 00:04:31,700
you'll get your own software 
design. 

86
00:04:32,000 --> 00:04:35,200
First of all, it's going to 
affect the logic of your code. 

87
00:04:35,200 --> 00:04:39,000
As I said, you may be solving 
the wrong problem, or you may be

88
00:04:39,100 --> 00:04:41,900
trying to solve the correct 
problem, but in an inefficient 

89
00:04:41,900 --> 00:04:44,200
ways. 
Second, as the measurement, 

90
00:04:44,200 --> 00:04:48,000
design guides us, there are 
quite a few design decisions 

91
00:04:48,000 --> 00:04:51,400
that were basing upon that 
knowledge of business, domains 

92
00:04:51,600 --> 00:04:55,300
So that strategic design 
decisions, like what are the 

93
00:04:55,300 --> 00:04:59,200
coarse-grained components that 
we are going to use to implement

94
00:04:59,200 --> 00:05:00,700
our system? 
How are they are going to 

95
00:05:00,707 --> 00:05:04,000
communicate with each other? 
How we allocate that work to 

96
00:05:04,000 --> 00:05:06,900
suffer engineering teams? 
And we have technical design 

97
00:05:06,900 --> 00:05:09,800
decisions. 
Like what design patterns were 

98
00:05:09,800 --> 00:05:13,200
going to use to implement each 
components, how we're going to 

99
00:05:13,200 --> 00:05:15,900
implement its business logic. 
How we're going to orchestrate 

100
00:05:15,900 --> 00:05:19,600
the interactions of different 
parts of a component. 

101
00:05:19,700 --> 00:05:23,000
It's our internal architecture. 
Of course we have high-level 

102
00:05:23,000 --> 00:05:26,800
architecture how components are 
working with each other and that

103
00:05:26,800 --> 00:05:30,900
also has implications both on 
strategic and tactical level. 

104
00:05:31,200 --> 00:05:34,800
Now, if we get that business 
domain knowledge around, that's 

105
00:05:34,800 --> 00:05:38,500
a good opportunity to make some 
wrong decisions. 

106
00:05:38,700 --> 00:05:43,900
Both strategic and tactical W. 
So that's, in my opinion, why we

107
00:05:43,900 --> 00:05:47,900
have to make sure that we have 
enough knowledge of the problem 

108
00:05:47,900 --> 00:05:51,400
domain before we're even trying 
to design a solution for it. 

109
00:05:51,500 --> 00:05:53,500
It. 
And sometimes what I can see, as

110
00:05:53,500 --> 00:05:56,600
well as software developers, I 
mean, we are all clever people. 

111
00:05:56,600 --> 00:06:00,400
I, we also sometimes think of 
imaginary problems or imaginary 

112
00:06:00,400 --> 00:06:02,500
Solutions. 
We think that oh, it will be 

113
00:06:02,500 --> 00:06:04,300
cool. 
If the most, typical one is 

114
00:06:04,300 --> 00:06:06,300
something happens in atomic 
fashion. 

115
00:06:06,500 --> 00:06:08,900
So, everything is just one 
transaction, they will be 

116
00:06:08,900 --> 00:06:10,900
real-time, cool. 
And people will just see the 

117
00:06:10,900 --> 00:06:13,600
results as possible, but 
sometimes business process 

118
00:06:13,600 --> 00:06:16,300
doesn't work this way. 
It's okay to have some delay and

119
00:06:16,300 --> 00:06:19,100
that's why we have more 
event-driven architecture 

120
00:06:19,200 --> 00:06:20,800
asynchronous and things like 
that. 

121
00:06:21,200 --> 00:06:24,600
And this Leads to a lot of 
things that we know software 

122
00:06:24,600 --> 00:06:26,600
projects tend to fail 
traditionally. 

123
00:06:26,600 --> 00:06:29,800
We all learn about that. 
Maybe 50% or more of software 

124
00:06:29,800 --> 00:06:32,500
projects are failing. 
Do you think By domain-driven 

125
00:06:32,500 --> 00:06:35,400
Design This crisis can actually 
be solved? 

126
00:06:36,100 --> 00:06:41,100
Yeah, I actually believe that. 
So if we look for reasons why so

127
00:06:41,100 --> 00:06:44,400
many software projects fail to 
look at studies that were 

128
00:06:44,400 --> 00:06:47,400
conducted on this topic. 
You'll see that quite a few of 

129
00:06:47,400 --> 00:06:49,800
them. 
If not all of them fail because 

130
00:06:49,800 --> 00:06:53,400
of communication issues, Shoes, 
or something related to 

131
00:06:53,407 --> 00:06:56,700
communication, it can be 
communication between team 

132
00:06:56,700 --> 00:07:00,100
members communication between 
software engineers and domain 

133
00:07:00,100 --> 00:07:03,700
expert communication issues 
between management and 

134
00:07:03,700 --> 00:07:07,000
Engineering teams. 
The core principle of domain 

135
00:07:07,000 --> 00:07:11,300
driven design is building a 
shared understanding between the

136
00:07:11,300 --> 00:07:15,500
different stakeholders of the 
project so that they can speak. 

137
00:07:15,600 --> 00:07:19,600
And reason about that suffer 
system in the same language in 

138
00:07:19,600 --> 00:07:21,400
DD lingo, it's called a be 
cutest. 

139
00:07:21,600 --> 00:07:25,400
Which once we will be able to 
facilitate communication in the 

140
00:07:25,400 --> 00:07:28,400
same language without the need 
for multiple translations, 

141
00:07:28,400 --> 00:07:31,900
before a knowledge, reaches, its
destination, everything will be 

142
00:07:32,000 --> 00:07:36,200
way more efficient that can 
solve as a lots of rework, 

143
00:07:36,400 --> 00:07:40,400
what's of wrong assumptions. 
And eventually, I believe it 

144
00:07:40,400 --> 00:07:43,200
will lead to more successful 
software projects. 

145
00:07:44,200 --> 00:07:48,300
And it probably also could help 
in translating the changes in 

146
00:07:48,300 --> 00:07:50,600
the business as well. 
So, let's say these days, 

147
00:07:50,600 --> 00:07:52,400
everything gets disrupted 
easily. 

148
00:07:52,600 --> 00:07:55,300
If you really understand the 
business domain, and use the 

149
00:07:55,300 --> 00:07:57,600
same understanding the share 
understanding, I like what you 

150
00:07:57,600 --> 00:08:00,100
mentioned, the ubiquitous 
language and maybe the business 

151
00:08:00,100 --> 00:08:03,600
process, maybe you can also 
adapt your software easily. 

152
00:08:03,800 --> 00:08:06,900
You can use the same terms, same
understanding, even your 

153
00:08:06,900 --> 00:08:10,100
software, the code classes, 
maybe the objects are named 

154
00:08:10,100 --> 00:08:13,600
similarly so you can actually 
probably adapt to the changes 

155
00:08:13,600 --> 00:08:16,600
pretty A much easier because the
business domains, the business, 

156
00:08:16,600 --> 00:08:18,500
understanding and software 
developers understanding 

157
00:08:18,500 --> 00:08:20,400
basically, are the same, am I 
right to set? 

158
00:08:20,400 --> 00:08:23,100
That actually the case. 
What did it is trying to solve? 

159
00:08:23,700 --> 00:08:25,100
Yeah, yeah. 
That's as well. 

160
00:08:25,100 --> 00:08:28,800
Because everything changes, 
especially if you're working for

161
00:08:28,800 --> 00:08:32,299
a stirrup Infinity cases. 
The Stirrup is new, not only 

162
00:08:32,299 --> 00:08:34,700
that, we are software. 
Engineers have no idea how to 

163
00:08:34,700 --> 00:08:36,600
implement that the most 
efficient way. 

164
00:08:36,600 --> 00:08:39,900
But Bill's people have no idea 
how they're going to solve 

165
00:08:39,900 --> 00:08:42,600
certain problems. 
That they are focusing on date, 

166
00:08:42,600 --> 00:08:44,700
knows that. 
Hey, that's Something that we 

167
00:08:44,700 --> 00:08:46,700
want to do. 
How we're going to do it. 

168
00:08:47,000 --> 00:08:49,500
We're going to iterate. 
We're going to test him 

169
00:08:49,500 --> 00:08:51,900
Solutions until find the most 
optimal one. 

170
00:08:52,200 --> 00:08:54,900
And guess what happened? 
During that time period, 

171
00:08:54,900 --> 00:08:57,400
everything is going to change 
that understanding of the 

172
00:08:57,408 --> 00:09:00,600
business domain is going to 
evolve, not only, you're going 

173
00:09:00,600 --> 00:09:04,700
to learn more and more about it.
But those business people, those

174
00:09:04,700 --> 00:09:08,200
domain experts, they're going to
learn as well as the gain more 

175
00:09:08,200 --> 00:09:12,600
knowledge that has to be 
reflected in software design 

176
00:09:12,600 --> 00:09:15,200
decisions. 
So, Going back to that formula 

177
00:09:15,200 --> 00:09:18,300
of software, design equals 
function of business domain. 

178
00:09:18,600 --> 00:09:21,600
If that component business 
domain changes, it has to be 

179
00:09:21,600 --> 00:09:25,900
reflected in software design. 
There can be many types of 

180
00:09:25,900 --> 00:09:28,300
changes starting from may be a 
more. 

181
00:09:28,300 --> 00:09:31,500
Efficient way to describe the 
business, domain better 

182
00:09:31,500 --> 00:09:34,600
terminology, a better 
understanding of the business 

183
00:09:34,600 --> 00:09:37,600
processes, like what you just 
said about transaction, 

184
00:09:37,600 --> 00:09:40,400
boundaries for example, what 
should be strongly consistent? 

185
00:09:40,400 --> 00:09:41,900
What can be eventually 
consistent. 

186
00:09:42,300 --> 00:09:45,700
But also the whole Jesus do 
making change. 

187
00:09:46,000 --> 00:09:49,400
Now, it's not unusual for a 
company to start with one 

188
00:09:49,400 --> 00:09:52,200
business goal, and change it 
along the way, because the 

189
00:09:52,200 --> 00:09:54,500
previous one wasn't financially 
viable. 

190
00:09:54,500 --> 00:09:58,500
For example, software project 
that was implemented. 

191
00:09:58,500 --> 00:10:01,500
In the first Reincarnation of 
the company is not necessarily 

192
00:10:01,500 --> 00:10:05,000
relevant for the new one because
this is the main we change, its 

193
00:10:05,000 --> 00:10:07,800
sub domains may change. 
Everything can change, it has to

194
00:10:07,800 --> 00:10:12,300
be reflected in software design,
failing to react to changes in 

195
00:10:12,300 --> 00:10:15,800
business domain, will occur. 
Technical depth over time and 

196
00:10:15,800 --> 00:10:19,700
eventually it will lead you to a
very big technical debt and a 

197
00:10:19,708 --> 00:10:23,300
big bowl of mud and typically 
than Engineers will say, yeah, 

198
00:10:23,300 --> 00:10:24,900
we need to rewrite the whole 
thing again. 

199
00:10:24,900 --> 00:10:27,600
So starting from scratch. 
That's like the typical have a 

200
00:10:28,300 --> 00:10:29,800
problem in the software 
industry. 

201
00:10:30,200 --> 00:10:33,500
So you mentioned that we have 
two things in DDD, right? 

202
00:10:33,600 --> 00:10:37,100
What is called strategic design 
and also technical design 

203
00:10:37,400 --> 00:10:40,200
throughout my journey learning 
about DDD, as well. 

204
00:10:40,300 --> 00:10:42,800
I typically started from the 
technical design. 

205
00:10:42,900 --> 00:10:45,800
I mean, just to be honest. 
Everyone here I started with oh 

206
00:10:45,800 --> 00:10:49,800
I can see repository use case 
Service Pack then it looks cool 

207
00:10:49,900 --> 00:10:51,800
and I even started from a 
framework back. 

208
00:10:51,800 --> 00:10:54,500
Then it's like spring framework.
They have all these term in the 

209
00:10:54,500 --> 00:10:56,400
framework. 
So I started from there and 

210
00:10:56,400 --> 00:10:58,400
learn the Eric Evans books as 
well. 

211
00:10:58,600 --> 00:11:01,200
So that's where probably people 
started as the first path 

212
00:11:01,200 --> 00:11:04,600
towards domain driven design but
I do along the way as I learn 

213
00:11:04,600 --> 00:11:06,100
about it. 
The most important part is 

214
00:11:06,100 --> 00:11:09,600
actually, the Strategic design. 
Can you tell us more about 

215
00:11:09,600 --> 00:11:12,300
strategic design? 
What it is, it actually about 

216
00:11:12,400 --> 00:11:15,200
and why it is much more 
Important that the Tactical 

217
00:11:15,200 --> 00:11:17,000
design. 
Yeah. 

218
00:11:17,100 --> 00:11:19,300
First of all, I fully agree with
you. 

219
00:11:19,500 --> 00:11:24,600
I think that strategic design is
way more important because you 

220
00:11:24,600 --> 00:11:28,900
can write, pretty successful 
project while incorporating only

221
00:11:28,900 --> 00:11:32,400
strategic design decisions, but 
if you're focusing only on 

222
00:11:32,400 --> 00:11:36,000
technical design decisions. 
Well, that's probably not going 

223
00:11:36,000 --> 00:11:38,700
to end well. 
At least in my experience, I 

224
00:11:38,700 --> 00:11:41,200
wrote a chapter in the book 
about my story of applying the 

225
00:11:41,200 --> 00:11:45,200
major redesign in that company. 
It's similar to what you just 

226
00:11:45,200 --> 00:11:47,500
said. 
I read four chapters of the blue

227
00:11:47,500 --> 00:11:51,200
book, and let's get started. 
Let's model everything as an 

228
00:11:51,200 --> 00:11:53,500
aggregate. 
So strategic design. 

229
00:11:53,500 --> 00:11:55,900
What is it? 
First of all, strategic design 

230
00:11:55,900 --> 00:11:58,900
is about creating a shared, 
understanding between software 

231
00:11:58,900 --> 00:12:01,600
engineers and business domain 
experts. 

232
00:12:01,600 --> 00:12:04,400
It's about cultivating that 
shared language, shared 

233
00:12:04,400 --> 00:12:07,800
understanding. 
Now, to do that, there are a few

234
00:12:07,800 --> 00:12:11,300
requirements from that language 
that you're using in 

235
00:12:11,300 --> 00:12:14,300
communication. 
That's my requirement is Each 

236
00:12:14,300 --> 00:12:18,500
term should have one and only 
one meeting people, unlike 

237
00:12:18,500 --> 00:12:22,200
software, they are so 
unpredictable, sometimes they 

238
00:12:22,200 --> 00:12:25,600
can say one thing, but mean 
something else? 

239
00:12:25,700 --> 00:12:29,300
Because the context is 
different, we cannot allow that 

240
00:12:29,400 --> 00:12:32,300
when taking a software design 
decisions, we have to make sure 

241
00:12:32,300 --> 00:12:34,800
that every piece of knowledge is
explicit. 

242
00:12:35,200 --> 00:12:38,400
So the major InDesign says, hey,
when you have such ubiquitous 

243
00:12:38,400 --> 00:12:42,200
language, that depends on 
context model, it explicitly in 

244
00:12:42,200 --> 00:12:46,100
code, defined the context, Which
that language applies, its 

245
00:12:46,200 --> 00:12:49,600
bounded context, that's the name
of the pattern bounded context, 

246
00:12:50,200 --> 00:12:52,600
and that's the first strategic 
design decision. 

247
00:12:53,000 --> 00:12:56,800
It ensures that you have a model
and compost by the bounded 

248
00:12:56,800 --> 00:13:00,700
context, which is clear. 
Each of its terms has only one 

249
00:13:00,700 --> 00:13:05,600
meaning now many because of some
historical issues and mistakes 

250
00:13:05,600 --> 00:13:09,300
think that bounded context is 
necessarily microservice, that's

251
00:13:09,300 --> 00:13:13,700
not true abundant context. 
Is it rather your biggest valid?

252
00:13:13,800 --> 00:13:18,600
Monolith because it encompasses 
a model that has no conflicts in

253
00:13:18,600 --> 00:13:20,900
it. 
You can decompose it further but

254
00:13:20,900 --> 00:13:24,400
that's a different discussion. 
But the idea is to file those 

255
00:13:24,400 --> 00:13:28,000
boundaries that ensure that you 
have a correct model in it 

256
00:13:28,000 --> 00:13:30,500
without no conflicts or 
collisions. 

257
00:13:30,900 --> 00:13:34,000
So, that's your first strategic 
design decision. 

258
00:13:34,000 --> 00:13:37,300
You are deciding what you're 
going to implement, what is the 

259
00:13:37,300 --> 00:13:40,000
business domain? 
And what are the core components

260
00:13:40,000 --> 00:13:43,700
of your system that you're going
to build second assistant? 

261
00:13:43,900 --> 00:13:48,600
Doesn't build itself for that. 
We need us software engineers in

262
00:13:48,600 --> 00:13:51,300
any organization. 
There can be either one team of 

263
00:13:51,300 --> 00:13:54,100
people or multiple teams of 
people working on the same 

264
00:13:54,100 --> 00:13:59,300
project and that again, affects 
how you design those bounded 

265
00:13:59,300 --> 00:14:02,200
context because they have to 
interact with each other. 

266
00:14:02,300 --> 00:14:05,300
Now, let's say you have two 
bounded context implemented by 

267
00:14:05,300 --> 00:14:08,100
two different teams think of two
examples. 

268
00:14:08,400 --> 00:14:11,200
The first case they have a 
really good collaboration 

269
00:14:11,200 --> 00:14:13,700
between them, they're like two 
teams. 

270
00:14:13,800 --> 00:14:17,300
But they understand that they're
going to succeed or fail 

271
00:14:17,300 --> 00:14:21,100
together, so they're really 
trying to care for each other. 

272
00:14:21,300 --> 00:14:24,500
If there are some integration 
conflicts, they are going to 

273
00:14:24,500 --> 00:14:27,600
just go ahead and fix it without
making magic drama about it. 

274
00:14:28,100 --> 00:14:33,200
Now let's fast-forward to same 
company, lots of money and 

275
00:14:33,200 --> 00:14:36,000
suddenly they became a huge 
Enterprise. 

276
00:14:36,400 --> 00:14:38,900
And again we have two teams 
working on two different bounded

277
00:14:38,900 --> 00:14:41,600
contacts. 
Now suddenly there is no such 

278
00:14:41,600 --> 00:14:43,500
good collaboration between the 
teams. 

279
00:14:44,000 --> 00:14:47,800
One team asks to modify the 
integration interface and now 

280
00:14:47,800 --> 00:14:51,000
you have drama. 
Now you have meetings such Etc 

281
00:14:51,500 --> 00:14:53,700
and that of course, postpones to
the release. 

282
00:14:53,900 --> 00:14:56,300
It negatively affects the 
progress, etc. 

283
00:14:56,300 --> 00:14:58,600
Etc. 
Well, the management design 

284
00:14:58,600 --> 00:15:01,200
says, hey, that's something you 
have to take into account. 

285
00:15:01,200 --> 00:15:03,600
When you are designing, those 
components have, there are going

286
00:15:03,600 --> 00:15:06,300
to be integrated. 
So, for example, in the first 

287
00:15:06,300 --> 00:15:09,700
case, the pattern can be 
partnership, those teams their 

288
00:15:09,700 --> 00:15:13,900
Partners, the interested in 
succeeding together in the In 

289
00:15:13,900 --> 00:15:17,400
case, one of the customers, 
suppliers patterns, might be a 

290
00:15:17,400 --> 00:15:20,700
better choice because they 
provide that certain level of 

291
00:15:20,700 --> 00:15:23,800
isolation between the team so 
that the changes want to 

292
00:15:23,800 --> 00:15:27,300
propagate across the integration
interface and cause all the 

293
00:15:27,300 --> 00:15:30,200
drama. 
So, that's the second strategic 

294
00:15:30,200 --> 00:15:33,400
design decision that we are 
making according to both 

295
00:15:33,400 --> 00:15:36,800
business domain and the 
structure of our teams going 

296
00:15:36,800 --> 00:15:40,500
back to our previous discussion,
the structure of engineering 

297
00:15:40,500 --> 00:15:43,700
teams can change as well. 
Two teams can be in Partnership.

298
00:15:43,800 --> 00:15:47,200
Beginning, but a few years later
there will be like enemies of 

299
00:15:47,200 --> 00:15:50,300
each other. 
That should affect the way those

300
00:15:50,300 --> 00:15:52,700
bounded context are integrated 
with each other. 

301
00:15:52,800 --> 00:15:54,500
That's an important design 
decision. 

302
00:15:55,300 --> 00:15:58,500
So, it seems that a few things 
here, if I heard what you 

303
00:15:58,500 --> 00:16:00,800
mentioned, just now, right? 
The first thing is actually 

304
00:16:00,800 --> 00:16:03,500
ubiquitous language. 
It's like almost every book. 

305
00:16:03,500 --> 00:16:05,700
I read every resource. 
I read about domain-driven 

306
00:16:05,700 --> 00:16:09,100
design, ubiquitous language is 
the first thing, which also 

307
00:16:09,200 --> 00:16:12,800
then, translate into multiple 
things on this context. 

308
00:16:12,800 --> 00:16:16,100
That's also another important 
aspect within the context 

309
00:16:16,100 --> 00:16:18,000
itself. 
The ubiquitous language should 

310
00:16:18,000 --> 00:16:21,400
also translate what you said is 
without any Collision without 

311
00:16:21,400 --> 00:16:23,700
any Clash of understanding of a 
particular term. 

312
00:16:24,000 --> 00:16:26,800
So let's say a user you've 
mentioned is in one bounded 

313
00:16:26,800 --> 00:16:28,200
context. 
Yeah, it's clear. 

314
00:16:28,200 --> 00:16:30,600
What is the term used in this 
bounded context? 

315
00:16:30,800 --> 00:16:33,200
But in another bounded context 
it might mean something 

316
00:16:33,200 --> 00:16:35,100
different. 
Depending on that contact. 

317
00:16:35,200 --> 00:16:37,700
And then another thing that you 
mentioned, the funny story about

318
00:16:37,700 --> 00:16:39,600
the integrating between two 
teams. 

319
00:16:39,800 --> 00:16:42,500
I think what I understand is 
something related to like 

320
00:16:42,500 --> 00:16:45,900
integration of A bounded 
context, and what the book says,

321
00:16:45,900 --> 00:16:49,000
it's about context map, right? 
So how do you actually map 

322
00:16:49,000 --> 00:16:52,000
between two bounded contacts? 
There are different ways of how 

323
00:16:52,000 --> 00:16:54,000
you can integrate things. 
Like are you mentioned 

324
00:16:54,000 --> 00:16:57,700
partnership customer-supplier 
conformist and things like that?

325
00:17:00,300 --> 00:17:02,800
I hope you enjoyed this short 
clip from tackling Journal 

326
00:17:02,800 --> 00:17:05,800
favorite playlist. 
If you find this episode useful,

327
00:17:06,000 --> 00:17:07,599
please help. 
Share it with your friends and 

328
00:17:07,599 --> 00:17:10,599
colleagues who you think would 
also benefit from listening to 

329
00:17:10,608 --> 00:17:13,400
this episode. 
And if you want to listen more 

330
00:17:13,400 --> 00:17:16,400
from this conversation, please 
go back and listen to the 

331
00:17:16,400 --> 00:17:20,099
original full conversation with 
my guest, stay tuned for the 

332
00:17:20,099 --> 00:17:23,500
next technology, no episode. 
And until then goodbye.