1
00:00:01,080 --> 00:00:04,799
Speaker 1: How'd you like to listen to dot NetRocks with no ads? Easy?

2
00:00:05,360 --> 00:00:08,560
Become a patron For just five dollars a month, you

3
00:00:08,599 --> 00:00:11,320
get access to a private RSS feed where all the

4
00:00:11,359 --> 00:00:14,560
shows have no ads. Twenty dollars a month will get

5
00:00:14,599 --> 00:00:18,440
you that and a special dot NetRocks patron mug. Sign

6
00:00:18,519 --> 00:00:22,120
up now at Patreon dot dot NetRocks dot com.

7
00:00:22,160 --> 00:00:24,679
Speaker 2: Hey Carl and Richard here with your twenty twenty four

8
00:00:24,839 --> 00:00:26,000
NDC schedule.

9
00:00:26,320 --> 00:00:29,640
Speaker 1: We'll be at as many NDC conferences as possible this year,

10
00:00:29,960 --> 00:00:33,200
and you should consider attending no matter what. The Copenhagen

11
00:00:33,240 --> 00:00:37,640
Developers Festival happens August twenty sixth through the thirtieth. Tickets

12
00:00:37,679 --> 00:00:40,719
at Cphdevfest dot com.

13
00:00:40,880 --> 00:00:44,719
Speaker 2: Ndcporto is happening October fourteenth through the eighteenth. Tickets at

14
00:00:44,799 --> 00:00:46,600
Ndcporto dot com.

15
00:00:46,600 --> 00:01:02,079
Speaker 1: We'll see you there, we hope. Hey, guess what it's

16
00:01:02,119 --> 00:01:05,120
dot net rocks. I'm Carl Franklin and I'm Richard Campbell.

17
00:01:05,480 --> 00:01:08,359
We're here again. Yes, you can't get rid of us.

18
00:01:08,480 --> 00:01:10,760
It's still the summertime too, so we've been at home

19
00:01:10,959 --> 00:01:15,560
for a while. Yeah. I had a sad weekend. I

20
00:01:15,599 --> 00:01:18,280
went to a funeral of my cousin who was three

21
00:01:18,359 --> 00:01:22,159
years younger than me, and it was too soon for her.

22
00:01:22,280 --> 00:01:23,439
But cancer sucks.

23
00:01:23,719 --> 00:01:26,760
Speaker 2: Yeah, no, I know what you mean. Man, it's reality.

24
00:01:26,760 --> 00:01:28,840
We're living with her now older than friends of ours

25
00:01:28,840 --> 00:01:29,480
that we're losing.

26
00:01:30,480 --> 00:01:33,040
Speaker 1: However, I did get a chance to visit with the

27
00:01:33,079 --> 00:01:38,040
other Franklins in the family, and they're a stoic bunch. Man.

28
00:01:38,079 --> 00:01:41,519
There was nary a tear, even though they felt the

29
00:01:41,599 --> 00:01:46,079
loss deeply. It was very strange. Anyway, I won't go

30
00:01:46,120 --> 00:01:48,599
into that. How are you.

31
00:01:49,040 --> 00:01:51,680
Speaker 2: I'm good, you know, with the summer winding down, getting

32
00:01:51,680 --> 00:01:55,480
ready to go to Copenhagen Developers Festival in the near

33
00:01:55,560 --> 00:01:58,519
future here, and that'll be the first trip since June.

34
00:01:58,719 --> 00:02:01,000
So it's been a good couple of months on the

35
00:02:01,040 --> 00:02:02,599
coast and you know it's nice up here.

36
00:02:02,799 --> 00:02:04,079
Speaker 1: Yeah, that's right.

37
00:02:04,200 --> 00:02:06,920
Speaker 2: And I've been smoking a lot of salmon and ribs

38
00:02:06,959 --> 00:02:08,199
and you know that kind of thing.

39
00:02:08,280 --> 00:02:11,759
Speaker 1: Is that good for your lungs? I'm not smoke smoking salmon.

40
00:02:11,879 --> 00:02:15,759
Speaker 2: Yeah, but plus it's really hard to keep it lit.

41
00:02:16,000 --> 00:02:22,039
Speaker 1: Yeah. All right, Well let's jump into the way we

42
00:02:22,120 --> 00:02:24,319
start the show with better not a framework?

43
00:02:24,520 --> 00:02:33,759
Speaker 2: Awesome, man, what do you got? Well?

44
00:02:33,759 --> 00:02:35,719
Speaker 1: This started out of course, is a way that I

45
00:02:35,719 --> 00:02:40,280
could poke, uh, you know, a little dive into little

46
00:02:40,400 --> 00:02:42,680
parts of the framework, the dot net framework back when

47
00:02:42,719 --> 00:02:45,080
it was a Windows framework, and then it just sort

48
00:02:45,120 --> 00:02:52,400
of evolved to Carl says something something somebody once said

49
00:02:52,719 --> 00:02:56,199
this is Carl does a Google search five minutes before

50
00:02:56,240 --> 00:03:00,080
the show. But today we have something different and it

51
00:03:00,080 --> 00:03:06,280
involves you, mister Campbell. So it's about dev Intersection, So

52
00:03:06,360 --> 00:03:07,240
tell me what's going on.

53
00:03:07,400 --> 00:03:09,960
Speaker 2: So we've got a side by shote show, as we

54
00:03:10,120 --> 00:03:13,840
like to do in at dev Intersection. We're going side

55
00:03:13,840 --> 00:03:16,919
byside with a new show, or at least a new name,

56
00:03:17,039 --> 00:03:19,840
which is the Next Gen Ai Show. So this is

57
00:03:20,120 --> 00:03:23,719
at the MGMGEN in Las Vegas from the tenth to

58
00:03:23,759 --> 00:03:26,560
the twelfth of September, so coming up right away, right

59
00:03:26,639 --> 00:03:29,879
and we've got a special offer putting on we call

60
00:03:29,960 --> 00:03:33,479
the Bogo offer. You buy one get one free.

61
00:03:33,080 --> 00:03:35,520
Speaker 1: That's right. So if you haven't registered yet and you

62
00:03:35,520 --> 00:03:37,240
want to go and you want to get a free ticket,

63
00:03:37,280 --> 00:03:40,439
what you do is you use the code gen Ai

64
00:03:40,719 --> 00:03:44,919
bogo g E n AI b O g O discount

65
00:03:44,919 --> 00:03:48,439
code when you're registering at either next gen ai com

66
00:03:48,560 --> 00:03:53,960
for dev Intersection dot com and with a full price registration,

67
00:03:54,120 --> 00:03:57,840
you'll receive an email confirmation which will include a unique

68
00:03:57,879 --> 00:04:01,240
discount code for a free second registration to pass on

69
00:04:01,280 --> 00:04:04,199
to an additional attendee. Right, so there you go. It's

70
00:04:04,199 --> 00:04:05,560
buy one, get one free.

71
00:04:05,639 --> 00:04:07,639
Speaker 2: And by the way, you can registered to either show,

72
00:04:08,159 --> 00:04:10,759
it doesn't matter which, and you have access to everything.

73
00:04:10,879 --> 00:04:13,400
We just we tend to do, you know, the marketing

74
00:04:13,439 --> 00:04:16,839
towards the Microsoft community, Visual Studio C Shop on the

75
00:04:16,839 --> 00:04:20,199
internest the radiosexual side, and the marketing towards the AI

76
00:04:20,360 --> 00:04:24,120
community on the next gen AI side, but we want those,

77
00:04:24,160 --> 00:04:25,839
you know, we call it intersection for reason. It's a

78
00:04:25,839 --> 00:04:28,759
crossing over of different interest areas, and so that's why

79
00:04:28,800 --> 00:04:30,600
we have the two names and the two websites, but

80
00:04:30,639 --> 00:04:31,480
it's all the same show.

81
00:04:31,639 --> 00:04:34,920
Speaker 1: That's great. So that's what I got. Who's talking to

82
00:04:35,000 --> 00:04:35,800
us today, Richard?

83
00:04:35,959 --> 00:04:38,879
Speaker 2: Awesome dude. And speaking of AI stuff, I grabbed a

84
00:04:38,879 --> 00:04:41,319
comment of Show eighteen ninety four, which you did back

85
00:04:41,360 --> 00:04:44,000
in April of this year with Carl Getz. We were

86
00:04:44,040 --> 00:04:48,480
talking about programming with speech in AI, and this particular

87
00:04:48,480 --> 00:04:50,560
comment comes from SD Penner who said, I thought this

88
00:04:50,759 --> 00:04:52,680
was great. This opened my eyes to new ways of

89
00:04:52,720 --> 00:04:56,040
working with visual Studio, because that's the problem with visual Studio,

90
00:04:56,079 --> 00:04:58,000
like everything's in there, you just can't find it, right,

91
00:04:58,079 --> 00:05:02,240
Like there's so many tools. Oddly enough, or maybe suspiciously,

92
00:05:02,680 --> 00:05:06,240
this recent code rush video came across my feed where

93
00:05:06,240 --> 00:05:10,360
they talked about supporting voice commands that we're mentioned in

94
00:05:10,360 --> 00:05:14,000
a podcast on dot net rocks because we've already done this, right, Yeah,

95
00:05:14,120 --> 00:05:16,639
talk to Mark Miller will He was playing with the

96
00:05:16,680 --> 00:05:20,800
idea as well. So you're right, there's an exploration of

97
00:05:20,879 --> 00:05:22,560
tooling right now.

98
00:05:22,680 --> 00:05:22,920
Speaker 3: Yeah.

99
00:05:23,079 --> 00:05:28,920
Speaker 2: I think a general pressure against the user interface to

100
00:05:29,120 --> 00:05:32,639
just include sort of that chat mechanism and or voice

101
00:05:32,680 --> 00:05:36,279
mechanism with it in a way to describe your goals,

102
00:05:36,279 --> 00:05:39,279
describe your ideas, and use large language models to pull

103
00:05:39,399 --> 00:05:41,399
value from it to save you some time.

104
00:05:41,560 --> 00:05:44,959
Speaker 1: So, and it's really getting good, Like voice commands have

105
00:05:45,079 --> 00:05:46,040
always been around.

106
00:05:46,279 --> 00:05:49,240
Speaker 2: Yeah, it's just dragon naturally speaking in the eighties for

107
00:05:49,319 --> 00:05:50,000
god's sake.

108
00:05:49,879 --> 00:05:52,040
Speaker 1: That's right, where you trained your parrot to turn the

109
00:05:52,120 --> 00:05:52,839
lights on and off.

110
00:05:52,839 --> 00:05:54,319
Speaker 2: But don't do that.

111
00:05:54,439 --> 00:06:01,120
Speaker 1: I do not, But anyway, Yeah, so it's getting really

112
00:06:01,199 --> 00:06:06,240
good in just about every interface that I have. I

