1
00:00:00,000 --> 00:00:04,020
All right. Well, usually I have some inane banter, but we'll just start right into it,

2
00:00:04,040 --> 00:00:07,360
because I've been looking forward to a little chat here. Why don't you introduce yourself?

3
00:00:08,320 --> 00:00:13,620
Hello, everyone. My name is Jakub Pinimon. Currently, I work as a principal technologist,

4
00:00:14,120 --> 00:00:18,180
and some people call this role developer advocate, and I work for Pivotal right now.

5
00:00:18,680 --> 00:00:26,120
I'm from Poland, and here people use the name evangelist for this role. I think it's probably

6
00:00:26,120 --> 00:00:31,200
due to very religious context of our country. That's my guess. But after all, the term comes

7
00:00:31,200 --> 00:00:38,040
from religious evangelism. My question is, how about Netherlands and US? Do we use the term

8
00:00:38,040 --> 00:00:44,140
evangelist still there? You know, I think it's mixed. I think in the Netherlands, I don't know

9
00:00:44,140 --> 00:00:49,540
what they would say. They probably would. Yeah, I think advocate is a weird, this is a very,

10
00:00:49,800 --> 00:00:55,000
not contentious, but I agree. It's confusing to know what to do. And I was talking on one of my

11
00:00:55,000 --> 00:01:00,240
other podcasts. Like, I'm not sure. I think maybe we're supposed to call ourselves strategists now.

12
00:01:00,240 --> 00:01:05,140
Have you noticed this trend? There's all these people, you'll see, it's these people at vendors

13
00:01:05,140 --> 00:01:13,680
called strategists. I think the issue is, if you use a command prompt, you are an advocate.

14
00:01:14,420 --> 00:01:19,260
And if you don't use a command prompt, I think you're a strategist, how you distinguish between

15
00:01:19,260 --> 00:01:23,820
the two. So I think I am a strategist, and I think you are an advocate.

16
00:01:24,500 --> 00:01:30,100
I still use the command prompt, so I'm still an advocate, right? Anyways, I don't like the word

17
00:01:30,100 --> 00:01:32,100
evangelist, to be honest. Yeah.

18
00:01:32,220 --> 00:01:39,380
So I see our role more as someone responsible for sharing the potential of some products,

19
00:01:39,620 --> 00:01:41,340
methodologies, et cetera, et cetera, right?

20
00:01:41,400 --> 00:01:48,320
In my case, I try to focus on architecture design. And only after that, spend some time

21
00:01:48,320 --> 00:01:59,040
actually talking about tools. Before Pivotal, I used to work in various companies like immobility,

22
00:01:59,460 --> 00:02:06,420
e-commerce, fintechs, amongst others. And this was a wonderful time. Being an independent consultant

23
00:02:06,420 --> 00:02:13,860
allowed me to get to know different problems, different domains, get familiars with different

24
00:02:13,860 --> 00:02:21,400
specific domains. Hence, my interest in the management design, by the way. From time to time,

25
00:02:21,460 --> 00:02:25,320
I work as a trainer, too, focusing on the management design and architecture.

26
00:02:26,620 --> 00:02:31,080
Yeah. Yeah. Well, you know, other than working together and being on the same team, one of the

27
00:02:31,080 --> 00:02:37,360
things I've been talking with you about recently is I have this, well, first of all, there's this issue

28
00:02:37,360 --> 00:02:44,900
of what happens to enterprise architects and all of our glorious future of cloud native and DevOps and

29
00:02:44,900 --> 00:02:51,420
agile and SRE, whatever, all that stuff. Because I don't think any of the literature uses the phrase

30
00:02:51,420 --> 00:02:58,140
enterprise architect. And yet there's a lot of them and they seem to provide a role. And so one of the

31
00:02:58,140 --> 00:03:02,460
things I was thinking about, I've been thinking about over the years, it's like, I kind of know what

32
00:03:02,460 --> 00:03:08,800
domain-driven design is, sort of. And we'll see how much I know. But it seems like at a large

33
00:03:08,800 --> 00:03:15,660
organization, an enterprise architect is well positioned to define those, if indeed they are

34
00:03:15,660 --> 00:03:21,960
skilled at it. And so to that end, I mean, maybe eventually we'll get to that. Like, what is domain-driven

35
00:03:21,960 --> 00:03:28,640
design? What is this? What is domain-driven design? That's a tough question, to be honest. I have read

36
00:03:28,640 --> 00:03:34,460
like three or four books on domain-driven design. I still, I'm not sure how to define this term,

37
00:03:34,540 --> 00:03:41,820
but let me try. So nowadays, critical factor or thing that defines the success of any IT project

38
00:03:41,820 --> 00:03:49,080
is understanding the problem to be solved itself. As the Eric Evans, father of domain-driven design,

39
00:03:49,280 --> 00:03:55,620
he once upon a time has said that the biggest complexity lies in understanding the domain itself,

40
00:03:55,880 --> 00:04:01,700
which is the system to be designed, which problem to be solved, etc. And I have a feeling that our

41
00:04:01,700 --> 00:04:09,040
industry is great at technology. Like you said, cloud solutions, continuous integration, continuous

42
00:04:09,040 --> 00:04:13,920
delivery, we are able to push from an idea to production in days or even hours, right?

43
00:04:14,140 --> 00:04:20,180
But what's the benefit if I push the wrong thing or not suitable thing, something that is misunderstood?

44
00:04:21,020 --> 00:04:26,980
And domain-driven design helps solving this problem by constant knowledge crunching and creates the

45
00:04:26,980 --> 00:04:34,580
shared view. Or as someone once upon a time has said, the shared repository of knowledge across the

46
00:04:34,580 --> 00:04:40,240
whole organization. And that's what domain-driven design is to me. Because sometimes there is no point in

47
00:04:40,240 --> 00:04:45,520
writing any software in the first place, and there has to be a problem which we intend to tackle, right?

48
00:04:46,040 --> 00:04:53,720
And domain-driven design tries to distill this core problem, focus on it, and do our best in this specific place.

49
00:04:54,100 --> 00:05:02,540
So that's my take on what's domain-driven design. It's not code, because code would be just a side effect

50
00:05:02,540 --> 00:05:06,140
of this process. I think that's what we're going to do in the first place.

51
00:05:06,140 --> 00:05:12,980
One famous guy from domain-driven design community, inventor of event-storming, he said that

52
00:05:12,980 --> 00:05:20,240
software development is a learning process, and working code is just a side effect of this learning process.

53
00:05:21,040 --> 00:05:22,940
So this is what I think about domain-driven design.

54
00:05:23,940 --> 00:05:27,340
I think he deserves a huge credit for stating as such,

55
00:05:28,240 --> 00:05:33,280
it's an iterative learning process during which we build this common understanding of the problem space.

56
00:05:33,280 --> 00:05:37,360
And the code that just works is a side effect of that process.

57
00:05:38,580 --> 00:05:47,680
So, yeah, I know it should be maybe defined in two sentences, but I am not capable of doing so.

58
00:05:48,100 --> 00:05:52,640
No, you can't define something like that in two sentences, right?

59
00:05:52,760 --> 00:05:59,160
Like, it would be, and I think because, like, you know, for the, well, there's two ways of defining

60
00:05:59,160 --> 00:06:05,980
things. I'll use an analogy, right? Like, I think going back to, like, how you, we, us, we would

61
00:06:05,980 --> 00:06:12,000
describe what it is we do, I've finally settled on a way to tell the normals, if you will, people aren't

62
00:06:12,000 --> 00:06:16,500
in the tech industry. That's very concise. It's basically like, I don't know, I'm a company spokesperson.

63
00:06:17,100 --> 00:06:19,860
And like, everyone's like, all right, great. Now we can go talk about something else.

64
00:06:21,000 --> 00:06:27,920
Because that's, that's the most easy to understand tangible part of what, what I do and the other

65
00:06:27,920 --> 00:06:33,660
people on our team do is like, we go out and talk to people. Now, if you are actually like one of us

66
00:06:33,660 --> 00:06:37,700
or someone in the tech industry, like that would be a completely insufficient thing to describe,

67
00:06:37,800 --> 00:06:40,720
right? There's all sorts of other things that we do, but it's easy to explain. And I think

68
00:06:40,720 --> 00:06:46,040
similarly, if you were going to explain like programming to someone, you would be like,

69
00:06:46,160 --> 00:06:53,480
ah, you write this code and it tells computers what to do. And it makes the software, it makes

70
00:06:53,480 --> 00:06:59,120
screens that people interact with that do things. That's what programming is, which would be a terrible

71
00:06:59,120 --> 00:07:05,820
explanation if you're actually a programmer. And like, I think, yeah. And then the, the, the longer

72
00:07:05,820 --> 00:07:13,060
explanations are always that as, as you were kind of going over there, uh, I, confusing is the wrong

73
00:07:13,060 --> 00:07:19,880
word, but like, I always found this frustrating on, when I was younger, but I feel like when you ask

74
00:07:19,880 --> 00:07:28,080
what a complicated thing is, the more difficult it is to define, the better someone has a grasp on it.

75
00:07:28,620 --> 00:07:34,340
It's kind of a very like Eastern philosophy approach to things. But because what you do is you like,

76
00:07:34,480 --> 00:07:40,180
you've suffered through all the insufficiencies of the thing. So you're like, ah, I don't want to

77
00:07:40,180 --> 00:07:46,940
make any promises that it solves things. Basically like any thought technology in computers. I think

78
00:07:46,940 --> 00:07:51,440
the ultimate definition for an expert is it's a lot worse than what we used to do.

79
00:07:52,500 --> 00:07:56,480
Yeah. It's like a solving one problem and causing two more problems, right?

80
00:07:56,700 --> 00:08:00,820
Exactly. And you know, when, when I, when I've looked at, especially when you were just going

81
00:08:00,820 --> 00:08:05,340
over it, I don't know if, I don't know if I've ever connected these two things so much, but when I,

82
00:08:05,440 --> 00:08:11,560
when you're just going over, uh, uh, the main driven design or triple D or DDD, I don't know what

83
00:08:11,560 --> 00:08:17,500
people call it, the insiders, but like, it reminds me a lot of this sort of, um, business strategy

84
00:08:17,500 --> 00:08:24,480
theory called jobs to be done, which is nothing at all to do with computers, but it basically means

85
00:08:24,480 --> 00:08:31,600
instead of thinking about yourself, what's an example, the classic example of all things is a

86
00:08:31,600 --> 00:08:37,180
milkshake, right? And so instead of thinking of yourself selling milkshakes to people, you're just

87
00:08:37,180 --> 00:08:42,060
a milkshake seller. You actually go and study what people are doing with your milkshake. And this is why

88
00:08:42,060 --> 00:08:47,920
it appeals as the technologists. And if you study them, you find out that a lot of people use a

89
00:08:47,920 --> 00:08:53,740
milkshake. Shockingly, they buy it in the morning and they use it as a quick substitute breakfast

90
00:08:53,740 --> 00:08:59,440
that fills them up. And so once you figure out this job to be done, that allows you to perfect

91
00:08:59,440 --> 00:09:06,800
the milkshake, right? And it may not actually be like a milkshake that a kid or a fun adult looking

92
00:09:06,800 --> 00:09:12,860
for a good time would buy, but you can make like a smoothie, like milkshake-y thing. And it all. And,

93
00:09:12,860 --> 00:09:16,740
and when I read about domain driven design stuff, it feels like there's that similar, as you were

94
00:09:16,740 --> 00:09:24,340
saying, constant learning of like, what is this thing we're actually doing? And therefore, how would

95
00:09:24,340 --> 00:09:31,260
we organize around providing it or something like that? I don't know, but, but at that point, after

96
00:09:31,260 --> 00:09:36,400
that, it gets confusing. So maybe that's a good start is like, I guess, ironically, given that you do a

97
00:09:36,400 --> 00:09:41,120
vent storming and domain driven design. What are the activities that one does when they're doing

98
00:09:41,120 --> 00:09:42,200
domain driven design?

99
00:09:43,040 --> 00:09:50,520
So first thing first, I really like the connection to milkshakes. And one of the, I think one of the

100
00:09:50,520 --> 00:09:56,960
outcomes of this milkshake research would be, Hey, sometimes those companies, they don't even need

101
00:09:56,960 --> 00:10:03,020
milkshakes. We won't sell them with milkshakes or they want to buy milkshakes. And then they don't

102
00:10:03,020 --> 00:10:08,960
even know that maybe exactly. Exactly. And like, in that case, the job to be done is like, I need a

103
00:10:08,960 --> 00:10:14,220
really quick, cheap breakfast that I can pick up on the way to work. Right. And that tastes good.

104
00:10:15,180 --> 00:10:20,720
Exactly. Exactly. And it doesn't have to be necessarily milkshake, right? Exactly. Because

105
00:10:20,720 --> 00:10:26,380
everyone does milkshakes. So maybe I will do milkshake as well. But in my context, something else

106
00:10:26,380 --> 00:10:30,920
would have been better. So this is what I think about domain driven design.

107
00:10:31,620 --> 00:10:39,460
And describing it with milkshakes, as you mentioned. So you also mentioned that programming is hard

108
00:10:39,460 --> 00:10:47,780
to, it's hard to describe. I think that's correct. But also programming has a good metaphor for

109
00:10:47,780 --> 00:10:53,780
us, for all of us. Like, even though we are not from technology industry, you can understand

110
00:10:53,780 --> 00:11:00,280
the word programming because it, we have metaphors that will help us understanding and understanding

111
00:11:00,280 --> 00:11:08,120
this word. Whereas domain driven design doesn't have those metaphors built yet. And it's hard to

112
00:11:08,120 --> 00:11:16,280
understand even by people who work at technology or a business because it doesn't have a good metaphor

113
00:11:16,280 --> 00:11:22,840
to connect with. So that's the problem with domain driven design. That's my take. Also, you have asked about

114
00:11:22,840 --> 00:11:38,280
activities, right? That's right. So it's not like there is no ceremony. So we don't, you don't necessarily have to do

115
00:11:38,280 --> 00:11:48,200
each sprint or each iteration, a specific thing like, hey, I have to do some kind of a knowledge crunching

116
00:11:48,200 --> 00:11:56,040
each day at 12 o'clock because that's what process says. Right, right. So things that may help

117
00:11:56,040 --> 00:12:04,040
you is doing conversation with the business owners. And conversations are the most popular ways of

118
00:12:04,040 --> 00:12:10,920
gathering knowledge, right? But, however, those conversations and meetings share a common problem.

119
00:12:10,920 --> 00:12:18,760
They often turn into something messy without any visible effect. Right. If there is any

120
00:12:18,760 --> 00:12:24,760
visible effect, so most probably it's the one written down by a requirement analyst or business

121
00:12:24,760 --> 00:12:32,680
analyst, EA or whatever we call this person. And those documents are just snapshots of this person's

122
00:12:32,680 --> 00:12:37,640
current understanding of the actual conversation and the actual problem. It's a snapshot of their

123
00:12:37,640 --> 00:12:44,600
understanding at the time of speaking. So it's already subjective, right? And then there is this process

124
00:12:44,600 --> 00:12:52,600
of developers reading and understanding this document. So then, therefore, the code is a snapshot of

125
00:12:52,600 --> 00:12:58,680
developers understanding the document at the time of implementation. Right. So we have these two

126
00:12:58,680 --> 00:13:04,680
layers of miscommunication, two layers of translation. And that can cause huge problems because after all,

127
00:13:04,680 --> 00:13:12,680
we can deliver things that are not even close to the initial idea of the business owners, right?

128
00:13:12,680 --> 00:13:21,720
Yeah. And just as a side note, and not to distract us too much, but that's an interesting classic

129
00:13:21,720 --> 00:13:27,720
problem in programming is, kind of to borrow some information terminology that I barely know,

130
00:13:27,720 --> 00:13:33,400
it's basically like the fidelity of information between point A and point B. So when you go from a

131
00:13:33,400 --> 00:13:40,360
business analyst to a developer, what is the loss of that requirement that you have, right? And you're

132
00:13:40,360 --> 00:13:45,400
like, you're pretty much guaranteed that there's going to be some loss of information and some

133
00:13:45,400 --> 00:13:53,000
misunderstanding. And like, I don't know if, I don't know if we really model that in development. And I

134
00:13:53,000 --> 00:13:56,600
guess the hack around that, that we have a lot is like, don't have them be separate people,

135
00:13:57,400 --> 00:14:04,360
but whatever. So, so anyways, back to the, uh, that we'll, we'll emerge from the footnote and,

136
00:14:04,360 --> 00:14:10,280
uh, go on with the normal course. Um, so we tend, as you mentioned, we tend to create those layers of

137
00:14:10,280 --> 00:14:17,080
translations. Um, I, I think about this as, um, we have this game in Poland. I don't know about

138
00:14:17,640 --> 00:14:23,080
any other country, but I, I think, yeah, in UK, they call it Chinese whispers. Do you know it?

139
00:14:23,080 --> 00:14:25,880
Hmm. Or like a telephone?

140
00:14:25,880 --> 00:14:33,880
Yeah. Yeah. Yeah. So it's, uh, the direct translation from Polish would be a death phone.

141
00:14:34,440 --> 00:14:39,320
Um, I think it's called Chinese whispers, but it's exactly what's happening with those business

142
00:14:39,320 --> 00:14:44,920
requirements gathered at some meeting and then written down on a piece of paper or a nice spreadsheet or a

143
00:14:44,920 --> 00:14:53,240
nice word document or whatever we use. And then, um, by it's taken by developers who try to understand

144
00:14:53,240 --> 00:14:58,840
that and translate into code. But luckily there is something that can help you. Uh,

145
00:14:58,840 --> 00:15:04,680
so Alberto Brandolini, he proposed in 2013, I guess, a technique called event storming,

146
00:15:05,720 --> 00:15:11,720
because after all, how do we actually perform this meaningful conversation between stakeholders and

147
00:15:11,720 --> 00:15:18,600
development team? And even storming is a technique that can help you. It's an exploratory exercise

148
00:15:18,600 --> 00:15:25,640
built around conversation, but with visible outcome, because we have tons of sticky notes with domain

149
00:15:25,640 --> 00:15:32,680
events, with hotspots, with misunderstandings, without, with understandings, with risk written down on those

150
00:15:32,680 --> 00:15:38,760
sticky notes. It's a straightforward and understandable. I would say it's understandable by anyone. So it's

151
00:15:38,760 --> 00:15:44,280
a straightforward technique, understandable by anyone. And this common vision is built. Common language,

152
00:15:44,280 --> 00:15:51,560
so-called ubiquitous language. It's, uh, it's a term that is, uh, that's coming from DDD community,

153
00:15:51,560 --> 00:15:57,880
ubiquitous language. So the language is spoken by, uh, everyone in our piece of, in our piece of model,

154
00:15:57,880 --> 00:16:06,120
by business owners, by QAs, by DevOps, by code, especially. And this, uh, this ubiquitous language is

155
00:16:06,120 --> 00:16:13,000
present on those sticky notes. Uh, in our industry, I have a thing that we have a nice misconception that

156
00:16:13,000 --> 00:16:19,240
the only important language is our programming language. Uh, but after all, we should focus more

157
00:16:19,240 --> 00:16:25,720
on the business language and let this language flow starting from domain experts minds and finishing in

158
00:16:25,720 --> 00:16:31,240
our working code, which is understandable by the domain, by those domain experts, because it speaks

159
00:16:31,240 --> 00:16:36,360
the same language. So even storming is the technique where you gather those people, business owners to

160
00:16:36,360 --> 00:16:43,400
people with answers and, uh, technical people. So people with questions and you build this common