113
00:06:06,360 --> 00:06:09,160
use it to I use a speech to talk to

114
00:06:09,399 --> 00:06:12,160
chat GPT on my phone. Hm, I use speech in

115
00:06:12,160 --> 00:06:15,399
my car. We'll talk about that next show. Sure, I

116
00:06:15,560 --> 00:06:20,160
use I don't use speech at the PC though, but yeah,

117
00:06:20,279 --> 00:06:25,360
but yeah, I'm getting toward it because yeah, just mousing around, Yeah,

118
00:06:25,360 --> 00:06:26,199
it gets tiring.

119
00:06:26,319 --> 00:06:28,199
Speaker 2: I didn't even think about the fact that today, when

120
00:06:28,199 --> 00:06:30,720
I walk into my office to record a show, I

121
00:06:30,759 --> 00:06:34,439
do command Home Assistant via voice to switch to video mode,

122
00:06:35,360 --> 00:06:38,480
which switches the computer around, turns on the lights, like

123
00:06:38,560 --> 00:06:41,920
configures everything to get ready to record. That's really cool,

124
00:06:42,079 --> 00:06:44,920
normal workflow. And then when it's done, tell okay, go

125
00:06:45,000 --> 00:06:47,360
back to normal and it switches everything backed off again.

126
00:06:47,920 --> 00:06:50,079
So yeah, it's happening. So as do you? Thank you

127
00:06:50,120 --> 00:06:52,000
so much for your comment. Copy of music Cobey is

128
00:06:52,000 --> 00:06:53,160
on its way to you. And if you'd like a

129
00:06:53,160 --> 00:06:54,839
copy of music Gobe, I write a comment on the

130
00:06:54,839 --> 00:06:57,360
website at dot at Rocks dot com or on the facebooks.

131
00:06:57,399 --> 00:06:59,439
We publish every show there, and if you comment there

132
00:06:59,439 --> 00:07:01,439
in a really we'll send you copy of music go by.

133
00:07:01,560 --> 00:07:04,839
Speaker 1: Music to code by still very popular option for developers

134
00:07:04,879 --> 00:07:08,959
who want help getting into the zone. And yeah, we'll

135
00:07:09,000 --> 00:07:11,639
send you a free one if like what just happened

136
00:07:11,680 --> 00:07:15,759
right here, somebody's getting a free music yestaed by Yeah, okay,

137
00:07:16,000 --> 00:07:20,000
let me introduce our guest today. Anita Kavama is a

138
00:07:20,040 --> 00:07:23,079
hands on software architect with more than twenty five years

139
00:07:23,079 --> 00:07:27,319
of experience from building business solutions. In the late nineties,

140
00:07:27,360 --> 00:07:30,480
she advocated for the importance of UX before it was

141
00:07:30,519 --> 00:07:35,000
accepted as important by the software community. Today, Anita feels

142
00:07:35,000 --> 00:07:37,920
at home in the domain driven Design community, where she's

143
00:07:37,959 --> 00:07:42,160
been a frequent speaker the last years. Currently, she has

144
00:07:42,199 --> 00:07:45,639
a great time as a coding software architect at Equanor

145
00:07:46,240 --> 00:07:49,279
in a team delivering custom business solutions to the in

146
00:07:49,360 --> 00:07:53,879
house trading desk. Welcome Anita, Thank you, yes, thank you.

147
00:07:53,879 --> 00:07:56,360
You have Have you heard the show before?

148
00:07:56,639 --> 00:07:58,199
Speaker 3: Oh yeah, many many time.

149
00:07:58,399 --> 00:07:59,480
Speaker 2: Oh goodness, Oh great.

150
00:08:00,000 --> 00:08:01,160
Speaker 1: Should be a k quak for you.

151
00:08:02,360 --> 00:08:05,000
Speaker 2: And I originally twigged on the talk you were doing

152
00:08:05,000 --> 00:08:07,040
it in DC. I was all about event sourcing. But

153
00:08:07,120 --> 00:08:10,759
I Equinor is a big company and if DDD is

154
00:08:10,800 --> 00:08:12,160
a playing a role in there, I'd love to hear

155
00:08:12,199 --> 00:08:14,319
a bit of the story of what you what you're doing,

156
00:08:14,360 --> 00:08:17,279
about how our organization like that approaches software development.

157
00:08:17,519 --> 00:08:21,079
Speaker 3: Yeah, actually, when d d D and the book Eric

158
00:08:21,120 --> 00:08:26,079
Evans's book came out Eclinor engaged in this and invited

159
00:08:26,160 --> 00:08:30,600
him over here in Norway to visit us to tell

160
00:08:30,639 --> 00:08:34,200
more about what is d d D and also to

161
00:08:34,279 --> 00:08:37,639
engage with some of our teams. And of course that's

162
00:08:37,799 --> 00:08:42,000
a long long time ago. It was around I wasn't

163
00:08:42,320 --> 00:08:45,159
coding much on that at the times. I was just

164
00:08:45,320 --> 00:08:50,080
partly part of that as a consultant and equinor. But

165
00:08:50,200 --> 00:08:53,000
he came over and it was a lot of you know,

166
00:08:53,759 --> 00:08:58,840
groups and a community building inside Ecuinor for actually doing

167
00:08:58,919 --> 00:09:02,159
the main dream in design. And then I think we

168
00:09:02,279 --> 00:09:06,159
still are a bunch of people doing this and h

169
00:09:07,440 --> 00:09:10,720
really engaged in the community. But there is also of

170
00:09:10,799 --> 00:09:14,360
course teams that are not doing the main driven design.

171
00:09:14,480 --> 00:09:17,639
But for me, I call myself a d d D lower.

172
00:09:17,799 --> 00:09:20,240
I think I've seen the power for some of the

173
00:09:20,480 --> 00:09:24,559
tip of application we are doing where is highly complicated

174
00:09:24,639 --> 00:09:28,720
business application. I think the main driven design has a

175
00:09:28,759 --> 00:09:33,080
big role. And really the d d D community is

176
00:09:33,120 --> 00:09:36,720
so open and so warm and I have learned so

177
00:09:36,840 --> 00:09:40,720
much from that. But I think that we really from

178
00:09:40,759 --> 00:09:45,080
the start had to buying from some management, actually getting

179
00:09:45,879 --> 00:09:50,960
d Garrick evans Or to our to our campus and

180
00:09:51,360 --> 00:09:54,399
helping us out. I think was a great start, because

181
00:09:54,440 --> 00:09:57,240
yet then you don't you can use your energy in

182
00:09:57,440 --> 00:10:00,799
understanding and doing things that it is and easy. It's

183
00:10:00,840 --> 00:10:04,639
always related to building hard solutions too, so you have

184
00:10:04,720 --> 00:10:07,759
to focus. And if you use all your focus just

185
00:10:07,799 --> 00:10:11,639
to convince the management and other around you that this

186
00:10:11,840 --> 00:10:15,000
is something you to do, then you lose the focus

187
00:10:15,039 --> 00:10:18,440
of actually doing the good work interesting in building the

188
00:10:18,679 --> 00:10:22,559
IT solutions. So having that support from the start is

189
00:10:22,840 --> 00:10:24,039
really really critical.

190
00:10:24,120 --> 00:10:27,960
Speaker 1: I think, did you say Eric Evans has has joined

191
00:10:28,000 --> 00:10:29,879
you equan No.

192
00:10:29,679 --> 00:10:32,159
Speaker 3: No, but we kind of hire it him as a

193
00:10:32,159 --> 00:10:35,080
consultant for our guests for some weeks or something.

194
00:10:35,240 --> 00:10:37,480
Speaker 2: But that book is more than twenty years old now,

195
00:10:37,559 --> 00:10:40,080
like it's been around a while, and we interviewed him

196
00:10:40,080 --> 00:10:42,639
in two thousand and seven and found he's a very

197
00:10:42,759 --> 00:10:45,679
kind man, very very pleasant to talk to.

198
00:10:46,360 --> 00:10:50,120
Speaker 3: Absolutely. I was so lucky that I was part of

199
00:10:50,159 --> 00:10:55,159
the Explored DDDY conference in Denver this year and there

200
00:10:55,200 --> 00:11:00,440
we had this Diametics cake at a speaker's dinner where

201
00:11:01,000 --> 00:11:03,799
Eric Ebbans was there, and it was for the twenty

202
00:11:04,519 --> 00:11:07,080
years since the book came out. So it was a

203
00:11:07,120 --> 00:11:10,320
cake with a picture of the front side of the book,

204
00:11:11,039 --> 00:11:13,960
and we were kind of kidding that when he take

205
00:11:14,000 --> 00:11:19,120
a bit, it was dividing into bond the context each got.

206
00:11:18,960 --> 00:11:23,919
Speaker 1: It the cake driven or domain driven cake.

207
00:11:24,000 --> 00:11:24,240
Speaker 3: Yeah.

208
00:11:24,360 --> 00:11:27,919
Speaker 2: Nice, Yeah, that's great, very funny. Yeah, oh right, Well,

209
00:11:28,279 --> 00:11:30,279
I didn't mean to distract you much, but it's a

210
00:11:30,360 --> 00:11:33,200
you know, awesome story, and I appreciate your viewpoint on that.

211
00:11:33,279 --> 00:11:36,840
It certainly it realized like it's a career length kind

212
00:11:36,879 --> 00:11:37,840
of thing too.

213
00:11:38,240 --> 00:11:41,720
Speaker 3: Yeah, And for me it's not a distraction because events

214
00:11:41,799 --> 00:11:45,559
sourcing without the main driven the sign, I really will

215
00:11:45,600 --> 00:11:49,159
not know how to do that. I think events sourcing

216
00:11:49,200 --> 00:11:52,799
gives me the toolbox that is so helpful when doing

217
00:11:53,519 --> 00:11:56,120
no the other way of around. Of course, the main

218
00:11:56,200 --> 00:11:59,519
driven the sign gives me the toolbox with the concept

219
00:11:59,559 --> 00:12:04,279
of aggregates the context and all that of make doing

220
00:12:04,320 --> 00:12:07,679
events sourcing much much easier. And I think that also

221
00:12:07,759 --> 00:12:10,360
grew out of that community, so that was how I

222
00:12:10,399 --> 00:12:13,120
was introduced to it actually, So for me it was

223
00:12:13,159 --> 00:12:16,759
not distraction. It was completely inside the context where I

224
00:12:16,799 --> 00:12:18,039
think it belongs.

225
00:12:18,440 --> 00:12:22,519
Speaker 2: So why is the main drive design essential to event sourcing?

226
00:12:22,759 --> 00:12:26,759
Speaker 3: Well, for me, first of all, if this what events

227
00:12:26,840 --> 00:12:31,039
are we focusing on, and you can do events sourcing

228
00:12:31,360 --> 00:12:35,639
much more technical, but all I have been part of doing.

229
00:12:35,720 --> 00:12:38,759
Then we focus on domain events and with all that's

230
00:12:38,799 --> 00:12:42,360
a fact, it's something that has happened and really important,

231
00:12:42,519 --> 00:12:46,639
something that the business cares about. So actually having that

232
00:12:48,039 --> 00:12:52,159
and also when you do events sourcing, you need to

233
00:12:52,919 --> 00:12:56,639
those events need to belong to something. And that's something

234
00:12:56,879 --> 00:13:00,399
is the concept of aggregates that I know from domain

235
00:13:00,519 --> 00:13:03,679
driven design. And if I haven't kind of understood that

236
00:13:03,799 --> 00:13:06,799
concept from before, I think it would be harder to understand.

237
00:13:07,279 --> 00:13:09,320
So where are these events belonging to?

238
00:13:10,080 --> 00:13:10,399
Speaker 2: Right?

239
00:13:10,559 --> 00:13:12,759
Speaker 3: So they need to have a place to live. So

240
00:13:13,080 --> 00:13:17,080
that's I guess the two main things. And of course

241
00:13:17,120 --> 00:13:22,879
events storming. That all back to Brandolini introduced also really

242
00:13:22,919 --> 00:13:26,159
a member of the dd D community where you is

243
00:13:26,200 --> 00:13:30,799
a brainstorming technique where you identify or all these domain

244
00:13:30,840 --> 00:13:34,840
events also fits perfect into this picture and helps me

245
00:13:34,960 --> 00:13:38,200
out on my team. We are using that heavily.

246
00:13:38,519 --> 00:13:42,639
Speaker 1: When I think of event sourcing, I think of you know,

247
00:13:42,799 --> 00:13:45,919
like let's say you have a financial application and people

248
00:13:45,960 --> 00:13:48,519
are in a spreadsheet and they make a change. Rather

249
00:13:48,559 --> 00:13:52,440
than changing a value in a table, you add a

250
00:13:52,559 --> 00:13:55,480
record to a table that the value was changed from

251
00:13:55,559 --> 00:13:58,360
this to that with a time stamp, and who did it.

252
00:14:00,080 --> 00:14:03,080
I never really thought of it when you were describing

253
00:14:03,559 --> 00:14:05,840
what you're using for. It almost sounds more like a

254
00:14:05,960 --> 00:14:06,879
logging feature.

255
00:14:07,159 --> 00:14:10,840
Speaker 3: Well, in that case, when you change that value, you

256
00:14:11,000 --> 00:14:14,320
probably have the business have something in their mind. What

257
00:14:14,519 --> 00:14:19,360
are they actually doing transferred to in business terms. So

258
00:14:19,440 --> 00:14:22,440
it's for instance, I've been working with some trading strategies

259
00:14:22,519 --> 00:14:24,679
and you can say we have a table with a

260
00:14:24,799 --> 00:14:29,039
trading strategy, but when the user start that strategy, we

261
00:14:29,120 --> 00:14:31,840
don't look upon that as changing the one value from

262
00:14:31,960 --> 00:14:35,840
stop to start, but it's a they do. They have

263
00:14:35,919 --> 00:14:39,039
an intention that is starting the strategy, and we get

264
00:14:39,039 --> 00:14:42,679
a domain event that says that the strategy is started.

265
00:14:43,080 --> 00:14:47,600
So it's more to actually explain in business terms those

266
00:14:47,840 --> 00:14:52,399
state changes and look upon. It's not the importance here

267
00:14:52,600 --> 00:14:55,080
just to keep track of the state changes, but really

268
00:14:55,159 --> 00:15:00,279
understand what is happening seen from a behavior perspective in

269
00:15:00,320 --> 00:15:05,240
the business. So it is I feel I've been working

270
00:15:05,360 --> 00:15:07,360
with some sort of design for a long time, as

271
00:15:07,360 --> 00:15:11,639
you said in the introduction, and also before when we

272
00:15:11,720 --> 00:15:15,399
did not do event sourcing, we put all these noise

273
00:15:15,480 --> 00:15:18,840
in our tables. Of course, we've put the versions because

274
00:15:18,879 --> 00:15:21,320
we need an audit. But then we added flags. We

275
00:15:21,320 --> 00:15:24,559
added flags that say, oh, this row is updated by

276
00:15:24,600 --> 00:15:27,159
a user, and do you know this user idea that

277
00:15:27,919 --> 00:15:31,519
I've been something that we do and I think everything

278
00:15:31,559 --> 00:15:34,960
we did because we wanted to know what has actually happened.

279
00:15:35,039 --> 00:15:38,480
We wanted that behavior we view. But all we had

280
00:15:38,639 --> 00:15:43,240
was this static table and actually should keep the state,

281
00:15:43,679 --> 00:15:47,960
but we enhanced it and put a lot of stuff

282
00:15:48,039 --> 00:15:51,720
into it in order to be able to detect what

283
00:15:51,879 --> 00:15:55,039
has actually happened. And now doing event sourcing, I can

284
00:15:55,159 --> 00:15:58,480
just save what did actually happen and I really find

285
00:15:58,519 --> 00:15:59,519
that so useful.

286
00:16:01,360 --> 00:16:03,720
Speaker 2: The domain event is sort of the starting point of

287
00:16:03,759 --> 00:16:07,440
an event storm. What is the domain event?

288
00:16:07,799 --> 00:16:10,799
Speaker 3: It is something that happened in the past, And that's

289
00:16:10,879 --> 00:16:14,840
really diffferent from the command because the command can fail

290
00:16:15,320 --> 00:16:19,159
and the command could trigger a validation error and so on.

291
00:16:19,879 --> 00:16:23,919
But something that has happened. Taking the same example, strategy

292
00:16:23,960 --> 00:16:28,120
is started is completely different from the command starting the strategy.

293
00:16:28,159 --> 00:16:29,919
What if the user is not allowed to do it?

294
00:16:30,000 --> 00:16:34,240
So this has already happened, so it's a fact, but

295
00:16:34,320 --> 00:16:37,080
it should also be something that the business cares about.

296
00:16:37,360 --> 00:16:40,840
And that's one I use as a guidance for thinking

297
00:16:40,879 --> 00:16:45,159
about which event should we take care of and save

298
00:16:45,600 --> 00:16:49,759
which how do we bundle stuff? It shouldn't be meaningful

299
00:16:49,879 --> 00:16:53,799
or be able to discuss with the user. And if

300
00:16:53,840 --> 00:16:56,480
you do this events storming, you try to put those

301
00:16:56,519 --> 00:16:59,960
domain events up in a myro board or a white

302
00:17:00,039 --> 00:17:00,960
board or whatever.

303
00:17:01,399 --> 00:17:04,519
Speaker 2: As I understand, it's like it's a whiteboard, sticky note

304
00:17:05,400 --> 00:17:06,240
process approach.

305
00:17:06,440 --> 00:17:08,599
Speaker 3: Yeah, it is, absolutely So.

306
00:17:08,519 --> 00:17:11,119
Speaker 2: What's the granularity of domain event? Is it like adding

307
00:17:11,160 --> 00:17:14,640
something to a shopping cart or initiating a sale? Like

308
00:17:14,839 --> 00:17:15,920
what's they.

309
00:17:15,640 --> 00:17:19,119
Speaker 3: Add item to a shopping card is a typical example

310
00:17:19,160 --> 00:17:22,559
of a domain event and also remove that item, and

311
00:17:22,640 --> 00:17:26,920
of course then you're into one other typical example of

312
00:17:27,119 --> 00:17:31,559
how events sourcing different from other way to building solutions,

313
00:17:31,839 --> 00:17:34,759
because if you only have the shopping cart and someone

314
00:17:34,799 --> 00:17:39,880
asks you how often they do the customer remove just

315
00:17:39,960 --> 00:17:42,519
this kind of shoe from my shopping card? You don't

316
00:17:42,559 --> 00:17:46,039
have that information. So one of the slogan for events

317
00:17:46,119 --> 00:17:49,599
sourcing is that you will never lose any data because

318
00:17:49,640 --> 00:17:52,279
you take care of those so you can answer them.

319
00:17:52,559 --> 00:17:55,799
I used to say, I'm architecting for tomorrow's question. You

320
00:17:55,920 --> 00:17:59,000
never know in a data d even organization, what do

321
00:17:59,079 --> 00:18:01,839
they ask tomorrow? I should ask me something new? Actually,

322
00:18:01,880 --> 00:18:03,839
if they if you are truly data.

323
00:18:03,680 --> 00:18:09,680
Speaker 1: Driven, so I imagine that web browsing behavior and how

324
00:18:09,720 --> 00:18:12,880
they use the application in a web for example, which

325
00:18:12,920 --> 00:18:16,640
can all be tracked, right, I imagine that is going to

326
00:18:16,640 --> 00:18:20,640
be very interested to the Mark Zuckerbergs of the world. Interesting.

327
00:18:21,000 --> 00:18:26,920
Speaker 3: Yeah, but for us, it's only those events. I mean,

328
00:18:27,440 --> 00:18:32,640
how you are navigating into your browser. We are not tracking.

329
00:18:32,799 --> 00:18:36,559
We are only tracking. Yeah you could, we could. Yeah,

330
00:18:36,599 --> 00:18:40,440
And of course that depends on what information What is

331
00:18:40,480 --> 00:18:41,640
your purpose there?

332
00:18:42,880 --> 00:18:43,119
Speaker 1: Yeah?

333
00:18:44,200 --> 00:18:46,200
Speaker 2: Okay, what's important to the organization?

334
00:18:46,519 --> 00:18:46,799
Speaker 1: Right?

335
00:18:46,920 --> 00:18:49,640
Speaker 3: Yes, it is, and also to if you have a

336
00:18:49,720 --> 00:18:53,319
more task based user interface in opposite to a more

337
00:18:53,400 --> 00:18:56,640
crowd base where you actually are thinking about what task

338
00:18:56,759 --> 00:18:58,920
or the user is doing, and you might have button

339
00:18:59,079 --> 00:19:02,960
that face start strategy instead of the just changing a

340
00:19:03,039 --> 00:19:07,960
column in a table from stop to start, then it's

341
00:19:08,039 --> 00:19:10,680
much easier. It is more aligned with doing AM and

342
00:19:10,799 --> 00:19:14,880
sourcing because you're already there knowing the intention behind the

343
00:19:15,000 --> 00:19:19,200
user because it's kind of expressing is through the functionality

344
00:19:19,240 --> 00:19:22,000
the task is doing in the interface, right, If that

345
00:19:22,079 --> 00:19:22,599
makes sense?

346
00:19:22,759 --> 00:19:25,519
Speaker 2: Well, and it's something I've always noticed with domain view

347
00:19:25,559 --> 00:19:28,720
is that it's far more agnostic. Like crud speaks to

348
00:19:28,920 --> 00:19:30,839
I'm speaking to an rdbm ass. I mean, I know

349
00:19:30,880 --> 00:19:33,680
I can make it with other things. This idea of