161
00:16:43,400 --> 00:16:48,360
understanding. Um, it's, um, it's a, it's a great technique because it allows you to

162
00:16:49,240 --> 00:16:56,120
build a common, common language, which is not focused on technology. So the domain experts can

163
00:16:56,120 --> 00:16:59,960
really, uh, help us gathering this knowledge and understand that.

164
00:16:59,960 --> 00:17:05,000
So, so what's like, uh, what's like an example? Like let's, let's pick a domain. Like I know in your

165
00:17:05,000 --> 00:17:08,520
presentation, you always use credit cards, but maybe there's something better. Like what's a,

166
00:17:09,560 --> 00:17:15,640
what's a thing domain is the wrong word in this context, but you know, what's, what's a area of

167
00:17:15,640 --> 00:17:17,880
business or something we could pick to have some.

168
00:17:17,880 --> 00:17:27,080
So let's say, I don't know, for instance, Uber or taxi, something like this. So, um, if you focus

169
00:17:27,080 --> 00:17:32,840
on those behaviors and domain events, you would have a tons of sticky notes that would try to, to,

170
00:17:32,840 --> 00:17:39,080
to be enforced in the timeline, in the timeline. Like, uh, one sticky note would be a taxi ordered,

171
00:17:39,080 --> 00:17:44,840
right? A car was ordered. And then there should be some separate process trying to match the

172
00:17:44,840 --> 00:17:51,960
available driver to your order. And after some time, there is an event, Hey, um, a taxi driver

173
00:17:51,960 --> 00:17:58,440
match to your order. And this creates a ride for instance, but the ride can be still canceled. So

174
00:17:58,440 --> 00:18:05,560
we have, um, an order which says, uh, right canceled. And then the, the drive may not be canceled,

175
00:18:05,560 --> 00:18:10,920
but the driver may not arrive from whatever reason it was. Maybe he had an axis and stuff like this.

176
00:18:11,720 --> 00:18:18,440
So speaking about those events allows you to find the holes in your model. So it allows you to tackle

177
00:18:18,440 --> 00:18:23,640
the model and allows you to, to, to think about your model and your business from a different

178
00:18:23,640 --> 00:18:27,960
perspective. It allows you to ask questions, questions, which are not related to technology.

179
00:18:29,240 --> 00:18:34,200
So that, what would be, um, of course, and during this event storming session, you don't have like

180
00:18:34,200 --> 00:18:41,320
three or four sticky notes as we just used for taxi. Most probably we have like 400 or 500 of them.

181
00:18:41,720 --> 00:18:47,320
And you try to, to, uh, to find misconceptions between two different people or two different,

182
00:18:47,320 --> 00:18:52,680
um, departments, because during the session, you have people from coming from different departments.

183
00:18:53,160 --> 00:19:01,880
Let's say, um, um, in, in taxi domain, you would have people from, um, customer service or driver

184
00:19:01,880 --> 00:19:08,360
service. And they will think about an, about the, uh, about a term called order in a different way,

185
00:19:08,360 --> 00:19:13,960
right? From a customer service perspective, an order would be something that's related to a customer

186
00:19:13,960 --> 00:19:21,320
from driver service would be something, uh, related to a driver. So we have one thing that's in fact,

187
00:19:21,320 --> 00:19:25,720
it represents two different things in the real world, in our problem, in our problem space.

188
00:19:26,440 --> 00:19:31,720
And you have to find those, those misunderstandings during this session, because it allows you to,

189
00:19:31,720 --> 00:19:37,960
to, after all, to build a model, which can grow independently in the customer service department

190
00:19:37,960 --> 00:19:43,240
and in the driver service department. I'm just, um, I don't know if there is such a thing as a

191
00:19:43,240 --> 00:19:46,440
driver service. I'm just, you know, um, trying to...

192
00:19:46,440 --> 00:19:52,680
You're, you're, you're inventing your own, uh, Uber service, uh, car service.

193
00:19:53,240 --> 00:19:58,360
If it would be, if it was, uh, a bookstore, online bookstore, uh, that's easier. You have

194
00:19:58,360 --> 00:20:04,440
people from a warehouse and they care about size of the book and maybe the number of the books you

195
00:20:04,440 --> 00:20:09,240
have in your inventory. Uh, there will be people from taxes. They care about the price and the tax.

196
00:20:09,240 --> 00:20:13,560
They will be people from product catalog. They care about the title, people from shipping.

197
00:20:14,360 --> 00:20:18,760
They will care about, um, I don't know, most probably the wave of a, of a book.

198
00:20:19,800 --> 00:20:26,040
So we have different perspective on the same thing. Um, and you, it's, um, if you model this in one

199
00:20:26,040 --> 00:20:32,200
place, it's going to be problematic because your model will be, uh, tightly coupled to a different,

200
00:20:32,200 --> 00:20:39,080
um, different requirements coming from different perspective. And then there are those different

201
00:20:39,080 --> 00:20:46,600
perspectives that can be in clash. They can be, um, causing problems and you are not allowed to,

202
00:20:46,600 --> 00:20:52,520
to, to, to grow independently of different departments. So yeah, that's the, I think the

203
00:20:52,520 --> 00:20:57,480
first way I encountered domain-driven design was it's almost been four years that I've been at

204
00:20:57,480 --> 00:21:03,720
Pivotal, but I guess like almost four years ago. And, uh, like, I think it was like Matt Stein,

205
00:21:03,720 --> 00:21:08,920
who was talking about, uh, you use that to figure out microservices.

206
00:21:08,920 --> 00:21:13,560
You would have, which, you know, now that I'm thinking of it, I wonder if that was sort of

207
00:21:13,560 --> 00:21:18,520
like, uh, retconned into microservices or, you know, which one was the, the horse in the cart?

208
00:21:18,520 --> 00:21:21,800
No, wait. Yeah. There you go. With the chicken and the egg or whatever.

209
00:21:21,800 --> 00:21:22,280
Yeah.

210
00:21:22,280 --> 00:21:28,760
Uh, but you know, what you're touching on was, uh, um, what, what would you call it?

211
00:21:28,760 --> 00:21:37,240
It was like a taboo of software design, which was, it's okay to have multiple entities or,

212
00:21:37,240 --> 00:21:43,320
or objects that are the quote unquote, the same thing, because the way they're going to vary

213
00:21:43,320 --> 00:21:50,360
is by the, the group using them. Um, and so as you're, as you're going over, right, like a book

214
00:21:50,360 --> 00:21:55,080
to the shipping department is different than, or I would imagine is different than a book

215
00:21:55,080 --> 00:22:01,160
to the recommendation engine or something. Um, and that, I think that was an interesting,

216
00:22:01,160 --> 00:22:05,400
like, well, what if we don't follow that rule of, uh, what's the old rules?

217
00:22:05,400 --> 00:22:08,680
Uh, not, you aren't going to need it, but, uh, don't repeat yourself.

218
00:22:08,680 --> 00:22:14,200
Like what if dry doesn't actually matter or matters less, which is, which is intriguing.

219
00:22:15,000 --> 00:22:20,600
So the thing is that even though, um, that's my opinion, uh, even though the code looks the

220
00:22:20,600 --> 00:22:25,640
same in two different places, it doesn't mean it's, uh, we are violating this. Don't repeat

221
00:22:25,640 --> 00:22:33,400
yourself principle because, uh, it can grow, right? It can grow. It's always easier to, um,

222
00:22:34,040 --> 00:22:39,000
to merge it afterwards, afterwards, if you don't need it, then split it afterwards. If you have

223
00:22:39,000 --> 00:22:43,960
like, uh, one model for two different things. Hmm. That's a good long-term view. Yeah, that makes

224
00:22:43,960 --> 00:22:50,360
sense. Uh, and, um, you mentioned microservices and Matt Stania. He has a great content on domain

225
00:22:50,360 --> 00:22:58,760
driven design and microservices for, for sure. Domain driven design was first, uh, was first. And, uh,

226
00:22:58,760 --> 00:23:07,720
I think it gets second law nowadays also because of microservices. Um, the thing is that those,

227
00:23:07,720 --> 00:23:14,200
those independent models allows you to have so-called polyglot persistence. So we can

228
00:23:14,200 --> 00:23:20,040
choose and pick your own tool for persistence of those different models, because after all,

229
00:23:20,040 --> 00:23:25,560
hey, they are different. So why not, uh, why not picking the right tool in a different, in a,

230
00:23:25,560 --> 00:23:34,600
in a different places. Um, and these are called bounded context. This is, um, I think most important

231
00:23:34,600 --> 00:23:42,360
thing coming from the main design community. And yet it's, uh, the most difficult one to describe,

232
00:23:42,360 --> 00:23:49,560
but these are those, uh, different perspective on the same thing. And these are great candidates to,

233
00:23:49,560 --> 00:23:58,440
to, um, to be used as separate deployment units. So right. Microservices, right. But you can go with

234
00:23:58,440 --> 00:24:04,920
monolith application as well. And, um, that's what I also always recommend for starter to have

235
00:24:04,920 --> 00:24:10,760
something which is called a modular monolith. So a monolith with those bounded context with clear

236
00:24:10,760 --> 00:24:17,320
boundaries. And it's going to be easier. I'm not saying easy, but easier to, to migrate to microservices

237
00:24:17,320 --> 00:24:22,200
later on if you, if you really need to do so. And these are great candidates because there's a,

238
00:24:22,200 --> 00:24:29,880
these are oriented, uh, around products, uh, around business capabilities. So, um, they should be

239
00:24:29,880 --> 00:24:35,480
autonomous, uh, which is the definition of my, of a microservice, microservice, right. And they

240
00:24:35,480 --> 00:24:43,560
communicate, um, and synchronize state using eventual consistency. So that should work. And, um, that's why,

241
00:24:43,560 --> 00:24:49,240
in my opinion, the main design is getting a second lock right now because of the microservices hype,