350
00:19:34,200 --> 00:19:36,559
the customer wants to add something to the shopping cart.

351
00:19:36,920 --> 00:19:39,960
Everything plumbing related to that is secondary the point, right,

352
00:19:40,039 --> 00:19:41,759
It's like, this is what the customer wants to do.

353
00:19:41,799 --> 00:19:43,519
There's a ton of ways to go about it. Now

354
00:19:43,559 --> 00:19:46,000
we can work through those options. But more importantly, there's

355
00:19:46,720 --> 00:19:49,920
a series of events that occur from that desire.

356
00:19:50,279 --> 00:19:52,680
Speaker 3: It is, and as long as you have that event,

357
00:19:52,920 --> 00:19:57,319
you can at unepoint in time later on play through

358
00:19:57,359 --> 00:20:01,279
those events and construct the information that you need. So

359
00:20:01,359 --> 00:20:03,920
you don't need to pick this is my state of

360
00:20:04,000 --> 00:20:06,680
my application in the start, and I think that is

361
00:20:06,720 --> 00:20:09,559
often very hard to do. To discuss what are a

362
00:20:09,640 --> 00:20:13,519
user doing in this application is such much easier to

363
00:20:13,640 --> 00:20:16,880
agree upon. But actually what information are they going to see?

364
00:20:16,960 --> 00:20:20,400
And how should we save those That is much that's

365
00:20:20,559 --> 00:20:23,480
question that need to when you show the users you

366
00:20:23,519 --> 00:20:26,119
have given them something to say what they actually want

367
00:20:26,160 --> 00:20:30,480
to see. So having this separated like a command, your

368
00:20:30,759 --> 00:20:34,759
responsibility segregation. So you have the events and then the

369
00:20:35,200 --> 00:20:38,119
things that really are changing all the time. What is

370
00:20:38,160 --> 00:20:42,000
the valuable information to show to the users? It's much

371
00:20:42,200 --> 00:20:43,839
easier to change, right.

372
00:20:44,440 --> 00:20:49,519
Speaker 1: Would you serialize the state, the relevant state and put

373
00:20:49,559 --> 00:20:54,519
that in an event source record or would you prefer

374
00:20:54,640 --> 00:20:58,599
to calculate the state based on a history or a

375
00:20:58,759 --> 00:20:59,720
range of records.

376
00:21:00,079 --> 00:21:04,279
Speaker 3: Yeah, I prefer to just make the state based on

377
00:21:04,319 --> 00:21:07,440
the history of the So it's two side here on

378
00:21:07,480 --> 00:21:10,759
the right side where you need to be. You need

379
00:21:10,799 --> 00:21:13,759
to have the exact state and we don't take any

380
00:21:13,839 --> 00:21:18,519
eventual consistency there. So what we do we actually source

381
00:21:18,599 --> 00:21:21,960
the state by looping through the events. Hence and the

382
00:21:22,119 --> 00:21:26,720
term events sourcing. So your events is the truth. And

383
00:21:26,799 --> 00:21:29,400
of course if you stream get too long, there are

384
00:21:29,680 --> 00:21:32,559
techniques where you can do snapshotting and so, but you

385
00:21:32,640 --> 00:21:35,319
do that when you have to. But for the start,

386
00:21:35,720 --> 00:21:39,839
you just go through source the events. You read each

387
00:21:39,960 --> 00:21:43,920
one event in sequence for that aggregate. And if you

388
00:21:43,960 --> 00:21:46,839
don't know the aggregate term for DDDY, it's more like

389
00:21:46,920 --> 00:21:51,160
the it's like a business entity that has both behavior

390
00:21:51,720 --> 00:21:55,279
and data. So you get the aggregate state by looking

391
00:21:55,279 --> 00:21:57,839
through the event and you just pick up the things

392
00:21:57,880 --> 00:22:01,039
that you need in order to be able to do

393
00:22:01,160 --> 00:22:02,960
the business rules on the right side.

394
00:22:03,200 --> 00:22:06,720
Speaker 1: Yeah, that's a big difference from somebody who's just doing logging.

395
00:22:06,839 --> 00:22:09,519
Even with something like Serra log where you're taking the

396
00:22:09,559 --> 00:22:11,799
state of an object or a bunch of objects and

397
00:22:11,799 --> 00:22:18,319
putting them in a in a record, the state is sourced,

398
00:22:18,680 --> 00:22:22,960
as you said, events and the clue is right there

399
00:22:23,000 --> 00:22:23,880
in the name. Yeah.

400
00:22:23,960 --> 00:22:27,000
Speaker 3: And on the red side, when you want to display information,

401
00:22:27,440 --> 00:22:30,720
you do have this eventual consistency because you react to

402
00:22:30,799 --> 00:22:35,119
those events, and you can pick events from many different

403
00:22:35,160 --> 00:22:38,519
streams and you build up the information you need to see.

404
00:22:38,599 --> 00:22:43,079
And there we the typical start out at least with

405
00:22:43,279 --> 00:22:45,880
just having that state in memory, because every time we

406
00:22:45,960 --> 00:22:48,799
restart our application, we can just start from the first

407
00:22:48,839 --> 00:22:50,759
event and we can spin it up and makes it

408
00:22:50,839 --> 00:22:54,759
also easy to change early in the process. But when

409
00:22:54,799 --> 00:22:59,119
a database grows and become too big, with just can

410
00:22:59,559 --> 00:23:02,160
then you can build a date and you can save

411
00:23:02,240 --> 00:23:06,720
it in whatever database you want to that is best

412
00:23:06,759 --> 00:23:09,319
fit for that purpose. So it's not the event store

413
00:23:09,519 --> 00:23:12,039
that keeps the remodels is that it could be a

414
00:23:12,079 --> 00:23:14,960
separate one and then if you want to change it,

415
00:23:15,000 --> 00:23:18,519
you can at any point just scratch it and build

416
00:23:18,519 --> 00:23:21,400
it off from scratch it. Just if you actually change

417
00:23:21,440 --> 00:23:23,960
your read model schema, you don't need to do a

418
00:23:24,039 --> 00:23:27,079
database migration. And that's of course something that is.

419
00:23:27,079 --> 00:23:30,559
Speaker 2: Nice too, But it makes sense that you can have

420
00:23:30,640 --> 00:23:33,440
reconciliation points so you can say, all right, we're starting

421
00:23:33,440 --> 00:23:37,920
at a balance here now then stream forward, Yeah, depending

422
00:23:37,920 --> 00:23:41,119
on scope, and I can there plenty of streams you

423
00:23:41,119 --> 00:23:43,559
could last a long time, but there's also plenty where

424
00:23:43,599 --> 00:23:46,960
it's like, listen, you're also gonna I mean, I use

425
00:23:47,000 --> 00:23:49,640
the term reconciliation for a reason. From a financial perspectors,

426
00:23:49,640 --> 00:23:51,799
there's a point where you declare, this month is completed,

427
00:23:51,880 --> 00:23:55,839
here is the truth, and from then on you don't

428
00:23:56,079 --> 00:23:58,680
want any possibility that would change. Not that it should,

429
00:23:59,240 --> 00:24:02,559
but there's no reason to go re reconcile at that point.

430
00:24:02,799 --> 00:24:06,480
Speaker 3: Yeah. Nice that you take that example, because usually if

431
00:24:06,519 --> 00:24:10,039
you try to explain event sourcing to someone from the business,

432
00:24:10,119 --> 00:24:13,960
you do the accounting story, because accounting has been done

433
00:24:14,160 --> 00:24:16,359
doing event sourcing for one hundreds of years.

434
00:24:16,799 --> 00:24:17,440
Speaker 2: That's a legend.

435
00:24:17,920 --> 00:24:22,599
Speaker 3: Just to release something and update, they really do it

436
00:24:22,720 --> 00:24:26,039
the right time way like you do event sourcing, and

437
00:24:26,079 --> 00:24:28,680
if there is for it, people you say, okay, that's

438
00:24:28,680 --> 00:24:32,680
what guitar is doing because they also take you were

439
00:24:32,759 --> 00:24:36,960
kicked in a new pull request, and you don't just

440
00:24:37,119 --> 00:24:40,039
update the state, do how the changes lead to that state?

441
00:24:40,440 --> 00:24:44,720
Speaker 2: Yeah, no, you always have a journal. From a dba's perspective,

442
00:24:44,759 --> 00:24:48,519
you only insert, you never update, right, and that way

443
00:24:48,559 --> 00:24:51,720
you always have the dialogue of the truth of how

444
00:24:51,720 --> 00:24:56,079
things happened in sequence, even though eventually you want an

445
00:24:56,119 --> 00:25:00,119
aggregate of that because it gets too expensive to constantly recompute.

446
00:25:00,279 --> 00:25:02,599
Speaker 3: But there is also a goal the way you're on

447
00:25:02,680 --> 00:25:05,440
the right side again, not on the read side, where

448
00:25:05,440 --> 00:25:09,519
you show the information, but you try to design your

449
00:25:09,519 --> 00:25:14,680
aggregate so they are not that not living forever. So

450
00:25:14,759 --> 00:25:18,480
that's the same ass accounting is doing. Again. So for instance,

451
00:25:18,519 --> 00:25:20,799
might be we are aggregates that only have the event

452
00:25:20,920 --> 00:25:23,799
for a stream that belongs to a day for us

453
00:25:23,880 --> 00:25:29,519
working with traders, and we do that a lot, so

454
00:25:30,000 --> 00:25:33,279
you have techniques for not making those streams so big.

455
00:25:33,400 --> 00:25:37,119
So when the application has run for a while, the

456
00:25:37,279 --> 00:25:39,759
goal kind of and this is hard. It's not always

457
00:25:39,839 --> 00:25:42,079
we managed to do it, but we try to make

458
00:25:42,119 --> 00:25:46,240
those streams so they reset themselves, just as accounting is doing.

459
00:25:46,440 --> 00:25:47,000
Every year.

460
00:25:47,319 --> 00:25:51,519
Speaker 2: I've seen a stream system for testing materials and the

461
00:25:51,599 --> 00:25:54,480
data streams are very intensive, but the test runs are

462
00:25:54,880 --> 00:25:58,039
minutes long, so there's clearly a beginning, a run, and

463
00:25:58,079 --> 00:26:01,440
an end and then you can look at them from

464
00:26:01,480 --> 00:26:04,839
an aggrid perspective. But in that time, they're taking measurements

465
00:26:04,920 --> 00:26:07,920
multiple times per second. Like it can be a ton

466
00:26:07,960 --> 00:26:10,000
of data, but at least it has a clear picture.

467
00:26:10,000 --> 00:26:12,400
And I think when you think about domain in general,

468
00:26:12,480 --> 00:26:14,319
for any kind of business case, and again I'm falling

469
00:26:14,319 --> 00:26:16,759
back on e commerce, I did that the most. You know,