242
00:24:49,240 --> 00:24:57,240
but, um, um, bounded context and those separate models from different, for different things were

243
00:24:57,240 --> 00:25:03,720
first. And then people just, uh, figured out, Hey, after all, we need the separate things which are

244
00:25:03,720 --> 00:25:10,520
separately deployed, separately scaled, um, should be autonomous. These are the same things that the

245
00:25:10,520 --> 00:25:16,120
bounded context are. Yeah. Yeah. Yeah. That's interesting that, that you mentioned like the, uh,

246
00:25:16,120 --> 00:25:23,560
uh, the transactional persistence problem, which, which is always an issue, right? Like basically like

247
00:25:23,560 --> 00:25:30,040
we were, um, we were doing some, some spring tour stuff, uh, I don't know, a month ago. And, and my,

248
00:25:30,040 --> 00:25:34,200
my little joke to tell with people is like, let's, when we have the Q and a part, let's see who the,

249
00:25:34,200 --> 00:25:38,200
how long it takes for someone to ask about transactions. Like, that's just always like,

250
00:25:38,200 --> 00:25:42,280
there's always someone who wants like two phase commit. And they're like, how do you do that?

251
00:25:42,280 --> 00:25:47,560
And then you're like, you don't do that. And they're like, okay, I don't know what to say now.

252
00:25:48,580 --> 00:25:54,020
Right. It's just like, it's just like this dead end. It's like, how, how, how do I fly? And you're

253
00:25:54,020 --> 00:26:01,040
like, you know, don't fly anyways, but it seems, and of course, I mean, you know, persistence and

254
00:26:01,040 --> 00:26:05,480
transactions and all that is always a problem, but it, it, that's another intriguing thing that if you're

255
00:26:05,480 --> 00:26:10,440
doing this event storming, right, you're kind of laying out all the events that happen to buy a

256
00:26:10,440 --> 00:26:17,260
book or book a taxi. Um, and then you divide it up into components or modulars, those being the

257
00:26:17,260 --> 00:26:24,600
domains. It's almost like it actually works out fine for there to be eventual consistency because

258
00:26:24,600 --> 00:26:29,800
those domains are separate enough that they kind of act independently and they can kind of synchronize

259
00:26:29,800 --> 00:26:34,160
with each other out of sync. Um, and I'm sure there's all sorts of problems with that, but that's

260
00:26:34,160 --> 00:26:39,560
another dimension to look at it is like, where are, where are the boundaries of minimal

261
00:26:39,560 --> 00:26:45,300
transactionality? I don't know what that means, but like, where do we find that we actually need

262
00:26:45,300 --> 00:26:49,520
a transaction? And that seems like a line somewhere that, that you can draw as well.

263
00:26:50,440 --> 00:26:58,520
Yeah. So I have, uh, my, my heuristic, um, to find actually, uh, those boundaries is let's ask

264
00:26:58,520 --> 00:27:06,160
ourselves a question, how our business model or how our business would have worked, uh, without

265
00:27:06,160 --> 00:27:13,080
computers? Because after all, acid and, uh, atomic transactions are a thing that's, uh, that, that,

266
00:27:13,080 --> 00:27:21,000
uh, was developed by us, by developers, right? Before technology, there was an industry of let's

267
00:27:21,000 --> 00:27:27,240
say banking and they had to work without transactions somehow. Right. And they were distributed because

268
00:27:27,240 --> 00:27:33,240
there wasn't the central bank unit. Uh, bank was distributed. You had like several places to pick

269
00:27:33,240 --> 00:27:39,240
your money from and several places to deposit your money too. Uh, and after all it, it had to work

270
00:27:39,240 --> 00:27:44,840
somehow without computers, without transactions, uh, it worked in an eventually consistent way.

271
00:27:44,840 --> 00:27:52,920
Right. And nowadays also banks, they, they, they, they, they, they work in a eventual, uh, eventually

272
00:27:52,920 --> 00:27:59,640
consistent, consistent manner. Um, let's say I can overdraw my account. Is that a good word? Overdraw?

273
00:28:00,520 --> 00:28:07,960
Oh yeah, for sure. Yeah. So we can do it. That's in fact our business model. Um, I want you to

274
00:28:07,960 --> 00:28:13,720
overdraw. I want you to be able to take advantage of eventually consistent, eventual consistency,

275
00:28:13,720 --> 00:28:21,880
because I'm going to apply penalty or some fees. Um, I will earn more money because I'm eventually

276
00:28:21,880 --> 00:28:27,080
consistent. Yeah. I mean, to interrupt, I think, I think another good example is like, I don't know,

277
00:28:27,080 --> 00:28:32,520
maybe this is putting a, uh, a round hole in a square peg or whatever, but like credit cards are

278
00:28:32,520 --> 00:28:38,840
kind of an eventually consistent system in a weird way. It's just like you, cause you don't actually,

279
00:28:39,640 --> 00:28:44,680
me, the credit card user doesn't pay the person. And then my bank account isn't reconciled at the

280
00:28:44,680 --> 00:28:50,360
point of purchase. It's just sort of like, there's this record that eventually I should pay it.

281
00:28:50,840 --> 00:28:56,360
And, and if I don't pay it, there are penalties. I mean, literal penalties for me not paying it,

282
00:28:56,360 --> 00:29:01,320
but it's not like, it's kind of like the credit card company is there to like cover the, uh, that

283
00:29:01,320 --> 00:29:06,360
time where, you know, the time where the transaction doesn't close. And then there's, you know, exceptions

284
00:29:06,360 --> 00:29:11,160
and errors get thrown that caused me to have to pay money if I don't do it. But it, it kind of allows

285
00:29:11,160 --> 00:29:17,640
this, uh, this fluidity of, of moving quickly. I guess there's like a credit limit, but I don't know.

286
00:29:17,640 --> 00:29:22,280
Anyways, that that's probably an easier thing to, cause I guess that's another thing built into the

287
00:29:22,280 --> 00:29:29,080
system is it's probably very rare that you have two credit card transactions at the same time,

288
00:29:29,080 --> 00:29:35,560
unless, unless you have like two of your subscription payments go at once while you're buying a jacket.

289
00:29:35,560 --> 00:29:39,400
But that would be very difficult for that all to happen at the same time. I don't know.

290
00:29:39,400 --> 00:29:47,000
Yeah. And, um, if you have those transactions and you have those multiple times, actually, maybe you are

291
00:29:47,000 --> 00:29:53,240
a fraud, right? So I can easily spot you. Yeah. Yeah. And you are trying to trick the system. Um,

292
00:29:54,120 --> 00:30:00,200
you are trying to get advantage of, uh, of my system being eventually consistent. And if I design my

293
00:30:00,200 --> 00:30:07,640
system in a manner that it's, um, capable of noticing the fact that you are trying to trick the system,

294
00:30:07,640 --> 00:30:12,840
that's fine. Right. And it's easier to model our system now in an eventually consistent manner,

295
00:30:12,840 --> 00:30:17,400
especially if we talk about, um, distributed system, there is no other way, by the way.

296
00:30:17,960 --> 00:30:24,600
Uh, but we, as, as, uh, technology industry, as, as software engineers, we tend to focus on those

297
00:30:24,600 --> 00:30:31,080
atomic transactions and we tend to focus on, Hey, what happens if this happens? And then if that happens,

298
00:30:31,080 --> 00:30:34,760
and then after all, after two minutes, if that's another thing happens.

299
00:30:35,880 --> 00:30:41,160
So we, we try to focus on those edge, edge conditions, whereas our business may be super

300
00:30:41,160 --> 00:30:49,320
happy with 95% of them, of the, all the possible conditions and cases, um, being implemented and

301
00:30:49,320 --> 00:30:57,080
those 5% or 2% being done manually or even maybe I can lose money in those 5%.

302
00:30:57,080 --> 00:31:05,160
If that allows me to go faster to production with my 95% of, of, uh, features done and leaving those

303
00:31:05,160 --> 00:31:13,080
two or 5% of edge cases, um, for a future work, that's fine. But again, it's not our decision,

304
00:31:13,080 --> 00:31:17,560
right? It's, um, it's a business decision. So I would always, in the main driven design,

305
00:31:17,560 --> 00:31:22,600
I was, I would always look for answer in the domain itself, right? What happens if that,

306
00:31:22,600 --> 00:31:25,640
and what's the risk and what's the cost? What's the cost?

307
00:31:25,640 --> 00:31:29,800
So I, I distracted us here. Let's, let's go back to either the, uh, the taxi example or the book

308
00:31:29,800 --> 00:31:36,280
buying example. Like what, like what, how do, what, how do we define and what are the domains we have,

309
00:31:36,280 --> 00:31:43,640
we have in those examples? All right. So again, there's no such of like, um, um, silver bullet to,

310
00:31:43,640 --> 00:31:50,680
to define those domains. You have to, um, be present during this, uh, event storming session.

311
00:31:50,680 --> 00:31:58,120
And by being present, I mean, look at what, uh, people are talking about. So there might be people

312
00:31:58,120 --> 00:32:04,920
talking about, um, a taxi driver or another term like an order. We already mentioned order,

313
00:32:04,920 --> 00:32:10,360
and they will have different things in mind. The same, like we used, uh, with our book example,

314
00:32:10,360 --> 00:32:16,600
right? Um, so they will care about different properties of an order. Most probably people

315
00:32:16,600 --> 00:32:22,920
from claims, they will care about, um, a route, right? Of, of our right, because maybe the client

316
00:32:22,920 --> 00:32:29,640
is complaining about, um, the chosen route was too long and I paid too much, or I spent too much

317
00:32:29,640 --> 00:32:38,120
time in the taxi, uh, in the car, uh, whereas other people, uh, from customer service or from,

318
00:32:38,120 --> 00:32:44,920
um, you know, in, in, in the old days, there was this lady trying to match your order to a available

319
00:32:44,920 --> 00:32:48,920
driver, right? Yep.

320
00:32:48,920 --> 00:32:55,160
Uh, there was this person trying to match, uh, your order to, to available driver. Now it's, uh,

321
00:32:55,160 --> 00:33:01,720
it's technology like Uber has its own engine to do so. Um, for this kind of a person or, or for this

322
00:33:01,720 --> 00:33:08,520
kind of a piece of, uh, of model of code, um, and all there would be, there is, uh, there's no order

323
00:33:08,520 --> 00:33:13,240
yet, by the way. There is, uh, a taxi available, a taxi driver available, and there is, uh, three

324
00:33:13,240 --> 00:33:18,680
customers waiting to be picked up at this specific location. And I'm trying to match something and I'm

325
00:33:18,680 --> 00:33:24,680
creating an order, but our order doesn't have anything when it comes to route yet. There might

326
00:33:24,680 --> 00:33:29,080
be proposed route, but it's just a proposed route, right? I can agree to this proposed route as a

327
00:33:29,080 --> 00:33:35,080
customer. Uh, and then there is something different at the end of the, of the, of my drive, the driver,

328
00:33:35,400 --> 00:33:41,720
the driver, he might have taken a different route because there was a traffic jam or the customer asked

329
00:33:41,720 --> 00:33:48,680
him to do so. Um, so an order for the claim department would be something different, um,

330
00:33:48,680 --> 00:33:56,280
from, uh, would be something different than it is to, to this customer and taxi drivers,

331
00:33:57,320 --> 00:34:02,120
uh, subdomain, I would call like this. It's easier to come up with, uh, with something when it comes to

332
00:34:02,120 --> 00:34:08,200
this book, bookstore department, because I'm not familiar with, with, with, with taxis and how they work

333
00:34:08,200 --> 00:34:13,640
underneath. But you would look, um, the heuristic is that you would look for, for people talking about

334
00:34:13,640 --> 00:34:17,720
different things and you would try to find misunderstanding between them. And they use the

335
00:34:17,720 --> 00:34:23,720
same term. Like product is something we sell and other people, other person would tell a product is

336
00:34:23,720 --> 00:34:29,080
something we buy because maybe in our company we do both, right? We sell products and we also buy

337
00:34:29,080 --> 00:34:34,760
products, right? We sell cars, right? We have to buy something to actually build our car. It's different

338
00:34:34,760 --> 00:34:41,160
department, the same world. Um, and that would be the first heuristic to, to try to decouple to,

339
00:34:41,160 --> 00:34:45,880
into those domains, right? Yeah. And I mean, tell me, tell me if I'm understanding this right,

340
00:34:45,880 --> 00:34:51,560
but I feel like I've, I've, I've, I've learned a new angle on this is like, I guess I've noticed.

341
00:34:51,560 --> 00:34:59,400
So basically this conflict that comes up in event storming is used as a heuristic to find different

342
00:34:59,400 --> 00:35:05,000
domains, which is to say, whenever conflict comes up between like, Oh, I think a book means this and

343
00:35:05,000 --> 00:35:09,960
a book or someone else thinks a book mean that the, the first thing might be like, well, one of you is

344
00:35:09,960 --> 00:35:14,600
wrong, right? Like if it's within the same domain, you just might be thinking, you know,

345
00:35:16,040 --> 00:35:21,160
maybe you need to combine your two understandings or actually a book does not include a light bulb.

346
00:35:21,160 --> 00:35:27,000
So that's a misunderstanding of what books are, uh, unless it's a really funny book. Um,

347
00:35:27,000 --> 00:35:30,920
but what's interesting is the second thing in my mind is like, if there's a conflict,

348
00:35:30,920 --> 00:35:36,520
then that means they're talking about two concepts that are different enough that they would belong in

349
00:35:36,520 --> 00:35:41,400
different domains. So as like the facilitator of some event driven thing, you're basically like, Oh,

350
00:35:42,200 --> 00:35:47,080
we should look at this stuff on the margin, these conflicts and see if that helps us crack apart and

351
00:35:47,080 --> 00:35:54,760
find what a domain is. Yeah, so exactly. Um, that was a great example of this. Hey, you are wrong with

352
00:35:54,760 --> 00:36:00,440
this book because the book doesn't contain a light bulb. It can happen. Of course, because after all,

353
00:36:00,440 --> 00:36:07,560
even storming is a technique to, to share knowledge. So, um, if my knowledge is not correct and someone

354
00:36:07,560 --> 00:36:12,040
will, uh, tell me the truth, Hey, the book is something like this in this context, that's fine.

355
00:36:12,040 --> 00:36:17,800
What can happen as well? But most probably, um, those misconceptions will happen from people,

356
00:36:17,800 --> 00:36:23,640
between people, uh, that are coming from different, let's say department. I'm not going to say departments.

357
00:36:23,640 --> 00:36:28,840
It's a wrong thing, but, um, different perspectives, right in the ideal world from different departments,

358
00:36:28,840 --> 00:36:34,520
but, uh, in normal organization and regular organization, we have people that, uh, know

359
00:36:34,520 --> 00:36:40,840
something from their department, at least a little bit, uh, of something from the department they work

360
00:36:40,840 --> 00:36:48,280
closely with. Maybe they have, uh, they have a feeling that they know something about this department that

361
00:36:48,280 --> 00:36:55,080
sits next to them does by accident. So they have feelings about things in the different departments.

362
00:36:55,080 --> 00:36:59,720
They have feelings about their knowledge in their department. And actually I can spot that during

363
00:36:59,720 --> 00:37:04,680
this, uh, during this event storming session and, and try to propose something. But again,

364
00:37:04,680 --> 00:37:10,920
it's not a heuristic is it's a heuristic. It's not a deterministic outcome that you would all end up

365
00:37:10,920 --> 00:37:16,520
with. It's not like, Hey, if you do eight hours of event storming, you will, you will come up with,

366
00:37:16,520 --> 00:37:22,440
uh, with nicely, nice boundaries of a software. No, exactly. I mean, kind of starting with the vague,

367
00:37:22,440 --> 00:37:28,680
ambiguous hand wavy stuff we were talking about, right? Like when, what you need is a tool to like

368
00:37:28,680 --> 00:37:34,200
discover something definitive. Right. So it's not like, like, it sounds like doing this process,

369
00:37:34,200 --> 00:37:40,520
like it's not, it's not prescriptive in what the end is. It's just like, how do we surface these,

370
00:37:40,520 --> 00:37:46,440
these things that then we make decisions about, right? Like you need some, some way of, uh,

371
00:37:46,840 --> 00:37:51,480
pulling up, dredging all this stuff from the deep, which is, or the shallow, I don't know,

372
00:37:51,480 --> 00:37:57,880
uh, which, which is always, uh, difficult. And then I, I guess, I guess also not to be all the

373
00:37:57,880 --> 00:38:02,440
negative case, you might also discover different things that are actually the same thing in this

374
00:38:02,440 --> 00:38:08,440
process and consolidate them. Yep. That, that can also happen. So another thing that, uh,

375
00:38:08,440 --> 00:38:17,240
uh, uh, that is very common and Alberto describes that as pivot events, pivot events are the events

376
00:38:17,240 --> 00:38:23,400
that, uh, are really important. For instance, let's say that we, let's, let's come back to our

377
00:38:23,400 --> 00:38:31,480
credit card example. So, um, I'm opening a website because I want a new credit card and I'm looking at

378
00:38:31,480 --> 00:38:38,600
different offers, right? So I have like, uh, let's say I have three offers, um, with different fees,

379
00:38:38,600 --> 00:38:44,600
with different interest rates, with different withdrawal fees, uh, and different, um, bidding

380
00:38:44,600 --> 00:38:51,080
cycles. Let's say I'm picking one of those and I'm signing a contract and, uh, I get my credit

381
00:38:51,080 --> 00:38:59,720
card, right? Um, and my credit card engine, uh, the one that actually calculates the withdrawal fees

382
00:38:59,720 --> 00:39:06,200
and interest rates has to know about the actual values. What's this guy, what's this guy's withdrawal

383
00:39:06,200 --> 00:39:13,080
fee? Because he just has, we withdraw money. We have to apply some fees. So developers think about

384
00:39:13,080 --> 00:39:19,000
this as, Hey, I have a relationship from my, I'm talking about database right now. So I'm having,

385
00:39:19,000 --> 00:39:26,840
let's say foreign key relationship or constraint from, uh, my credit card to my offer, right? But

386
00:39:26,840 --> 00:39:33,400
guess what? Those two have different life cycles, right? So it doesn't really matter what kind of

387
00:39:33,400 --> 00:39:40,040
offer, um, you are pointing to. It only matters what kind of withdrawal fee or withdrawal of, or

388
00:39:40,040 --> 00:39:47,640
interest rates you have because signing a contract is a transition event that creates you, um, current

389
00:39:47,640 --> 00:39:54,200
snapshot of the offer and copies and paste that to your, to your credit card domain. And then you

390
00:39:54,200 --> 00:39:58,760
have this offer that has its own life cycle and you can actually delete that the next day because

391
00:39:58,760 --> 00:40:04,520
maybe it's not rental. Uh, but your credit card argument, it's still there with this, uh, with those

392
00:40:04,520 --> 00:40:11,000
values, right? So we have those transition events in which, um, things behave differently. Like, uh,

393
00:40:11,800 --> 00:40:18,520
after signing contract, I cannot change withdrawal fee in my, uh, in my credit card, right? But I can

394
00:40:18,520 --> 00:40:24,120
still change that. So these are called the pivot events. These are described by the way. I recommend

395
00:40:24,120 --> 00:40:31,720
you to, I recommend to read, uh, Alberto's book called event storming all of the knowledge, uh, that you

396
00:40:31,720 --> 00:40:38,280
need when it comes to even storming. It's there. Yeah. Yeah. So, so let's say we've drawn out. I

397
00:40:38,280 --> 00:40:44,840
think, I think you hit on a good example there. Two separate domains are, uh, a credit card offer