470
00:26:16,799 --> 00:26:18,880
the month end is the month end, and we do

471
00:26:19,000 --> 00:26:21,079
maintain those aggriates with only twelve of them of a

472
00:26:21,160 --> 00:26:26,000
year because they're historically relevant. But they once made, never changed.

473
00:26:26,240 --> 00:26:29,880
Speaker 3: Yeah, yeah, and that's what we want with our events too.

474
00:26:29,920 --> 00:26:32,480
We don't want them to be immutable. But of course,

475
00:26:32,839 --> 00:26:35,720
since they're a domain event, they also have domain concepts

476
00:26:35,720 --> 00:26:38,880
inside them, and that's a choice, but that's a choice

477
00:26:38,880 --> 00:26:43,079
we have taken. So that's opinionated. But that means that

478
00:26:43,200 --> 00:26:46,440
when we get deeper inside and understand the business concept better,

479
00:26:46,680 --> 00:26:50,440
we might want to change them. So you are able

480
00:26:50,480 --> 00:26:54,759
to do migration of those events. Just as we always

481
00:26:54,759 --> 00:26:57,440
sat down, we'd always stayed in the database when we

482
00:26:57,559 --> 00:27:01,599
need to do any changes, then you are not changing

483
00:27:01,640 --> 00:27:05,160
the events you have. You read them up and you

484
00:27:05,319 --> 00:27:07,960
change them and write them down to a new events store,

485
00:27:08,200 --> 00:27:09,720
so you just start with a new cover.

486
00:27:09,880 --> 00:27:12,480
Speaker 2: Yeah, this sounds like even just the change of the

487
00:27:12,519 --> 00:27:14,839
scheme in a database, and they're sort of a breakpoint,

488
00:27:15,000 --> 00:27:17,359
you know, going from B one to V two, and

489
00:27:17,440 --> 00:27:20,400
it is not easy to analyze across the breakpoint.

490
00:27:20,839 --> 00:27:25,400
Speaker 3: No. So so even though we have these real models

491
00:27:25,559 --> 00:27:28,599
that we don't need to do migration. Now, that is

492
00:27:28,640 --> 00:27:31,079
really good. The hard part for us then is to

493
00:27:31,160 --> 00:27:33,920
keep those events because there you have you can have

494
00:27:34,079 --> 00:27:36,480
versens or you can migrate them. You have the same

495
00:27:37,279 --> 00:27:39,640
challenges as you have when you have the state in

496
00:27:39,640 --> 00:27:41,960
a database and you can't scratch that. One.

497
00:27:42,400 --> 00:27:45,400
Speaker 2: Sure makes a lot of sense, and I think this

498
00:27:45,480 --> 00:27:47,319
is a good moment for us to take a brief

499
00:27:47,359 --> 00:27:49,240
break for these very important messages.

500
00:27:50,319 --> 00:27:54,319
Speaker 1: Attention dot net developers looking for the ultimate SDK to

501
00:27:54,400 --> 00:28:01,359
handle electronic document processing. Meet TX text Control. Txtext controls

502
00:28:01,400 --> 00:28:06,759
your go to solution for seamless PDF generation, secure electronics signatures,

503
00:28:07,039 --> 00:28:11,400
and efficient digital forms processing all within your dot net applications.

504
00:28:11,759 --> 00:28:17,240
Empower your products with robust document management capabilities, boost productivity

505
00:28:17,640 --> 00:28:21,559
and deliver top notch solutions to your clients, trusted by

506
00:28:21,599 --> 00:28:25,920
developers worldwide, including me and Richard. Txtext Control is the

507
00:28:26,079 --> 00:28:30,640
SDK that makes a difference. Check out demos dot textcontrol

508
00:28:30,720 --> 00:28:34,400
dot com for live online demos and see it in action.

509
00:28:37,759 --> 00:28:40,880
Speaker 2: And we're back. I'm Richard Campbell. That's Carl Franklin. You're

510
00:28:40,920 --> 00:28:43,279
listening to dot net Rocks. Hey, and we're talking to

511
00:28:43,319 --> 00:28:46,240
our friend Anita a bit about event sourcing and the

512
00:28:46,319 --> 00:28:50,519
role of demander of design in that. Where does COSMOSDB

513
00:28:50,680 --> 00:28:51,240
come into this.

514
00:28:52,039 --> 00:28:56,000
Speaker 3: Well, we need a place to store over events, but

515
00:28:56,160 --> 00:28:59,720
we also need a lot of part of the solution

516
00:28:59,839 --> 00:29:02,640
to react to those events, if that is to build

517
00:29:02,960 --> 00:29:06,160
update your state, or if that is just to do

518
00:29:06,319 --> 00:29:10,680
our reactions. For instance, we often get events, we call

519
00:29:10,720 --> 00:29:15,079
them the events. Sourcing events is inside events that's part

520
00:29:15,119 --> 00:29:18,720
of your application, but you also get event from the outside.

521
00:29:18,759 --> 00:29:22,200
For instance, for the traders, the order a trade could

522
00:29:22,240 --> 00:29:25,279
be executed and we listen to that and the solution

523
00:29:25,480 --> 00:29:28,920
reacts to it. So we need something that is pushing

524
00:29:28,960 --> 00:29:33,079
out those changes, and we need something that is how

525
00:29:33,240 --> 00:29:37,240
high scales but also is easy to use and in

526
00:29:37,319 --> 00:29:42,279
Microsoft documentation on Christmas TB has something called a change

527
00:29:42,319 --> 00:29:46,279
feed and that is a mechanism for pushing out those changes.

528
00:29:47,279 --> 00:29:51,680
And in Microsoft documentation for this change feed, they have

529
00:29:51,960 --> 00:29:56,079
events sourcing one of the scenarios. So we were like, okay,

530
00:29:56,680 --> 00:30:01,240
we try. We were already committed to working assure, so

531
00:30:01,359 --> 00:30:05,480
it was already in that area. So then Christmas dB

532
00:30:05,799 --> 00:30:09,119
seems like the best option for us to start, and

533
00:30:10,119 --> 00:30:13,880
we really the power of this change Feit is really

534
00:30:13,920 --> 00:30:17,839
good because you can just say I want to listen

535
00:30:18,119 --> 00:30:21,160
to those events a processes listening, or you can have

536
00:30:21,319 --> 00:30:25,079
multiple processes that list to those events, and then the

537
00:30:25,160 --> 00:30:28,599
Christmas DV change feed make sure that one stream will

538
00:30:28,960 --> 00:30:31,400
events from one stream will only be sent to one

539
00:30:31,440 --> 00:30:34,440
of those processes that we also need because we need

540
00:30:35,079 --> 00:30:38,319
the sequence of events are important, but the sequence of

541
00:30:38,519 --> 00:30:45,519
events across different aggregates isn't necessarily important. So you get

542
00:30:45,559 --> 00:30:49,519
this flexibility. And as a software architect, I really like

543
00:30:49,640 --> 00:30:54,559
that because then I can't start small because we know

544
00:30:54,680 --> 00:30:57,200
that we can scale out. We know that Christmas dB

545
00:30:57,319 --> 00:30:58,640
can help us with those things.

546
00:30:58,680 --> 00:31:04,200
Speaker 2: Right right is geolocated, synchronized, and distributed. But you can

547
00:31:04,240 --> 00:31:06,960
start with one node. This is an interesting angle on

548
00:31:07,000 --> 00:31:09,519
COSMOSDBI wasn't particularly aware of that it does have the

549
00:31:09,599 --> 00:31:13,200
speed mechanism that serves the streaming of events for sourcing.

550
00:31:13,200 --> 00:31:16,279
Speaker 3: Really well, it does, and that is the reason why

551
00:31:16,319 --> 00:31:17,920
we picked just that one.

552
00:31:18,599 --> 00:31:21,240
Speaker 1: Well, before you started with dd D, did you do

553
00:31:21,759 --> 00:31:25,480
non DDD development and how many years of that did

554
00:31:25,480 --> 00:31:25,720
you do?

555
00:31:27,079 --> 00:31:31,240
Speaker 3: Oh? So when did I start with DDDY? As I said,

556
00:31:31,279 --> 00:31:34,559
it was a period where I was more working with

557
00:31:34,880 --> 00:31:38,160
user experience and as a business analyst, but I was

558
00:31:38,279 --> 00:31:44,799
part of building solutions that didn't do DDITY in the start.

559
00:31:45,000 --> 00:31:49,920
So I think when we started out with this, the

560
00:31:50,039 --> 00:31:53,200
first one I was part of, I guess that was

561
00:31:53,359 --> 00:31:58,920
two thousand and five, six maybe, And that was a

562
00:31:59,000 --> 00:32:06,079
completely different vlication, non event sourcing, of course, and yeah,

563
00:32:06,119 --> 00:32:10,920
a different It was related to partly invoicing and accounting.

564
00:32:11,000 --> 00:32:13,960
Speaker 1: Actually, oh okay, so this is great. So you have

565
00:32:14,079 --> 00:32:19,359
experience doing invoicing and accounting without the benefits of events

566
00:32:19,400 --> 00:32:23,519
sourcing and DDD. And then afterwards, so what was that

567
00:32:23,559 --> 00:32:27,079
process like like when did the light bulb come on?

568
00:32:27,440 --> 00:32:30,319
And did you at first think oh, well, this seems

569
00:32:30,359 --> 00:32:32,559
like a lot of ceremony to get started, but then

570
00:32:32,799 --> 00:32:36,119
it got easier like, what was your experience like making

571
00:32:36,160 --> 00:32:36,759
that transition.

572
00:32:37,000 --> 00:32:39,880
Speaker 3: Yeah. First, if you take the transition from kind of

573
00:32:40,039 --> 00:32:43,480
non domain driven design solution to domain driven the sign

574
00:32:43,559 --> 00:32:48,799
solution I was rewrite with it a huge monolithic application.

575
00:32:49,000 --> 00:32:52,400
It's actually very still running with the first line of

576
00:32:52,480 --> 00:32:55,200
code written in nineteen ninety four, so there's a really

577
00:32:55,519 --> 00:32:59,039
old one. Having a great value for the business still

578
00:32:59,119 --> 00:33:02,079
would be to take them some technical risk. We needed

579
00:33:02,119 --> 00:33:05,920
to migrate quite a huge part of that application. And

580
00:33:05,960 --> 00:33:11,200
I think for me, I read the domain driven domain

581
00:33:11,359 --> 00:33:13,759
riven the sign book when it came out and having

582
00:33:13,799 --> 00:33:17,440
this UX had on. I think it's kind of the

583
00:33:17,519 --> 00:33:19,839
same because that's what you want to do as a

584
00:33:20,079 --> 00:33:23,000
user experienced person too. You want to understand the business

585
00:33:23,400 --> 00:33:25,759
and you want to try to use those concepts, and

586
00:33:25,799 --> 00:33:28,319
that what we tried to do. So I said that