398
00:40:45,480 --> 00:40:52,360
and then the credit card when it exists for using it. Right. Let's say accounting.

399
00:40:52,360 --> 00:40:56,680
Uh, is it called accounting? Something like this. Yeah. Yeah. Yeah. And, and one of them is just

400
00:40:56,680 --> 00:41:01,960
sort of like, here's our deals and our, our, you know, the promotion that we have for a credit card.

401
00:41:01,960 --> 00:41:06,360
And then once you're actually using the credit card, that's a whole separate domain. Right. And

402
00:41:07,160 --> 00:41:15,000
you don't want to have like the same schema or object or whatever for the credit card on either side.

403
00:41:15,000 --> 00:41:20,600
There might be a lot of similarity. And like you say, uh, you will probably copy over

404
00:41:21,240 --> 00:41:28,520
or reference, uh, the promotion when you have the real credit card. Uh, but you don't really,

405
00:41:29,240 --> 00:41:34,280
those don't need to be the same thing. And in fact, it would be very difficult for them to be the same

406
00:41:34,280 --> 00:41:40,760
thing because for example, you might want to say, uh, on a promotional offer, we would like to add some

407
00:41:40,760 --> 00:41:46,120
new stuff to it or take things away. And we don't want to have to like sync up with the real credit

408
00:41:46,120 --> 00:41:51,240
card when, when, for whatever reason, right? Like maybe eventually we'll sync those things up,

409
00:41:51,240 --> 00:41:55,960
but for now we want to keep them independent so we can evolve them, uh, on their own. So I don't know.

410
00:41:55,960 --> 00:42:01,080
I mean, those seem like two good domains, right? Sure. Yes. And, uh, let's imagine if you actually

411
00:42:01,080 --> 00:42:06,920
have this foreign key constraint and you want to delete the offer because it's not rental. And then you have,

412
00:42:06,920 --> 00:42:13,640
hey, I cannot delete this offer because two or three credit cards, uh, actually they point to this

413
00:42:13,640 --> 00:42:19,320
offer. So you have to do something with your data. So what do you do? Uh, so you mark this offer as

414
00:42:19,320 --> 00:42:24,680
not rental. So you add the flag and then you have if statements if you're in your code in all the places

415
00:42:24,680 --> 00:42:32,600
when you use your offer, if it's deleted because of the, um, of the rental thing, then imagine the,

416
00:42:32,600 --> 00:42:38,280
the, the, the degree of accidental complexity that you, that you are bringing to your solution,

417
00:42:38,280 --> 00:42:45,000
to your solution space, just because, uh, we didn't do our job during the analysis of the problem space,

418
00:42:45,000 --> 00:42:51,320
right? Yeah, no, that makes sense. So let's, let's see. We gotta like, so what do you call these

419
00:42:51,320 --> 00:42:57,080
three that you gotta, is the credit card like an entity or what, what's, what's the lingo for that?

420
00:42:57,080 --> 00:43:05,880
Uh, it depends. So the ultimate answer of a consultant, it's, uh, um, so these two,

421
00:43:05,880 --> 00:43:12,520
they, they might be a different bounded context. Um, and in those bounded context, you build, um,

422
00:43:12,520 --> 00:43:19,560
you find your consistency boundaries. So we have already talked about, I need those two things to be

423
00:43:19,560 --> 00:43:27,640
changed in one transaction. Let's say if I do a withdrawal, always, I want to, um,

424
00:43:28,600 --> 00:43:36,920
enforce some business rules. For instance, a business rule says, um, I cannot withdraw more

425
00:43:36,920 --> 00:43:43,080
money than I actually have on my account. That seems like a valid business rule, right? Um,

426
00:43:44,040 --> 00:43:54,840
and also you have a rule saying, for instance, I cannot have more than 45 or 50 or 100 withdrawals

427
00:43:54,840 --> 00:44:00,680
during one week. I don't know why that's what our business wants, right? I'm just, uh,

428
00:44:01,880 --> 00:44:08,200
trying to think about different invariants. These are called invariants and you have to somehow model

429
00:44:08,200 --> 00:44:14,440
your code so that, uh, it changes the two, those two things in a strongly consistent manner. So we are

430
00:44:14,440 --> 00:44:20,120
consistent immediately. I don't want to change my balance and then in an eventually consistent

431
00:44:20,120 --> 00:44:25,960
manner, uh, change my withdrawals counter or something like this, because it might create a

432
00:44:25,960 --> 00:44:34,520
slight window, a time of window, window frame, um, in which our invariants may be, may be broken,

433
00:44:34,520 --> 00:44:38,280
right? Because there will be different people, different persons trying to do the same thing.

434
00:44:38,280 --> 00:44:43,320
And the, the, the second thing is not updated yet. So you try to find those, those things we

435
00:44:43,320 --> 00:44:49,160
have to, which has to be, which have to be strongly consistent, immediately consistent, and you model

436
00:44:49,160 --> 00:44:56,120
those as aggregates. So aggregate would be a tactical pattern from domain driven design. It comes from

437
00:44:56,840 --> 00:45:01,720
actually, I think, and maybe it's not a popular opinion, but it doesn't different from, uh,

438
00:45:01,720 --> 00:45:08,920
object oriented design. Um, it's an object which aggregates different objects and exposes some

439
00:45:08,920 --> 00:45:15,000
behaviors so that you can, you can perform comments and you, you run comments on this object. You don't

440
00:45:15,000 --> 00:45:22,440
talk to, um, to the, to the inside of your aggregate. So we don't talk to different objects that your

441
00:45:22,440 --> 00:45:29,320
aggregate owns. You only talk to your root of your aggregate. So it's called aggregate route. So you

442
00:45:29,320 --> 00:45:34,600
perform commands to your aggregate route and your aggregate route is responsible for spreading the

443
00:45:34,600 --> 00:45:40,840
information to all of the objects that it has and to all of the objects that need, uh, those

444
00:45:40,840 --> 00:45:46,600
information so that I can change any, everything in one transaction. That means that you always change

445
00:45:46,600 --> 00:45:55,400
one for aggregate in your transaction, which also, uh, gives us, uh, brings us to a point in which our use

446
00:45:55,400 --> 00:46:01,720
case typically would look like this. I have an application service for my use case, let's say

447
00:46:01,720 --> 00:46:08,680
withdraw money. Uh, of course I'm simplifying this right now, but it would like, it would look like

448
00:46:08,680 --> 00:46:14,680
this. First line of code would be, I want to load aggregate responsible for withdrawing money from my

449
00:46:14,680 --> 00:46:20,680
repository. I want to perform subcommand on this aggregate and I want to save this aggregate. And it's

450
00:46:20,680 --> 00:46:25,400
it's aggregate, it's aggregate, it's aggregates responsibility to spread the knowledge, to spread

451
00:46:25,400 --> 00:46:30,200
the effects, uh, on all of the things that has to be changed, uh, in a strongly consistent

452
00:46:30,200 --> 00:46:36,280
manner. And then you have those aggregates and then they can also, guess what? They can emit

453
00:46:36,280 --> 00:46:43,880
those domain events say, okay, the invariants, uh, all of the invariants are met. I can withdraw money,

454
00:46:43,880 --> 00:46:50,680
which, uh, which means that the money was withdrawn. So aggregate, it accepts the command, checks the

455
00:46:50,680 --> 00:46:56,040
invariants. And if, if it's fine with the invariants, it's going to emit the event saying something has

456
00:46:56,040 --> 00:47:02,440
done. So the state has changed and different things in like different bounded context, let's say some

457
00:47:02,440 --> 00:47:10,200
reporting the bounded context, um, or other bounded context, they can subscribe to those events in a

458
00:47:10,200 --> 00:47:18,520
eventually consistent manner and update some things. The crucial story, the crucial story of this process

459
00:47:18,520 --> 00:47:25,080
is that you find those things that needs to be changed in a strongly consistent fashion and you model

460
00:47:25,080 --> 00:47:31,480
them as aggregates in one bounded context. And then you have different bounded contexts and they need some

461
00:47:31,480 --> 00:47:37,000
information from other bounded contexts, but then you modify those different bounded contexts by

462
00:47:37,000 --> 00:47:41,400
subscribing to those events in an eventually consistent manner. Make sense?

463
00:47:43,080 --> 00:47:48,520
Yeah. Yeah. I mean, it's almost like when you need to have a transaction or something like that,

464
00:47:49,080 --> 00:47:54,760
you basically make an aggregate to handle it for you. If it's crossing all the domains and then

465
00:47:54,760 --> 00:48:02,200
that's sort of like your point of locking, I guess. And then the other thing I think that,

466
00:48:03,320 --> 00:48:08,760
the other technology that's sort of like key to all this is using an event driven model where,

467
00:48:09,720 --> 00:48:15,720
and maybe this is how transactions work really low level, but instead of kind of having a linear way

468
00:48:15,720 --> 00:48:21,560
of syncing things up, you're sending out events that other things are listening for and they can respond

469
00:48:21,560 --> 00:48:26,360
to and blah, blah, blah. But then that's another, another key to like this model of doing things is the way

470
00:48:26,360 --> 00:48:34,200
you're basically sending messages out to use old OO terms. And the thing that receives the message is

471
00:48:34,200 --> 00:48:37,640
in charge of doing whatever and saying that, that it's fine with it.

472
00:48:39,080 --> 00:48:45,400
Yeah. I agree. I agree. Especially when you said that, um, this is our locking point and you described

473
00:48:45,400 --> 00:48:51,800
aggregates as locking points because one of the frequent questions, um, asked by people who are

474
00:48:51,800 --> 00:48:57,400
introduced to this concept of aggregates and, uh, objects in domain driven design, if you actually choose

475
00:48:57,400 --> 00:49:03,320
to do, to do object oriented domain driven design, because you can do functional style as well. But one of the

476
00:49:03,320 --> 00:49:11,720
questions is, um, how do I do, um, optimistic slash pessimistic locking? So how do I do a concurrency