587
00:33:28,480 --> 00:33:31,960
DDD is X for the developers. You tried to do

588
00:33:32,119 --> 00:33:37,279
the business concept inside your solution. And for me, the

589
00:33:37,359 --> 00:33:42,200
big big change was that you could write this automatically

590
00:33:42,400 --> 00:33:46,119
tests around about the context. All of a sudden, we

591
00:33:46,160 --> 00:33:49,839
could put them into pieces that was possible to handle

592
00:33:50,000 --> 00:33:53,599
and possible we use behavior driven development to write those

593
00:33:53,640 --> 00:33:58,720
tests like spec flow test or feature tests. I guess

594
00:33:58,799 --> 00:34:01,000
you have a lot of different anames of those tests,

595
00:34:01,039 --> 00:34:05,160
but it's more high level than unit tests. So for

596
00:34:05,240 --> 00:34:10,079
me that was Yeah. I had a great, great person

597
00:34:10,119 --> 00:34:13,079
in my team and lip and she knew did it

598
00:34:13,440 --> 00:34:16,519
out and in and was a good teacher. So for me,

599
00:34:16,559 --> 00:34:19,800
it wasn't a lot of overhead. It just makes sense

600
00:34:20,000 --> 00:34:23,880
to think that way and to build the solutions that way.

601
00:34:24,559 --> 00:34:29,039
Speaker 1: Right, So rather than building them by business feature, you

602
00:34:29,079 --> 00:34:32,960
built them by technical things that they did, like I

603
00:34:32,960 --> 00:34:34,440
would imagine no.

604
00:34:34,280 --> 00:34:39,159
Speaker 3: More opposite, instead of making them model of your software

605
00:34:39,559 --> 00:34:42,599
based on technical concept because you can always solve one

606
00:34:42,639 --> 00:34:48,559
problem technical yeah. Yeah, But if you have a calculation

607
00:34:48,679 --> 00:34:51,960
and you make those technical lists, for instance, instead of

608
00:34:52,000 --> 00:34:55,639
really understanding what is the business concept seen from the

609
00:34:55,679 --> 00:34:59,480
business that is part of this calculation. And my belief

610
00:34:59,599 --> 00:35:02,039
and what I think is the power of domain during

611
00:35:02,039 --> 00:35:06,199
the sign is that when you use the business concept,

612
00:35:06,760 --> 00:35:10,199
is this more likely that the next business requirements actually

613
00:35:10,239 --> 00:35:13,519
fit into your code with because it's coming from the

614
00:35:13,559 --> 00:35:17,320
same business. So I can't prove it, I usually say,

615
00:35:17,440 --> 00:35:21,440
but I have experienced it. Yeah.

616
00:35:21,480 --> 00:35:25,360
Speaker 1: So I'm working on an application right now and while

617
00:35:25,360 --> 00:35:31,079
it's not formal DDD We certainly grouped the projects into

618
00:35:31,360 --> 00:35:36,880
their different domains, but then we ended up with a

619
00:35:36,920 --> 00:35:40,960
shared project that has code that they're all going to use,

620
00:35:41,079 --> 00:35:43,920
but in different ways. So then we would subclass in

621
00:35:43,960 --> 00:35:48,559
the domain the appropriate domain what we needed and strip

622
00:35:48,599 --> 00:35:52,239
out the generic fundamental stuff in the shared project. I

623
00:35:52,280 --> 00:35:54,880
guess that's something that you probably I think. I mean,

624
00:35:55,039 --> 00:35:57,119
you know, somebody could be out there saying, yeah, but

625
00:35:57,119 --> 00:36:00,239
wounce you duplicate a lot of code. Well, no, not

626
00:36:00,360 --> 00:36:04,719
necessarily not if you just have good architecture design up front.

627
00:36:05,159 --> 00:36:08,559
Speaker 3: Yeah, And I think if it's two different bonding concepts

628
00:36:08,840 --> 00:36:11,639
bond the context of its two different business area, they'd

629
00:36:11,679 --> 00:36:16,440
be probably changed for different reasons and at at different pace.

630
00:36:16,960 --> 00:36:19,400
So even though it's if it is a duplication from

631
00:36:19,440 --> 00:36:23,519
the start, I'm much more concerned that Okay, what if

632
00:36:23,559 --> 00:36:26,239
it is the same, but then they start to change

633
00:36:26,760 --> 00:36:30,280
independent of each other, because it doesn't really long together

634
00:36:30,480 --> 00:36:33,360
seen from the business So I find this thinking in

635
00:36:33,400 --> 00:36:37,519
the business term as a really good guideline for forgetting

636
00:36:37,559 --> 00:36:41,679
the right part of your application together, and that makes

637
00:36:41,719 --> 00:36:43,920
it easier to maintain it.

638
00:36:44,239 --> 00:36:46,840
Speaker 2: Okay, So, Anita, how do you go about actually building

639
00:36:46,880 --> 00:36:48,400
an event so driven application.

640
00:36:48,760 --> 00:36:51,599
Speaker 3: Well, actually I get a lot of help from some

641
00:36:51,719 --> 00:36:54,960
building blocks for building bloxes all you need and this

642
00:36:55,199 --> 00:36:58,360
was coined by Sebastian phone Conrad. I just picked upon

643
00:36:59,599 --> 00:37:03,559
talking had I looked up at YouTube that wasn't even

644
00:37:03,599 --> 00:37:07,519
at the conference, but I think it helps me demystify

645
00:37:07,679 --> 00:37:11,280
event sourcing because what you need is first you need

646
00:37:11,320 --> 00:37:14,519
a building block that is writing with commands and that

647
00:37:14,599 --> 00:37:18,960
takes care of whatever the user is doing. So when

648
00:37:18,960 --> 00:37:22,800
the user is doing something in the application, that intention

649
00:37:23,079 --> 00:37:26,960
is captured in a command and then that command need

650
00:37:27,039 --> 00:37:30,199
to do something to something and it is something. Here

651
00:37:30,320 --> 00:37:33,119
is to aggregate from ddity, as I say, a business

652
00:37:33,280 --> 00:37:37,800
entity with behavior and state, and the result of that

653
00:37:38,679 --> 00:37:42,400
is some new events or it could be zero events.

654
00:37:42,840 --> 00:37:44,920
So that is the one building block, and this is

655
00:37:45,280 --> 00:37:49,079
the one that is most similar from what we did before.

656
00:37:49,679 --> 00:37:52,519
But then of course, since we have an event source

657
00:37:52,559 --> 00:37:55,880
and just save those events, we need also to get

658
00:37:56,039 --> 00:37:59,159
the state in place. And here we have the concept

659
00:37:59,239 --> 00:38:02,960
or the building block of red models. And when you

660
00:38:03,000 --> 00:38:05,880
have this remodel, you just listen to those events that

661
00:38:05,960 --> 00:38:09,599
we briefly mention and you pick out the pieces of

662
00:38:09,719 --> 00:38:13,599
information you need and you build up the information that

663
00:38:13,639 --> 00:38:17,079
you want to display for the users. So this back

664
00:38:17,159 --> 00:38:20,239
end for front and pattern is really easy and a

665
00:38:20,239 --> 00:38:24,119
good way to go about for that. And then you

666
00:38:24,239 --> 00:38:27,480
have what sebast And from Conrad says is the cool stuff,

667
00:38:27,519 --> 00:38:30,039
and I really tend to agree with him. But that's

668
00:38:30,079 --> 00:38:34,079
the reactors. So what do the reactors, Well, they react

669
00:38:34,119 --> 00:38:37,280
to events. And I think living in a world where

670
00:38:37,599 --> 00:38:40,400
there is more and more automation, that what our solution

671
00:38:40,599 --> 00:38:43,400
is doing more and more is not necessarily the users

672
00:38:43,400 --> 00:38:47,000
pushing the buttons anymore. So you get events from other

673
00:38:47,599 --> 00:38:52,360
you're part of the event driven acle system kind of,

674
00:38:53,119 --> 00:38:56,000
and you need to react to those events. For us

675
00:38:56,679 --> 00:38:59,920
that is working related to the traders, the trades execute

676
00:39:00,280 --> 00:39:04,760
or the strategy started. Everything needs to react to each other.

677
00:39:05,480 --> 00:39:09,119
And these reactors is also the only one that where

678
00:39:09,119 --> 00:39:14,119
we isolate any side effects calling off APIs and all

679
00:39:14,159 --> 00:39:18,639
those or sending outside events, so other solutions should react

680
00:39:18,679 --> 00:39:21,599
to that is part of the reactors.

681
00:39:21,679 --> 00:39:23,880
Speaker 2: Sure, and the users are one source of events, but

682
00:39:24,199 --> 00:39:26,159
I mean you've said a couple of times trading and

683
00:39:26,280 --> 00:39:31,480
equinors here in the petroleum business, so you're dealing with production,

684
00:39:31,719 --> 00:39:34,800
you're dealing with refinement and we're dealing with commodities markets,

685
00:39:34,840 --> 00:39:38,639
so you have a lot of disparate sources of events.

686
00:39:39,280 --> 00:39:43,039
Speaker 3: Yeah, and I think there's a lot of areas out

687
00:39:43,039 --> 00:39:46,400
there where there are a lot of events. And when

688
00:39:46,440 --> 00:39:49,719
we do automation, we need to identify those events because

689
00:39:49,760 --> 00:39:53,480
we need to know when should other solutions do something

690
00:39:53,559 --> 00:39:57,320
when something has happened in the one solution. And so

691
00:39:57,440 --> 00:40:02,400
for us, it's a lot of different events. And the

692
00:40:02,440 --> 00:40:05,440
application I'm working with now is more like the traders

693
00:40:05,440 --> 00:40:08,960
for the gas traders, and yeah, they have products, so

694
00:40:09,320 --> 00:40:12,000
they and there is a lot of events when you

695
00:40:12,079 --> 00:40:14,800
are on an exchange, even if it was money.

696
00:40:14,800 --> 00:40:17,880
Speaker 2: Training you has been let's say important.

697
00:40:18,679 --> 00:40:24,519
Speaker 3: Yes, that's true. And so that is the third building block,

698
00:40:24,679 --> 00:40:28,239
and the fourth one is just this event store. And

699
00:40:28,400 --> 00:40:31,599
I think some of the secret of actually not making

700
00:40:31,679 --> 00:40:35,360
our applications too complex because you could say, okay, before

701
00:40:35,519 --> 00:40:38,280
I only had one building bock. It was so much easier.

702
00:40:38,360 --> 00:40:42,480
I don't need the reactor or the command and the remodels.

703
00:40:43,320 --> 00:40:48,159
But then again they tend to be very complex. Now

704
00:40:48,199 --> 00:40:51,639
we can divide where we put different business rules. For instance,

705
00:40:51,679 --> 00:40:55,079
if you have heavy calculation, if you have calculation like

706
00:40:55,440 --> 00:40:59,920
you should use that number of digit after in the calculation,

707
00:41:00,239 --> 00:41:04,480
or if you use this factor to go from energy

708
00:41:04,519 --> 00:41:07,199
to volume and all those things. You can do that

709
00:41:07,440 --> 00:41:10,079
just in the real models because it's not part of

710
00:41:10,119 --> 00:41:14,800
the force events. So you can place the business rules

711
00:41:14,840 --> 00:41:18,400
in the different part of the different building blocks. And

712
00:41:18,599 --> 00:41:21,360
I think the clue of it all is to make

713
00:41:22,119 --> 00:41:26,760
application because event sourcing is a bit complex. So it's

714
00:41:26,800 --> 00:41:29,519
a complex our infant and there is no way around it.

715
00:41:29,559 --> 00:41:32,039
But you have to make sure it's a complex arrangement

716
00:41:32,239 --> 00:41:36,239
of small parts so each part is not growing. And

717
00:41:36,280 --> 00:41:39,639
I think we at least us that I work in

718
00:41:39,639 --> 00:41:42,519
the IT area for years and years, we have been

719
00:41:42,639 --> 00:41:47,880
so used to build those big solutions, so we actually

720
00:41:48,440 --> 00:41:51,400
we tend to put everything together. And I think that's

721
00:41:51,400 --> 00:41:53,760
what we as a industry are trying to solve. And

722
00:41:53,880 --> 00:41:57,280
we want it more distributed. We want to split things

723
00:41:57,360 --> 00:41:59,440
up so we can change them and so on. So

724
00:41:59,559 --> 00:42:02,480
here to we have to keep eye on the different

725
00:42:02,519 --> 00:42:03,199
building box.

726
00:42:03,559 --> 00:42:08,280
Speaker 2: Sure you don't not every app makes sense for event sourcing,

727
00:42:08,360 --> 00:42:14,079
but you have a complex multi event problem. Other techniques

728
00:42:14,119 --> 00:42:17,239
could be applied, but they may have more residency problems,

729
00:42:17,239 --> 00:42:20,559
like you might have more problems maintaining that there's something

730
00:42:20,599 --> 00:42:24,239
about the architecture of event sourcing that tolerates adding new

731
00:42:24,239 --> 00:42:28,000
event feeds really well, adding new reactions to it to

732
00:42:28,039 --> 00:42:34,239
those event feeds, well, that's very tolerant to content diversity.

733
00:42:34,800 --> 00:42:36,800
More and more things can come at it and it

734
00:42:36,880 --> 00:42:40,639
doesn't get in the n over n mindus. One problem

735
00:42:40,719 --> 00:42:44,199
doesn't compound the problem when you add more diversity that way.

736
00:42:44,679 --> 00:42:47,920
Speaker 3: Yeah, and I think that's the better. The can we

737
00:42:48,000 --> 00:42:52,360
get to a place where adding new stuff isn't becoming

738
00:42:52,440 --> 00:42:57,760
harder and harder, right because it's the smaller that the software,

739
00:42:58,639 --> 00:43:02,320
And of course we can't stop believe that we we

740
00:43:02,400 --> 00:43:04,119
get there some day, so we have to try. But

741
00:43:04,199 --> 00:43:06,960
at least I think it's easier for event sourcing to

742
00:43:07,480 --> 00:43:09,320
add smaller part well.

743
00:43:09,599 --> 00:43:13,159
Speaker 2: And arguably if you've really done this well, it gets

744
00:43:13,199 --> 00:43:17,039
easier because the services are already there for a lot

745
00:43:17,079 --> 00:43:19,559
of these things. So as a new event class comes

746
00:43:19,559 --> 00:43:22,199
in or as a new reactor is needed, you don't

747
00:43:22,199 --> 00:43:24,519
have to build a bunch of stuff because the infrastructure

748
00:43:24,559 --> 00:43:25,320
is already there.

749
00:43:25,760 --> 00:43:26,199
Speaker 3: Yeah.

750
00:43:26,400 --> 00:43:30,440
Speaker 2: I almost think it's a dream, But you know, all

751
00:43:30,440 --> 00:43:33,119
we're hoping for is it doesn't get worse. It'd be

752
00:43:33,199 --> 00:43:34,400
nice if it actually got better.

753
00:43:35,000 --> 00:43:39,400
Speaker 3: Yeah, And of course event sourcing isn't dissolution for everything,

754
00:43:39,719 --> 00:43:43,960
and it's everybody said that event sourcing is not a

755
00:43:44,039 --> 00:43:48,320
high level architecture pattern and it's not something that you choose. Okay,

756
00:43:48,400 --> 00:43:51,679
everything that I make should be events source, or everything

757
00:43:51,719 --> 00:43:55,760
we make in our company. It doesn't because you have

758
00:43:55,880 --> 00:43:58,800
some simple problems that is really just a crowd problem.

759
00:43:58,840 --> 00:44:03,079
It's just updates in some information. And the same discussion

760
00:44:03,159 --> 00:44:05,679
we have had for domain during design for years too,

761
00:44:05,960 --> 00:44:09,880
how complex should it be for Actually it really the

762
00:44:10,000 --> 00:44:13,679
extra effort you put into doing ddity is something you

763
00:44:13,719 --> 00:44:17,199
should do. So but as I said, I've been working

764
00:44:17,280 --> 00:44:21,760
mainly with complex business application and there it makes sense

765
00:44:22,000 --> 00:44:24,440
for some of the problems we solve. And then what

766
00:44:24,559 --> 00:44:28,119
I'm working on now, I sometimes just thinking how should

767
00:44:28,159 --> 00:44:31,039
I solve this if I haven't had events sourcing, And

768
00:44:31,159 --> 00:44:36,320
that feels like, okay, we have gotten a good pattern

769
00:44:36,519 --> 00:44:40,360
just for this hour problem space. But of course each

770
00:44:40,480 --> 00:44:44,159
problem space is different and that's always the starting point

771
00:44:44,559 --> 00:44:46,000
understanding what you are solving.

772
00:44:46,199 --> 00:44:48,800
Speaker 2: Yeah, yeah, well, and it makes me wonder can you

773
00:44:49,199 --> 00:44:52,320
decide this ahead of time? Do you know enough or

774
00:44:52,360 --> 00:44:55,159
do you have to make the wrong thing first, like

775
00:44:55,199 --> 00:44:57,440
do you have to start down a path building something

776
00:44:57,599 --> 00:45:00,800
addressing Some ask this, they realize, well, this is going

777
00:45:00,840 --> 00:45:04,559
to be a problem. We need to re architect into

778
00:45:04,599 --> 00:45:07,079
an event source model. I would think the answer is

779
00:45:07,159 --> 00:45:10,039
read the book first. Only if you know you have

780
00:45:10,079 --> 00:45:10,559
the problem.

781
00:45:11,360 --> 00:45:13,920
Speaker 1: Well you might not know. Yeah, maybe I would think

782
00:45:13,960 --> 00:45:17,199
that the first thing is look up what event sourcing

783
00:45:17,400 --> 00:45:21,159
is and then consider how you're going to be accessing

784
00:45:21,239 --> 00:45:24,960
data and and you know, make the decision because it

785
00:45:25,000 --> 00:45:27,000
can you You're right, it can't apply everywhere.

786
00:45:27,519 --> 00:45:30,360
Speaker 3: Yeah, And that's why when I have the talk ahead

787
00:45:30,360 --> 00:45:33,480
at end the see, I try to focus on what

788
00:45:33,639 --> 00:45:35,519
is the good part and what is the hard part?

789
00:45:35,760 --> 00:45:39,880
Because you can't tell people when you should use it

790
00:45:39,920 --> 00:45:42,840
based on business domains or so on. But I try

791
00:45:42,920 --> 00:45:46,800
to figure to line out this is really nice with

792
00:45:46,920 --> 00:45:51,000
event sourcing, and this is quite make it harder when

793
00:45:51,000 --> 00:45:54,360
you do event sourcing. And then I think each team

794
00:45:54,480 --> 00:45:57,400
need to think about a problem they are solving, and see,

795
00:45:57,719 --> 00:46:00,679
do you think that the benefits are better than the pain,

796
00:46:00,840 --> 00:46:04,400
But of course you might. For instance, the first product

797
00:46:04,480 --> 00:46:07,880
where I used it, we had this event sourcing is

798
00:46:07,920 --> 00:46:11,800
really known for being a time machine. We can't travel

799
00:46:11,840 --> 00:46:15,239
into the future, but we can travel back. And our

800
00:46:15,280 --> 00:46:18,039
youser told us they had some autitudes on the fabric

801
00:46:18,159 --> 00:46:20,400
that they needed to keep track of, and I said,

802
00:46:21,079 --> 00:46:24,079
we would like in the future to know which of

803
00:46:24,119 --> 00:46:27,920
these outages did we know about three months before they happened,

804
00:46:28,480 --> 00:46:31,800
And event sourcing is kind of the really really good

805
00:46:31,840 --> 00:46:35,360
fit for that. So it was one of our motivations

806
00:46:35,360 --> 00:46:38,239
for picking that pattern. And then it turns out we

807
00:46:38,320 --> 00:46:41,760
didn't get to that part when they needed that information.

808
00:46:42,000 --> 00:46:45,360
So yeah, sometimes you have to might be changed. But

809
00:46:45,440 --> 00:46:47,920
I think focusing on a good and a hard part

810
00:46:47,960 --> 00:46:51,960
to understanding how are it different, and then each team

811
00:46:52,039 --> 00:46:54,960
need to think about, okay, here we see that we

812
00:46:55,039 --> 00:46:59,320
can solve a lot of things that event sourcing has

813
00:46:59,440 --> 00:47:03,039
the good spot, and then it might be a good

814
00:47:03,360 --> 00:47:06,920
time of using it. And one of the main pain

815
00:47:07,000 --> 00:47:10,960
point is actually the mindset is different from what people

816
00:47:11,000 --> 00:47:14,159
are used to. But I guess in it industry we

817
00:47:14,199 --> 00:47:17,400
are used to needing to change over mindset and learn

818
00:47:17,440 --> 00:47:21,880
new stuff all the time, So you have to have

819
00:47:21,920 --> 00:47:25,639
a team that embraced that part to think differently.

820
00:47:25,880 --> 00:47:29,679
Speaker 1: Sure, you reminded me of when you said, you know,

821
00:47:29,760 --> 00:47:31,960
we how do how would we know three months ahead

822
00:47:31,960 --> 00:47:34,199
of time when we look at the event sources. Is

823
00:47:34,239 --> 00:47:38,280
there room for predictive analytics and other AI to look

824
00:47:38,320 --> 00:47:43,800
at the event source data and maybe notify us when

825
00:47:43,800 --> 00:47:45,079
they see patterns coming.

826
00:47:45,360 --> 00:47:47,880
Speaker 3: We haven't been playing in that area, but yeah, I