477
00:49:11,720 --> 00:49:18,280
control? And it's actually pretty simple. If you have those consistency boundaries found and you model

478
00:49:18,280 --> 00:49:24,520
them as aggregates, aggregate is the point where you apply, let's say optimistic locking and that's it.

479
00:49:24,520 --> 00:49:30,040
That means that one person can change an aggregate in a given time. If there is a race condition,

480
00:49:30,040 --> 00:49:34,760
I'm going to throw an exception and that's it. So you, you, you do it on your aggregate level.

481
00:49:35,400 --> 00:49:40,520
And then, um, you have those different, um, you have those different concepts, as you mentioned,

482
00:49:40,520 --> 00:49:46,440
like, um, instead of changing state all of the time, I'm have, I'm having this log of things that

483
00:49:46,440 --> 00:49:52,200
actually has happened right in my journal because I can actually store those domain events somewhere.

484
00:49:53,320 --> 00:49:57,640
Yeah. Yeah. And then you can play them back and do all sorts of things once you have them there.

485
00:49:57,640 --> 00:50:02,200
I mean, it, it always seems like, I don't really know how file management works very well, but it

486
00:50:02,200 --> 00:50:07,240
seems like that's a shift that's been happening recently is that idea of journaling and logging

487
00:50:07,240 --> 00:50:13,080
things has, uh, you can probably hear my dog playing with that toy. She's a frequent guest star

488
00:50:13,080 --> 00:50:20,120
on all of that material. Uh, that's right. But like this idea of journaling and logging,

489
00:50:20,120 --> 00:50:25,480
like gets raised out of the lower levels up to the top of the application stack to handle

490
00:50:25,880 --> 00:50:29,800
distributed transactions a lot easier, which I don't really know what to do with that.

491
00:50:29,800 --> 00:50:37,240
But that's an interesting notion. Um, I think it, um, again, it's a, it's an old concept,

492
00:50:37,240 --> 00:50:44,440
uh, this generic concept that, um, that's now give that's, uh, that has been given a second

493
00:50:44,440 --> 00:50:48,280
law because of domain-driven design, not only because of domain-driven design,

494
00:50:48,280 --> 00:50:54,040
it's a great query concept. You have those events, uh, those logs, those journals in,

495
00:50:54,040 --> 00:50:57,960
let's say in any database, right? You have the thing called transaction log and

496
00:50:57,960 --> 00:51:04,520
it's actually a up and only right ahead log of your transactions that you write to your database.

497
00:51:05,960 --> 00:51:10,920
Yeah, that makes sense. If you want to replicate your database, you just share your transaction log

498
00:51:10,920 --> 00:51:16,920
to a different database and say to this different database, if you want to be, if you want to have

499
00:51:16,920 --> 00:51:22,360
my state, just replay this transaction log. Here is the start. Here is the, the end. If you play it in

500
00:51:22,360 --> 00:51:30,840
the exact order as I did, you will have the same state, right? Um, so I can actually replicate my

501
00:51:30,840 --> 00:51:35,640
database by showing this transaction log. Yeah. Yeah. And then recover things from it as well.

502
00:51:35,640 --> 00:51:41,880
If it's, if, if, if your log is stored somewhere that wasn't damaged, obviously, but yeah, that's

503
00:51:41,880 --> 00:51:48,760
interesting. Like, like basically, uh, computers don't have free will. They're like very deterministic.

504
00:51:48,760 --> 00:51:54,440
So you can, there's no variability in replaying what they were. It should, uh, be the same thing.

505
00:51:54,440 --> 00:52:00,440
So, so then, so then before we wrap up, let's go back to the original question. So should enterprise

506
00:52:00,440 --> 00:52:04,760
architects be the ones helping define these domains? Is that, is that something we can, uh,

507
00:52:04,760 --> 00:52:12,520
a bone we can throw to them? Um, I think they should be involved, but to be honest, what's the point of,

508
00:52:12,520 --> 00:52:19,000
uh, having one person that's trying to think about those domains with, I mean, one person from the

509
00:52:19,000 --> 00:52:24,600
technology perspective, from the, uh, from our background, from, um, from development team,

510
00:52:25,080 --> 00:52:29,800
I should, everyone, I think everyone should be involved at some point, um,

511
00:52:31,640 --> 00:52:33,480
in order to distill those domains.

512
00:52:33,480 --> 00:52:36,760
Yeah. Well, maybe to reverse it, it's sort of like,

513
00:52:38,040 --> 00:52:42,440
it's, it seems like part of what, well, let me not use the phrase enterprise architect,

514
00:52:43,000 --> 00:52:49,640
at some point, let's say in a, in a large bank or any bank, you've got a lot of stuff going on.

515
00:52:50,680 --> 00:52:58,360
And it's almost like someone needs to coordinate. Here's, here's all the stuff so that we don't

516
00:52:58,360 --> 00:53:04,600
have like five different ways of offering a credit card. And, and the reason you do that is so that

517
00:53:05,000 --> 00:53:09,880
not, well, one, it's not efficient, but also so that it's easier for other people to interact

518
00:53:09,880 --> 00:53:15,720
with that. Right. That like, if I'm, if I'm doing what I called earlier, the real credit card that

519
00:53:15,720 --> 00:53:20,920
gets used day to day, it's really annoying if I have to go talk to five different things or teams

520
00:53:20,920 --> 00:53:28,120
or whatever to reconcile what this offer is. So, and then those kinds of problems across any large

521
00:53:28,120 --> 00:53:33,880
organization that, that exists a lot. So it seems like something or someone should be involved in like,

522
00:53:33,880 --> 00:53:40,360
trying to kind of like make the domains of domains, not, not to foist, uh, the usual,

523
00:53:40,360 --> 00:53:46,440
like, uh, you know, team of teams thing and scrum of scrums and all of that annoyance, but it,

524
00:53:46,440 --> 00:53:51,320
you know, it, it seems like there should be some, it would be helpful for there to be some reviewing

525
00:53:51,320 --> 00:53:57,160
of like, have we defined all these domains in a way that helps each of them out? Um, and like,

526
00:53:57,160 --> 00:54:02,360
I don't know, that's sort of like a notion of what EAs kind of do. And it's not so much that it's like,

527
00:54:02,360 --> 00:54:09,320
this is what an EA should do is I feel like if they're a good EA, they kind of know what's going

528
00:54:09,320 --> 00:54:14,040
on in the rest of the organization. And, and to your point, they can participate in the session with

529
00:54:14,040 --> 00:54:19,160
everyone else, but they can kind of give that input of like, Oh, and then it goes over here and then it

530
00:54:19,160 --> 00:54:24,760
goes over there and like all of that stuff. I don't know. It might also be trying to find like a, uh,

531
00:54:24,760 --> 00:54:30,040
what would you call it? Not a, not a solution to a problem, but like a, uh, to find something for

532
00:54:30,040 --> 00:54:35,880
them to do. But it seems like something that that would map to what our, our, our sort of optimistic

533
00:54:35,880 --> 00:54:41,160
notions of, or, or, yeah, they should be for sure. They should be involved. Also, uh,

534
00:54:41,160 --> 00:54:47,880
the outcome should be somehow shared across the organization. Right, right, right. Yeah. I guess

535
00:54:47,880 --> 00:54:53,000
that's another good point is, is like the, the, uh, I, you know, people never liked the word governance,

536
00:54:53,000 --> 00:54:59,080
but there's a certain governance of like, now that we've determined these domains, we should probably

537
00:54:59,080 --> 00:55:08,200
not change them tomorrow. This is, uh, this is never going to work like this. Right. Uh, so it sounds

538
00:55:08,200 --> 00:55:13,640
like a big design upfront, which, uh, you know, it's again, it's the same thing. It's, uh,

539
00:55:13,640 --> 00:55:20,360
our current understanding of the actual problem and our current understanding might change tomorrow

540
00:55:20,360 --> 00:55:26,120
because guess what? Our software development thing is a learning process, right? And we gain more

541
00:55:26,120 --> 00:55:31,880
insights tomorrow. And, um, what we discovered yesterday might not be relevant tomorrow, or there

542
00:55:31,880 --> 00:55:40,680
was a rapid change in our, uh, market that, um, forces us to actually redefine those. Um, and, uh,

543
00:55:40,680 --> 00:55:48,040
what I think about this is that, um, if you do proper analysis and not only analysis, but if you do

544
00:55:48,040 --> 00:55:54,840
proper architecture and by proper, it's always, uh, um, hard to describe what's proper, what's good,

545
00:55:54,840 --> 00:55:59,560
what's well-crafted architecture, right? Uh, my definition, it's not mine, but I heard,

546
00:55:59,560 --> 00:56:05,800
I have heard some, some time ago, this definition is that a good architecture is an architecture that

547
00:56:05,800 --> 00:56:14,520
allows you to postpone the, the important decision as, um, as long as you can. Yeah. Right. And allows

548
00:56:14,520 --> 00:56:19,720
you to change those decisions, right? Uh, if there are important decisions, I would like to, uh,

549
00:56:19,720 --> 00:56:25,880
I would like to make them, um, in the future. Why? Because in the future I will have more knowledge

550
00:56:25,880 --> 00:56:31,880
than I have currently. So my decision may be, may be different than, uh, than the decision that I

551
00:56:31,880 --> 00:56:37,160
would make today. And most probably it will be better in one week or in two weeks than it is today.

552
00:56:37,160 --> 00:56:42,040
Yeah. Yeah. It's, it's sort of like, uh, uh, to mix domains up, so to speak. It's like a, uh,

553
00:56:42,040 --> 00:56:49,080
uh, it, I think it's the contrapositive of, uh, an accounting term called a net present value

554
00:56:49,080 --> 00:56:54,600
or NPV, which is basically like, you know, money today is better than money tomorrow.

555
00:56:55,160 --> 00:57:00,680
Sure. And, and where, whereas the, it being the contrapositive, if I know if I'm using that term,