827
00:47:47,920 --> 00:47:51,440
think so. I think you know, as I said, I

828
00:47:51,559 --> 00:47:55,519
use this schlogan of architecting for tomorrow questions because you

829
00:47:55,639 --> 00:47:59,280
have those events and you can do analytics on them,

830
00:47:59,639 --> 00:48:03,719
and you don't need to know ahead of time, Actually

831
00:48:03,760 --> 00:48:07,159
what information do we need because they're only thinking what

832
00:48:07,199 --> 00:48:11,000
are happening in the business and the critical information related

833
00:48:11,000 --> 00:48:14,800
to that event a bit independent if it's useful or not,

834
00:48:15,679 --> 00:48:17,079
because one day it will be.

835
00:48:17,280 --> 00:48:19,840
Speaker 1: You also have to you also have to put in

836
00:48:19,519 --> 00:48:25,320
the event source catastrophic failure if you're going to try

837
00:48:25,360 --> 00:48:26,599
to prevent it in the future.

838
00:48:27,639 --> 00:48:30,000
Speaker 2: About I mean, this is going to be more data intensive,

839
00:48:30,039 --> 00:48:32,159
but goodness knows, we have enough storage base like that.

840
00:48:32,599 --> 00:48:34,280
Once upon a time, we were really careful about how

841
00:48:34,320 --> 00:48:36,159
much data we stored it, so we tended to stare

842
00:48:36,199 --> 00:48:38,760
of the agree because it costs less. That's not the

843
00:48:38,800 --> 00:48:41,760
issue anymore. Now. The issue is we don't know why

844
00:48:41,800 --> 00:48:44,599
we did what we did. Last year because we only

845
00:48:44,599 --> 00:48:46,679
have the aggregate data, not the whole chain.

846
00:48:47,280 --> 00:48:51,679
Speaker 3: Yeah. I actually had a very interesting discussion with Alberto

847
00:48:51,760 --> 00:48:55,199
Brandolini at the explore Ddity conference when he was talking

848
00:48:55,360 --> 00:48:59,159
that sometimes, if I understood it correctly, I sometimes see

849
00:48:59,280 --> 00:49:02,280
that issues you try to solve, for instance, in the

850
00:49:02,360 --> 00:49:06,280
data warehouse could have been kind of easily extracted if

851
00:49:06,320 --> 00:49:08,840
you have the events, because I think when you get

852
00:49:08,960 --> 00:49:12,000
to on the other side, you try to do the analytics.

853
00:49:12,639 --> 00:49:15,519
As I said, even in our solution back in time,

854
00:49:15,519 --> 00:49:18,559
we put all this flag because I think we need

855
00:49:18,599 --> 00:49:22,000
to know what have happened and why, and before we

856
00:49:22,079 --> 00:49:26,840
only had this data, so we do different things just

857
00:49:26,920 --> 00:49:30,840
to try to analyze it to understand what did happen

858
00:49:30,880 --> 00:49:33,960
in the business. And this gives you that as the

859
00:49:33,960 --> 00:49:37,800
core part of your information. So I really believe that

860
00:49:38,159 --> 00:49:41,360
as organizations get more and more data driven and more

861
00:49:41,519 --> 00:49:44,800
part are looking at the data, that it's easier to

862
00:49:44,920 --> 00:49:48,039
compare because you have fitted in a context already.

863
00:49:48,679 --> 00:49:51,599
Speaker 2: Yeah, and the sort of modern data analytics model now

864
00:49:51,599 --> 00:49:54,679
where you have the quote unquote data lake rather than

865
00:49:54,679 --> 00:49:58,920
a warehouse, you're literally just dropping those blocks of events

866
00:49:59,480 --> 00:50:02,719
up into the lake for analytical tools to be able

867
00:50:02,760 --> 00:50:05,239
to have access to the truth rather than they aggregate.

868
00:50:05,480 --> 00:50:08,960
Speaker 3: Yeah, I know. We also try to at least an

869
00:50:08,960 --> 00:50:12,960
equino to embrace this Tata mesh concepts. So instead of

870
00:50:13,000 --> 00:50:15,960
having one big lake that every events are swimming in,

871
00:50:16,400 --> 00:50:19,440
you have it into a mesh. That is I call

872
00:50:19,519 --> 00:50:22,679
it to manduin the sign for a data because you

873
00:50:22,840 --> 00:50:28,000
try to make a domain around your collective data that

874
00:50:28,039 --> 00:50:32,840
you before put just in aware else because that will

875
00:50:32,880 --> 00:50:35,000
also give you more context. And I think that's the

876
00:50:35,079 --> 00:50:39,159
hard part with data without context? What is it actually?

877
00:50:39,480 --> 00:50:40,519
That is hard to say.

878
00:50:40,960 --> 00:50:43,639
Speaker 2: The challenge with the mesh is the intersection points right

879
00:50:44,159 --> 00:50:48,440
each If each different set of applications has its own customer,

880
00:50:48,519 --> 00:50:51,239
how do we have a unified customer. Yeah, but those

881
00:50:51,280 --> 00:50:53,840
are good problems to tackle, it is, and.

882
00:50:53,800 --> 00:50:56,880
Speaker 3: I guess that's the challenge of the distributed application too.

883
00:50:57,400 --> 00:50:59,960
When we put things, it's hard to put it together.

884
00:51:00,559 --> 00:51:04,480
When everything is together, it's really really hard just to

885
00:51:04,639 --> 00:51:07,920
move it anyway. Balance.

886
00:51:08,079 --> 00:51:10,639
Speaker 2: Yeah, the monolith is in the answer to everything, and

887
00:51:10,639 --> 00:51:12,880
the distributed system is the answer to everything. So there's

888
00:51:12,880 --> 00:51:15,079
always going to be seams, Yeah, where we're going to

889
00:51:15,119 --> 00:51:16,840
have to figure out where that how to battle with

890
00:51:16,880 --> 00:51:17,920
those particularly.

891
00:51:17,760 --> 00:51:20,320
Speaker 1: Common topic we've been discussing here for the last year

892
00:51:20,440 --> 00:51:24,719
or so. During two years, yeah, two years, good lord, at.

893
00:51:24,679 --> 00:51:29,039
Speaker 2: Least dely longer, just because the sort of the reality

894
00:51:29,079 --> 00:51:30,639
of we're now at a place where we have as

895
00:51:30,719 --> 00:51:35,440
much compute, as much uh storage as we want, so

896
00:51:35,679 --> 00:51:38,159
now you're sort of designing for the optimal. Maybe it's

897
00:51:38,159 --> 00:51:40,360
a cost control thing, but it's most Most of the

898
00:51:40,400 --> 00:51:43,159
cost controls are about maintaining software, being able to do

899
00:51:43,199 --> 00:51:46,719
the new versions quickly, being able to respond to business opportunities,

900
00:51:47,320 --> 00:51:51,840
and so you architectures are hard. There isn't a right way.

901
00:51:51,840 --> 00:51:54,039
If there was, we'd all be doing it right. You

902
00:51:54,039 --> 00:51:56,199
can buy it at seven eleven. If it was easy.

903
00:51:56,800 --> 00:51:59,960
Speaker 3: I heard someone saying that, look at all the conference

904
00:52:00,199 --> 00:52:04,960
is out there on it. If it was easy, why

905
00:52:04,960 --> 00:52:07,320
should we have them. It's because we need to learn

906
00:52:07,400 --> 00:52:11,239
from each other to solve those problems, because everything depends.

907
00:52:11,599 --> 00:52:14,639
So you need to learn enough to really be able

908
00:52:14,760 --> 00:52:18,280
to think about how is how should we do it?

909
00:52:18,320 --> 00:52:19,320
In our context?

910
00:52:19,920 --> 00:52:23,639
Speaker 1: So what's next for you? Anita? Speaking anywhere? Writing some

911
00:52:23,679 --> 00:52:25,559
more stuff? What are you what are you working on?

912
00:52:25,599 --> 00:52:27,360
What's in your inbox? Yeah?

913
00:52:27,400 --> 00:52:32,000
Speaker 3: Well we'll go to London to the jacks y X

914
00:52:32,360 --> 00:52:36,360
London conference. That's the next one. That's the only one

915
00:52:36,400 --> 00:52:39,920
I know for now. But I also are preparing thinking

916
00:52:39,960 --> 00:52:44,719
about talks for both explore d d D and ddity Europe,

917
00:52:44,920 --> 00:52:48,320
just because I think those conferences is I learned so

918
00:52:48,400 --> 00:52:51,239
much every time I go there, and I really want

919
00:52:51,280 --> 00:52:54,920
to to both learn from others and share what I

920
00:52:55,000 --> 00:53:00,280
have learned by working as hands on every day. So

921
00:53:00,920 --> 00:53:05,039
the main part it's to make this application that we

922
00:53:05,079 --> 00:53:08,360
are working on for the traders better and better and

923
00:53:08,480 --> 00:53:12,159
more and more functionality every day together in the team.

924
00:53:12,320 --> 00:53:14,880
It's really enjoy working in the.

925
00:53:14,960 --> 00:53:18,480
Speaker 1: Team fantastic, you know I before we go, I really

926
00:53:18,480 --> 00:53:22,639
appreciate just a plain English way that you explain these things.

927
00:53:22,840 --> 00:53:26,400
It's great. I thank you, and I really appreciate your

928
00:53:26,559 --> 00:53:31,239
approach to events, sourcing and DDD and on all of it.

929
00:53:31,239 --> 00:53:33,840
It's great. So thank you very much for joining us

930
00:53:33,880 --> 00:53:34,280
this hour.

931
00:53:34,880 --> 00:53:38,199
Speaker 3: Thank you so much for having me. Have a nice evening, all.

932
00:53:38,159 --> 00:53:41,000
Speaker 1: Right, and we'll talk to you next time on dot

933
00:53:41,079 --> 00:54:04,320
net rocks. Dot net Rocks is brought to you by

934
00:54:04,400 --> 00:54:09,079
Franklin's Net and produced by Pop Studios, a full service audio,

935
00:54:09,199 --> 00:54:13,639
video and post production facility. Located physically in New London, Connecticut,

936
00:54:13,880 --> 00:54:18,679
and of course in the cloud online at pwop dot com.

937
00:54:18,880 --> 00:54:21,000
Visit our website at d O T N E t

938
00:54:21,239 --> 00:54:25,280
R O c k S dot com for RSS feeds, downloads,

939
00:54:25,400 --> 00:54:29,079
mobile apps, comments, and access to the full archives going

940
00:54:29,119 --> 00:54:32,519
back to show number one, recorded in September two thousand

941
00:54:32,559 --> 00:54:35,199
and two. And make sure you check out our sponsors.

942
00:54:35,360 --> 00:54:38,400
They keep us in business. Now go write some code,

943
00:54:38,719 --> 00:54:46,000
See you next time. You got jam vanst