556
00:57:00,680 --> 00:57:07,320
right, is basically like knowledge tomorrow is more valuable than knowledge today or not valuable in

557
00:57:07,320 --> 00:57:12,760
the sense of like, I will know more. And so therefore, if I can, if I can act on knowledge of

558
00:57:12,760 --> 00:57:18,040
tomorrow, that's better than acting on the knowledge that I have today. Uh, which, yeah, I mean that,

559
00:57:18,040 --> 00:57:22,600
that, that, uh, I had, uh, I, one of my old architect friends, he used to call this, uh,

560
00:57:22,600 --> 00:57:28,520
architectural runway. Like you want as long a runway as possible. And, uh, and it's, it's good to build

561
00:57:28,520 --> 00:57:33,480
that into the system that you have, uh, that flexibility, but yeah, I mean, your point stands,

562
00:57:33,480 --> 00:57:42,360
right? Like, uh, uh, I mean, tomorrow is maybe too short of a period, but you, you want your system to be

563
00:57:42,360 --> 00:57:49,720
able to adapt and change. And, and to some extent that requires some, some hygiene, I guess, like

564
00:57:49,720 --> 00:57:55,800
that flexibility has to be built into the system somehow that, uh, that it actually works out well.

565
00:57:55,800 --> 00:58:00,120
Like if we invent some new type of cash tomorrow, we don't want to, we don't want to have to like,

566
00:58:00,120 --> 00:58:03,640
have that reinvent all of the software that we use for banking.

567
00:58:03,640 --> 00:58:13,000
Exactly. Exactly. And, uh, but it requires us to somehow, uh, be able to get this knowledge or to

568
00:58:13,000 --> 00:58:19,080
gather this knowledge in the future. Uh, I have recently, uh, read about, uh, five levels of

569
00:58:19,080 --> 00:58:26,760
ignorance. Um, and it hit me because, uh, I haven't thought about this, uh, in that way. So five levels of

570
00:58:26,760 --> 00:58:33,000
ignorance, uh, the, the, the, the level zero is, um, it, it, it, it says that you don't have any

571
00:58:33,000 --> 00:58:38,120
ignorance in your thinking with me, which means, you know, that there is a certain problem to be

572
00:58:38,120 --> 00:58:42,600
solved and you know, every possible aspect of this problem to be solved. And you know that there

573
00:58:42,600 --> 00:58:49,320
are no more aspects. So in a short term, uh, in short words, a long, long story short, it's,

574
00:58:49,320 --> 00:58:54,280
you know, everything. Then there is a first level of ignorance, which says, because that was zero

575
00:58:54,280 --> 00:59:00,040
level. Uh, the first level would be, I know some things I know a lot, and there are some things

576
00:59:00,040 --> 00:59:05,240
that I don't know, but I know that they are there. So it's like known unknowns, right? Um,

577
00:59:05,240 --> 00:59:12,120
there was level two, which says, um, I have, I know something and I think it's, it's all of the

578
00:59:12,120 --> 00:59:17,160
things that I need to know, but there are other things and I don't know about them. And then there

579
00:59:17,160 --> 00:59:26,120
is level three, which means, um, um, I know something and I think that there is, uh, that

580
00:59:26,120 --> 00:59:32,920
that's all. And I have no one to ask about what the, uh, is there something more? And the level

581
00:59:32,920 --> 00:59:37,960
fit is that I don't have any idea about the five level of ignorance. So I'm just totally ignorant.

582
00:59:37,960 --> 00:59:44,680
And, uh, yeah. And again, this, uh, knowledge crown drink and, uh, even storming sessions, uh,

583
00:59:44,680 --> 00:59:51,000
helps us to, to actually degree, uh, decrease the, the, the, the, the level of ignorance in our

584
00:59:51,000 --> 00:59:58,440
understanding of the, of the problem space so that our solution space, um, is flexible and can be

585
00:59:58,440 --> 01:00:03,880
changed, uh, because there was a, um, market change that we need to react upon.

586
01:00:03,880 --> 01:00:07,880
Yeah. Yeah. Like, like I was thinking with our credit card example, like, you know,

587
01:00:07,880 --> 01:00:13,240
debit cards come about and then you got to do something with that, right? Like, like that,

588
01:00:13,240 --> 01:00:18,680
that must've been, or, or even chip and pin or whatever, right? Like things evolve and it's just

589
01:00:18,680 --> 01:00:23,880
like, well, now we got to go revisit everything and GDPR, right? Yeah. Yeah. Even worse.

590
01:00:26,040 --> 01:00:31,000
I, I always, whenever I run into my, uh, you know, I, I talked to my, uh, my Americans,

591
01:00:31,000 --> 01:00:35,240
friends, friends who haven't moved abroad, you know, my, my fellow Americans are always like,

592
01:00:35,240 --> 01:00:40,920
Oh, be careful how you solve this privacy problem. Cause basically like GDPR means every page I go to

593
01:00:40,920 --> 01:00:45,720
now that I'm in the Netherlands, I have to click on a button before I get anything. That's as far as I

594
01:00:45,720 --> 01:00:51,880
can tell, that's what it means. Now I have to click on something. Yeah. From, from user's perspective.

595
01:00:52,440 --> 01:00:56,280
Exactly. Exactly. All right. Well, I, this is a good overview. I think, I think,

596
01:00:56,280 --> 01:01:01,000
I think this overview, like, as we started off with never, never complete or anything,

597
01:01:01,000 --> 01:01:05,880
but I feel like, I feel like now, if I went and read about the mind driven design,

598
01:01:05,880 --> 01:01:10,760
I would understand what the point was and the outcomes. And I would have a good grasp on it.

599
01:01:10,760 --> 01:01:15,320
And then, and then also finally, I was looking this up, you know, you're going over the five

600
01:01:15,320 --> 01:01:21,160
levels of ignorance and I was hoping the food pyramid, uh, would fit in this. So food pyramid

601
01:01:21,720 --> 01:01:28,600
has four layers. I think it's like, let's see vegetables, fruits and vegetables, grains, meat,

602
01:01:29,320 --> 01:01:34,680
and dairy. I don't know. Maybe if you separated out fruits and vegetables, you'd have five layers,

603
01:01:35,800 --> 01:01:42,120
but there's also the five dysfunctions of teams. You remember that book? So you've got five there.

604
01:01:42,120 --> 01:01:46,600
And then in lean manufacturing, you have the five whys. So whenever you're solving a problem,

605
01:01:46,600 --> 01:01:52,440
you always ask why five times to go down five levels. And then check this out. Maslow's pyramid

606
01:01:52,440 --> 01:01:59,160
of needs, five levels, five levels. So there's something about five, something's going on there.

607
01:01:59,160 --> 01:02:05,800
I guess five is good because five is not one and it's not, you never use a two and it's definitely

608
01:02:05,800 --> 01:02:11,480
not three and six is way too much. So it's like that four is just weird, but it's this perfect number

609
01:02:11,480 --> 01:02:17,080
of, uh, analysis to divide things. Cause I think once you get to six or seven, it's too confusing.

610
01:02:17,080 --> 01:02:20,280
You can't keep all that up, but I bet you can keep five things in your head at once.

611
01:02:21,000 --> 01:02:25,880
Yeah. Five things is, uh, I think it's enough for me. It was even hard to, to, to keep those five

612
01:02:25,880 --> 01:02:28,440
things in my memory. My memory is limited.

613
01:02:28,440 --> 01:02:32,440
Exactly. I'm going to be on the lookout for this. What other things come in fives?

614
01:02:32,440 --> 01:02:36,920
Like there must be other things that like are, uh, set up in five areas. Well, great. Well,

615
01:02:36,920 --> 01:02:41,320
if people wanted to, uh, follow up with you, I mean, not with you, but like follow your stuff

616
01:02:41,320 --> 01:02:44,200
or see other things you've been working on, like, what would you point them to?

617
01:02:45,240 --> 01:02:51,720
Um, first thing, Twitter. So I, I tweet under Jakob Limon and I have a blog. It's, uh,

618
01:02:51,720 --> 01:02:59,800
p-i-o-o-o dot github.io. So those two things, and I'll put a link to those in the show notes,

619
01:02:59,800 --> 01:03:05,960
which will be at, which will be at pivotal.io slash podcast at some point. Well, thanks for

620
01:03:05,960 --> 01:03:11,400
being on. I think this is, thanks for having me. Yeah. Yeah. And, uh, as always, thanks for

621
01:03:11,400 --> 01:03:17,080
listening. This has been Pivotal Conversations. Now you can get the, uh, the past episodes and

622
01:03:17,080 --> 01:03:22,280
browse what's going on directly. If you go to soundcloud.com slash Pivotal Conversations,

623
01:03:22,280 --> 01:03:27,720
like I mentioned about every Thursday, we post this at a pivotal.io slash podcast.

624
01:03:28,280 --> 01:03:33,560
And, uh, also as a reminder, we're going to be merging together the two pivotal podcasts,

625
01:03:33,560 --> 01:03:37,880
pivotal insights, which is always a great podcast. There's a lot of customer interviews and kind of

626
01:03:37,880 --> 01:03:43,800
going over, uh, usage of pivotal related things and stuff people are doing, uh, with pivotal. Uh,

627
01:03:43,800 --> 01:03:48,200
and that's going to be merged together with this podcast. So we're starting now to publish every

628
01:03:48,200 --> 01:03:54,280
other week between them. So, uh, if you're listening, uh, to the order, you probably heard a pivotal

629
01:03:54,280 --> 01:03:58,120
insights thing last week, and now you're here. And the next week you'll hear one.

630
01:03:58,120 --> 01:04:02,920
So you get the idea. Um, and I think eventually it'll all become Pivotal Conversations.

631
01:04:03,320 --> 01:04:07,000
So you'll have that going on. So don't get shocked and enjoy it. And with that,

632
01:04:07,000 --> 01:04:10,200
we'll see everyone next time. Bye bye. Bye.