WEBVTT

1
00:00:01.080 --> 00:00:04.799
<v Speaker 1>How'd you like to listen to dot NetRocks with no ads? Easy?

2
00:00:05.360 --> 00:00:08.560
<v Speaker 1>Become a patron For just five dollars a month, you

3
00:00:08.599 --> 00:00:11.320
<v Speaker 1>get access to a private RSS feed where all the

4
00:00:11.359 --> 00:00:14.560
<v Speaker 1>shows have no ads. Twenty dollars a month will get

5
00:00:14.599 --> 00:00:18.440
<v Speaker 1>you that and a special dot NetRocks patron mug. Sign

6
00:00:18.519 --> 00:00:22.120
<v Speaker 1>up now at Patreon dot dot NetRocks dot com.

7
00:00:22.160 --> 00:00:24.679
<v Speaker 2>Hey Carl and Richard here with your twenty twenty four

8
00:00:24.839 --> 00:00:26.000
<v Speaker 2>NDC schedule.

9
00:00:26.320 --> 00:00:29.640
<v Speaker 1>We'll be at as many NDC conferences as possible this year,

10
00:00:29.960 --> 00:00:33.200
<v Speaker 1>and you should consider attending no matter what. The Copenhagen

11
00:00:33.240 --> 00:00:37.640
<v Speaker 1>Developers Festival happens August twenty sixth through the thirtieth. Tickets

12
00:00:37.679 --> 00:00:40.719
<v Speaker 1>at Cphdevfest dot com.

13
00:00:40.880 --> 00:00:44.719
<v Speaker 2>Ndcporto is happening October fourteenth through the eighteenth. Tickets at

14
00:00:44.799 --> 00:00:46.600
<v Speaker 2>Ndcporto dot com.

15
00:00:46.600 --> 00:01:02.079
<v Speaker 1>We'll see you there, we hope. Hey, guess what it's

16
00:01:02.119 --> 00:01:05.120
<v Speaker 1>dot net rocks. I'm Carl Franklin and I'm Richard Campbell.

17
00:01:05.480 --> 00:01:08.359
<v Speaker 1>We're here again. Yes, you can't get rid of us.

18
00:01:08.480 --> 00:01:10.760
<v Speaker 1>It's still the summertime too, so we've been at home

19
00:01:10.959 --> 00:01:15.560
<v Speaker 1>for a while. Yeah. I had a sad weekend. I

20
00:01:15.599 --> 00:01:18.280
<v Speaker 1>went to a funeral of my cousin who was three

21
00:01:18.359 --> 00:01:22.159
<v Speaker 1>years younger than me, and it was too soon for her.

22
00:01:22.280 --> 00:01:23.439
<v Speaker 1>But cancer sucks.

23
00:01:23.719 --> 00:01:26.760
<v Speaker 2>Yeah, no, I know what you mean. Man, it's reality.

24
00:01:26.760 --> 00:01:28.840
<v Speaker 2>We're living with her now older than friends of ours

25
00:01:28.840 --> 00:01:29.480
<v Speaker 2>that we're losing.

26
00:01:30.480 --> 00:01:33.040
<v Speaker 1>However, I did get a chance to visit with the

27
00:01:33.079 --> 00:01:38.040
<v Speaker 1>other Franklins in the family, and they're a stoic bunch. Man.

28
00:01:38.079 --> 00:01:41.519
<v Speaker 1>There was nary a tear, even though they felt the

29
00:01:41.599 --> 00:01:46.079
<v Speaker 1>loss deeply. It was very strange. Anyway, I won't go

30
00:01:46.120 --> 00:01:48.599
<v Speaker 1>into that. How are you.

31
00:01:49.040 --> 00:01:51.680
<v Speaker 2>I'm good, you know, with the summer winding down, getting

32
00:01:51.680 --> 00:01:55.480
<v Speaker 2>ready to go to Copenhagen Developers Festival in the near

33
00:01:55.560 --> 00:01:58.519
<v Speaker 2>future here, and that'll be the first trip since June.

34
00:01:58.719 --> 00:02:01.000
<v Speaker 2>So it's been a good couple of months on the

35
00:02:01.040 --> 00:02:02.599
<v Speaker 2>coast and you know it's nice up here.

36
00:02:02.799 --> 00:02:04.079
<v Speaker 1>Yeah, that's right.

37
00:02:04.200 --> 00:02:06.920
<v Speaker 2>And I've been smoking a lot of salmon and ribs

38
00:02:06.959 --> 00:02:08.199
<v Speaker 2>and you know that kind of thing.

39
00:02:08.280 --> 00:02:11.759
<v Speaker 1>Is that good for your lungs? I'm not smoke smoking salmon.

40
00:02:11.879 --> 00:02:15.759
<v Speaker 2>Yeah, but plus it's really hard to keep it lit.

41
00:02:16.000 --> 00:02:22.039
<v Speaker 1>Yeah. All right, Well let's jump into the way we

42
00:02:22.120 --> 00:02:24.319
<v Speaker 1>start the show with better not a framework?

43
00:02:24.520 --> 00:02:33.759
<v Speaker 2>Awesome, man, what do you got? Well?

44
00:02:33.759 --> 00:02:35.719
<v Speaker 1>This started out of course, is a way that I

45
00:02:35.719 --> 00:02:40.280
<v Speaker 1>could poke, uh, you know, a little dive into little

46
00:02:40.400 --> 00:02:42.680
<v Speaker 1>parts of the framework, the dot net framework back when

47
00:02:42.719 --> 00:02:45.080
<v Speaker 1>it was a Windows framework, and then it just sort

48
00:02:45.120 --> 00:02:52.400
<v Speaker 1>of evolved to Carl says something something somebody once said

49
00:02:52.719 --> 00:02:56.199
<v Speaker 1>this is Carl does a Google search five minutes before

50
00:02:56.240 --> 00:03:00.080
<v Speaker 1>the show. But today we have something different and it

51
00:03:00.080 --> 00:03:06.280
<v Speaker 1>involves you, mister Campbell. So it's about dev Intersection, So

52
00:03:06.360 --> 00:03:07.240
<v Speaker 1>tell me what's going on.

53
00:03:07.400 --> 00:03:09.960
<v Speaker 2>So we've got a side by shote show, as we

54
00:03:10.120 --> 00:03:13.840
<v Speaker 2>like to do in at dev Intersection. We're going side

55
00:03:13.840 --> 00:03:16.919
<v Speaker 2>byside with a new show, or at least a new name,

56
00:03:17.039 --> 00:03:19.840
<v Speaker 2>which is the Next Gen Ai Show. So this is

57
00:03:20.120 --> 00:03:23.719
<v Speaker 2>at the MGMGEN in Las Vegas from the tenth to

58
00:03:23.759 --> 00:03:26.560
<v Speaker 2>the twelfth of September, so coming up right away, right

59
00:03:26.639 --> 00:03:29.879
<v Speaker 2>and we've got a special offer putting on we call

60
00:03:29.960 --> 00:03:33.479
<v Speaker 2>the Bogo offer. You buy one get one free.

61
00:03:33.080 --> 00:03:35.520
<v Speaker 1>That's right. So if you haven't registered yet and you

62
00:03:35.520 --> 00:03:37.240
<v Speaker 1>want to go and you want to get a free ticket,

63
00:03:37.280 --> 00:03:40.439
<v Speaker 1>what you do is you use the code gen Ai

64
00:03:40.719 --> 00:03:44.919
<v Speaker 1>bogo g E n AI b O g O discount

65
00:03:44.919 --> 00:03:48.439
<v Speaker 1>code when you're registering at either next gen ai com

66
00:03:48.560 --> 00:03:53.960
<v Speaker 1>for dev Intersection dot com and with a full price registration,

67
00:03:54.120 --> 00:03:57.840
<v Speaker 1>you'll receive an email confirmation which will include a unique

68
00:03:57.879 --> 00:04:01.240
<v Speaker 1>discount code for a free second registration to pass on

69
00:04:01.280 --> 00:04:04.199
<v Speaker 1>to an additional attendee. Right, so there you go. It's

70
00:04:04.199 --> 00:04:05.560
<v Speaker 1>buy one, get one free.

71
00:04:05.639 --> 00:04:07.639
<v Speaker 2>And by the way, you can registered to either show,

72
00:04:08.159 --> 00:04:10.759
<v Speaker 2>it doesn't matter which, and you have access to everything.

73
00:04:10.879 --> 00:04:13.400
<v Speaker 2>We just we tend to do, you know, the marketing

74
00:04:13.439 --> 00:04:16.839
<v Speaker 2>towards the Microsoft community, Visual Studio C Shop on the

75
00:04:16.839 --> 00:04:20.199
<v Speaker 2>internest the radiosexual side, and the marketing towards the AI

76
00:04:20.360 --> 00:04:24.120
<v Speaker 2>community on the next gen AI side, but we want those,

77
00:04:24.160 --> 00:04:25.839
<v Speaker 2>you know, we call it intersection for reason. It's a

78
00:04:25.839 --> 00:04:28.759
<v Speaker 2>crossing over of different interest areas, and so that's why

79
00:04:28.800 --> 00:04:30.600
<v Speaker 2>we have the two names and the two websites, but

80
00:04:30.639 --> 00:04:31.480
<v Speaker 2>it's all the same show.

81
00:04:31.639 --> 00:04:34.920
<v Speaker 1>That's great. So that's what I got. Who's talking to

82
00:04:35.000 --> 00:04:35.800
<v Speaker 1>us today, Richard?

83
00:04:35.959 --> 00:04:38.879
<v Speaker 2>Awesome dude. And speaking of AI stuff, I grabbed a

84
00:04:38.879 --> 00:04:41.319
<v Speaker 2>comment of Show eighteen ninety four, which you did back

85
00:04:41.360 --> 00:04:44.000
<v Speaker 2>in April of this year with Carl Getz. We were

86
00:04:44.040 --> 00:04:48.480
<v Speaker 2>talking about programming with speech in AI, and this particular

87
00:04:48.480 --> 00:04:50.560
<v Speaker 2>comment comes from SD Penner who said, I thought this

88
00:04:50.759 --> 00:04:52.680
<v Speaker 2>was great. This opened my eyes to new ways of

89
00:04:52.720 --> 00:04:56.040
<v Speaker 2>working with visual Studio, because that's the problem with visual Studio,

90
00:04:56.079 --> 00:04:58.000
<v Speaker 2>like everything's in there, you just can't find it, right,

91
00:04:58.079 --> 00:05:02.240
<v Speaker 2>Like there's so many tools. Oddly enough, or maybe suspiciously,

92
00:05:02.680 --> 00:05:06.240
<v Speaker 2>this recent code rush video came across my feed where

93
00:05:06.240 --> 00:05:10.360
<v Speaker 2>they talked about supporting voice commands that we're mentioned in

94
00:05:10.360 --> 00:05:14.000
<v Speaker 2>a podcast on dot net rocks because we've already done this, right, Yeah,

95
00:05:14.120 --> 00:05:16.639
<v Speaker 2>talk to Mark Miller will He was playing with the

96
00:05:16.680 --> 00:05:20.800
<v Speaker 2>idea as well. So you're right, there's an exploration of

97
00:05:20.879 --> 00:05:22.560
<v Speaker 2>tooling right now.

98
00:05:22.680 --> 00:05:22.920
<v Speaker 3>Yeah.

99
00:05:23.079 --> 00:05:28.920
<v Speaker 2>I think a general pressure against the user interface to

100
00:05:29.120 --> 00:05:32.639
<v Speaker 2>just include sort of that chat mechanism and or voice

101
00:05:32.680 --> 00:05:36.279
<v Speaker 2>mechanism with it in a way to describe your goals,

102
00:05:36.279 --> 00:05:39.279
<v Speaker 2>describe your ideas, and use large language models to pull

103
00:05:39.399 --> 00:05:41.399
<v Speaker 2>value from it to save you some time.

104
00:05:41.560 --> 00:05:44.959
<v Speaker 1>So, and it's really getting good, Like voice commands have

105
00:05:45.079 --> 00:05:46.040
<v Speaker 1>always been around.

106
00:05:46.279 --> 00:05:49.240
<v Speaker 2>Yeah, it's just dragon naturally speaking in the eighties for

107
00:05:49.319 --> 00:05:50.000
<v Speaker 2>god's sake.

108
00:05:49.879 --> 00:05:52.040
<v Speaker 1>That's right, where you trained your parrot to turn the

109
00:05:52.120 --> 00:05:52.839
<v Speaker 1>lights on and off.

110
00:05:52.839 --> 00:05:54.319
<v Speaker 2>But don't do that.

111
00:05:54.439 --> 00:06:01.120
<v Speaker 1>I do not, But anyway, Yeah, so it's getting really

112
00:06:01.199 --> 00:06:06.240
<v Speaker 1>good in just about every interface that I have. I

113
00:06:06.360 --> 00:06:09.160
<v Speaker 1>use it to I use a speech to talk to

114
00:06:09.399 --> 00:06:12.160
<v Speaker 1>chat GPT on my phone. Hm, I use speech in

115
00:06:12.160 --> 00:06:15.399
<v Speaker 1>my car. We'll talk about that next show. Sure, I

116
00:06:15.560 --> 00:06:20.160
<v Speaker 1>use I don't use speech at the PC though, but yeah,

117
00:06:20.279 --> 00:06:25.360
<v Speaker 1>but yeah, I'm getting toward it because yeah, just mousing around, Yeah,

118
00:06:25.360 --> 00:06:26.199
<v Speaker 1>it gets tiring.

119
00:06:26.319 --> 00:06:28.199
<v Speaker 2>I didn't even think about the fact that today, when

120
00:06:28.199 --> 00:06:30.720
<v Speaker 2>I walk into my office to record a show, I

121
00:06:30.759 --> 00:06:34.439
<v Speaker 2>do command Home Assistant via voice to switch to video mode,

122
00:06:35.360 --> 00:06:38.480
<v Speaker 2>which switches the computer around, turns on the lights, like

123
00:06:38.560 --> 00:06:41.920
<v Speaker 2>configures everything to get ready to record. That's really cool,

124
00:06:42.079 --> 00:06:44.920
<v Speaker 2>normal workflow. And then when it's done, tell okay, go

125
00:06:45.000 --> 00:06:47.360
<v Speaker 2>back to normal and it switches everything backed off again.

126
00:06:47.920 --> 00:06:50.079
<v Speaker 2>So yeah, it's happening. So as do you? Thank you

127
00:06:50.120 --> 00:06:52.000
<v Speaker 2>so much for your comment. Copy of music Cobey is

128
00:06:52.000 --> 00:06:53.160
<v Speaker 2>on its way to you. And if you'd like a

129
00:06:53.160 --> 00:06:54.839
<v Speaker 2>copy of music Gobe, I write a comment on the

130
00:06:54.839 --> 00:06:57.360
<v Speaker 2>website at dot at Rocks dot com or on the facebooks.

131
00:06:57.399 --> 00:06:59.439
<v Speaker 2>We publish every show there, and if you comment there

132
00:06:59.439 --> 00:07:01.439
<v Speaker 2>in a really we'll send you copy of music go by.

133
00:07:01.560 --> 00:07:04.839
<v Speaker 1>Music to code by still very popular option for developers

134
00:07:04.879 --> 00:07:08.959
<v Speaker 1>who want help getting into the zone. And yeah, we'll

135
00:07:09.000 --> 00:07:11.639
<v Speaker 1>send you a free one if like what just happened

136
00:07:11.680 --> 00:07:15.759
<v Speaker 1>right here, somebody's getting a free music yestaed by Yeah, okay,

137
00:07:16.000 --> 00:07:20.000
<v Speaker 1>let me introduce our guest today. Anita Kavama is a

138
00:07:20.040 --> 00:07:23.079
<v Speaker 1>hands on software architect with more than twenty five years

139
00:07:23.079 --> 00:07:27.319
<v Speaker 1>of experience from building business solutions. In the late nineties,

140
00:07:27.360 --> 00:07:30.480
<v Speaker 1>she advocated for the importance of UX before it was

141
00:07:30.519 --> 00:07:35.000
<v Speaker 1>accepted as important by the software community. Today, Anita feels

142
00:07:35.000 --> 00:07:37.920
<v Speaker 1>at home in the domain driven Design community, where she's

143
00:07:37.959 --> 00:07:42.160
<v Speaker 1>been a frequent speaker the last years. Currently, she has

144
00:07:42.199 --> 00:07:45.639
<v Speaker 1>a great time as a coding software architect at Equanor

145
00:07:46.240 --> 00:07:49.279
<v Speaker 1>in a team delivering custom business solutions to the in

146
00:07:49.360 --> 00:07:53.879
<v Speaker 1>house trading desk. Welcome Anita, Thank you, yes, thank you.

147
00:07:53.879 --> 00:07:56.360
<v Speaker 1>You have Have you heard the show before?

148
00:07:56.639 --> 00:07:58.199
<v Speaker 3>Oh yeah, many many time.

149
00:07:58.399 --> 00:07:59.480
<v Speaker 2>Oh goodness, Oh great.

150
00:08:00.000 --> 00:08:01.160
<v Speaker 1>Should be a k quak for you.

151
00:08:02.360 --> 00:08:05.000
<v Speaker 2>And I originally twigged on the talk you were doing

152
00:08:05.000 --> 00:08:07.040
<v Speaker 2>it in DC. I was all about event sourcing. But

153
00:08:07.120 --> 00:08:10.759
<v Speaker 2>I Equinor is a big company and if DDD is

154
00:08:10.800 --> 00:08:12.160
<v Speaker 2>a playing a role in there, I'd love to hear

155
00:08:12.199 --> 00:08:14.319
<v Speaker 2>a bit of the story of what you what you're doing,

156
00:08:14.360 --> 00:08:17.279
<v Speaker 2>about how our organization like that approaches software development.

157
00:08:17.519 --> 00:08:21.079
<v Speaker 3>Yeah, actually, when d d D and the book Eric

158
00:08:21.120 --> 00:08:26.079
<v Speaker 3>Evans's book came out Eclinor engaged in this and invited

159
00:08:26.160 --> 00:08:30.600
<v Speaker 3>him over here in Norway to visit us to tell

160
00:08:30.639 --> 00:08:34.200
<v Speaker 3>more about what is d d D and also to

161
00:08:34.279 --> 00:08:37.639
<v Speaker 3>engage with some of our teams. And of course that's

162
00:08:37.799 --> 00:08:42.000
<v Speaker 3>a long long time ago. It was around I wasn't

163
00:08:42.320 --> 00:08:45.159
<v Speaker 3>coding much on that at the times. I was just

164
00:08:45.320 --> 00:08:50.080
<v Speaker 3>partly part of that as a consultant and equinor. But

165
00:08:50.200 --> 00:08:53.000
<v Speaker 3>he came over and it was a lot of you know,

166
00:08:53.759 --> 00:08:58.840
<v Speaker 3>groups and a community building inside Ecuinor for actually doing

167
00:08:58.919 --> 00:09:02.159
<v Speaker 3>the main dream in design. And then I think we

168
00:09:02.279 --> 00:09:06.159
<v Speaker 3>still are a bunch of people doing this and h

169
00:09:07.440 --> 00:09:10.720
<v Speaker 3>really engaged in the community. But there is also of

170
00:09:10.799 --> 00:09:14.360
<v Speaker 3>course teams that are not doing the main driven design.

171
00:09:14.480 --> 00:09:17.639
<v Speaker 3>But for me, I call myself a d d D lower.

172
00:09:17.799 --> 00:09:20.240
<v Speaker 3>I think I've seen the power for some of the

173
00:09:20.480 --> 00:09:24.559
<v Speaker 3>tip of application we are doing where is highly complicated

174
00:09:24.639 --> 00:09:28.720
<v Speaker 3>business application. I think the main driven design has a

175
00:09:28.759 --> 00:09:33.080
<v Speaker 3>big role. And really the d d D community is

176
00:09:33.120 --> 00:09:36.720
<v Speaker 3>so open and so warm and I have learned so

177
00:09:36.840 --> 00:09:40.720
<v Speaker 3>much from that. But I think that we really from

178
00:09:40.759 --> 00:09:45.080
<v Speaker 3>the start had to buying from some management, actually getting

179
00:09:45.879 --> 00:09:50.960
<v Speaker 3>d Garrick evans Or to our to our campus and

180
00:09:51.360 --> 00:09:54.399
<v Speaker 3>helping us out. I think was a great start, because

181
00:09:54.440 --> 00:09:57.240
<v Speaker 3>yet then you don't you can use your energy in

182
00:09:57.440 --> 00:10:00.799
<v Speaker 3>understanding and doing things that it is and easy. It's

183
00:10:00.840 --> 00:10:04.639
<v Speaker 3>always related to building hard solutions too, so you have

184
00:10:04.720 --> 00:10:07.759
<v Speaker 3>to focus. And if you use all your focus just

185
00:10:07.799 --> 00:10:11.639
<v Speaker 3>to convince the management and other around you that this

186
00:10:11.840 --> 00:10:15.000
<v Speaker 3>is something you to do, then you lose the focus

187
00:10:15.039 --> 00:10:18.440
<v Speaker 3>of actually doing the good work interesting in building the

188
00:10:18.679 --> 00:10:22.559
<v Speaker 3>IT solutions. So having that support from the start is

189
00:10:22.840 --> 00:10:24.039
<v Speaker 3>really really critical.

190
00:10:24.120 --> 00:10:27.960
<v Speaker 1>I think, did you say Eric Evans has has joined

191
00:10:28.000 --> 00:10:29.879
<v Speaker 1>you equan No.

192
00:10:29.679 --> 00:10:32.159
<v Speaker 3>No, but we kind of hire it him as a

193
00:10:32.159 --> 00:10:35.080
<v Speaker 3>consultant for our guests for some weeks or something.

194
00:10:35.240 --> 00:10:37.480
<v Speaker 2>But that book is more than twenty years old now,

195
00:10:37.559 --> 00:10:40.080
<v Speaker 2>like it's been around a while, and we interviewed him

196
00:10:40.080 --> 00:10:42.639
<v Speaker 2>in two thousand and seven and found he's a very

197
00:10:42.759 --> 00:10:45.679
<v Speaker 2>kind man, very very pleasant to talk to.

198
00:10:46.360 --> 00:10:50.120
<v Speaker 3>Absolutely. I was so lucky that I was part of

199
00:10:50.159 --> 00:10:55.159
<v Speaker 3>the Explored DDDY conference in Denver this year and there

200
00:10:55.200 --> 00:11:00.440
<v Speaker 3>we had this Diametics cake at a speaker's dinner where

201
00:11:01.000 --> 00:11:03.799
<v Speaker 3>Eric Ebbans was there, and it was for the twenty

202
00:11:04.519 --> 00:11:07.080
<v Speaker 3>years since the book came out. So it was a

203
00:11:07.120 --> 00:11:10.320
<v Speaker 3>cake with a picture of the front side of the book,

204
00:11:11.039 --> 00:11:13.960
<v Speaker 3>and we were kind of kidding that when he take

205
00:11:14.000 --> 00:11:19.120
<v Speaker 3>a bit, it was dividing into bond the context each got.

206
00:11:18.960 --> 00:11:23.919
<v Speaker 1>It the cake driven or domain driven cake.

207
00:11:24.000 --> 00:11:24.240
<v Speaker 3>Yeah.

208
00:11:24.360 --> 00:11:27.919
<v Speaker 2>Nice, Yeah, that's great, very funny. Yeah, oh right, Well,

209
00:11:28.279 --> 00:11:30.279
<v Speaker 2>I didn't mean to distract you much, but it's a

210
00:11:30.360 --> 00:11:33.200
<v Speaker 2>you know, awesome story, and I appreciate your viewpoint on that.

211
00:11:33.279 --> 00:11:36.840
<v Speaker 2>It certainly it realized like it's a career length kind

212
00:11:36.879 --> 00:11:37.840
<v Speaker 2>of thing too.

213
00:11:38.240 --> 00:11:41.720
<v Speaker 3>Yeah, And for me it's not a distraction because events

214
00:11:41.799 --> 00:11:45.559
<v Speaker 3>sourcing without the main driven the sign, I really will

215
00:11:45.600 --> 00:11:49.159
<v Speaker 3>not know how to do that. I think events sourcing

216
00:11:49.200 --> 00:11:52.799
<v Speaker 3>gives me the toolbox that is so helpful when doing

217
00:11:53.519 --> 00:11:56.120
<v Speaker 3>no the other way of around. Of course, the main

218
00:11:56.200 --> 00:11:59.519
<v Speaker 3>driven the sign gives me the toolbox with the concept

219
00:11:59.559 --> 00:12:04.279
<v Speaker 3>of aggregates the context and all that of make doing

220
00:12:04.320 --> 00:12:07.679
<v Speaker 3>events sourcing much much easier. And I think that also

221
00:12:07.759 --> 00:12:10.360
<v Speaker 3>grew out of that community, so that was how I

222
00:12:10.399 --> 00:12:13.120
<v Speaker 3>was introduced to it actually, So for me it was

223
00:12:13.159 --> 00:12:16.759
<v Speaker 3>not distraction. It was completely inside the context where I

224
00:12:16.799 --> 00:12:18.039
<v Speaker 3>think it belongs.

225
00:12:18.440 --> 00:12:22.519
<v Speaker 2>So why is the main drive design essential to event sourcing?

226
00:12:22.759 --> 00:12:26.759
<v Speaker 3>Well, for me, first of all, if this what events

227
00:12:26.840 --> 00:12:31.039
<v Speaker 3>are we focusing on, and you can do events sourcing

228
00:12:31.360 --> 00:12:35.639
<v Speaker 3>much more technical, but all I have been part of doing.

229
00:12:35.720 --> 00:12:38.759
<v Speaker 3>Then we focus on domain events and with all that's

230
00:12:38.799 --> 00:12:42.360
<v Speaker 3>a fact, it's something that has happened and really important,

231
00:12:42.519 --> 00:12:46.639
<v Speaker 3>something that the business cares about. So actually having that

232
00:12:48.039 --> 00:12:52.159
<v Speaker 3>and also when you do events sourcing, you need to

233
00:12:52.919 --> 00:12:56.639
<v Speaker 3>those events need to belong to something. And that's something

234
00:12:56.879 --> 00:13:00.399
<v Speaker 3>is the concept of aggregates that I know from domain

235
00:13:00.519 --> 00:13:03.679
<v Speaker 3>driven design. And if I haven't kind of understood that

236
00:13:03.799 --> 00:13:06.799
<v Speaker 3>concept from before, I think it would be harder to understand.

237
00:13:07.279 --> 00:13:09.320
<v Speaker 3>So where are these events belonging to?

238
00:13:10.080 --> 00:13:10.399
<v Speaker 2>Right?

239
00:13:10.559 --> 00:13:12.759
<v Speaker 3>So they need to have a place to live. So

240
00:13:13.080 --> 00:13:17.080
<v Speaker 3>that's I guess the two main things. And of course

241
00:13:17.120 --> 00:13:22.879
<v Speaker 3>events storming. That all back to Brandolini introduced also really

242
00:13:22.919 --> 00:13:26.159
<v Speaker 3>a member of the dd D community where you is

243
00:13:26.200 --> 00:13:30.799
<v Speaker 3>a brainstorming technique where you identify or all these domain

244
00:13:30.840 --> 00:13:34.840
<v Speaker 3>events also fits perfect into this picture and helps me

245
00:13:34.960 --> 00:13:38.200
<v Speaker 3>out on my team. We are using that heavily.

246
00:13:38.519 --> 00:13:42.639
<v Speaker 1>When I think of event sourcing, I think of you know,

247
00:13:42.799 --> 00:13:45.919
<v Speaker 1>like let's say you have a financial application and people

248
00:13:45.960 --> 00:13:48.519
<v Speaker 1>are in a spreadsheet and they make a change. Rather

249
00:13:48.559 --> 00:13:52.440
<v Speaker 1>than changing a value in a table, you add a

250
00:13:52.559 --> 00:13:55.480
<v Speaker 1>record to a table that the value was changed from

251
00:13:55.559 --> 00:13:58.360
<v Speaker 1>this to that with a time stamp, and who did it.

252
00:14:00.080 --> 00:14:03.080
<v Speaker 1>I never really thought of it when you were describing

253
00:14:03.559 --> 00:14:05.840
<v Speaker 1>what you're using for. It almost sounds more like a

254
00:14:05.960 --> 00:14:06.879
<v Speaker 1>logging feature.

255
00:14:07.159 --> 00:14:10.840
<v Speaker 3>Well, in that case, when you change that value, you

256
00:14:11.000 --> 00:14:14.320
<v Speaker 3>probably have the business have something in their mind. What

257
00:14:14.519 --> 00:14:19.360
<v Speaker 3>are they actually doing transferred to in business terms. So

258
00:14:19.440 --> 00:14:22.440
<v Speaker 3>it's for instance, I've been working with some trading strategies

259
00:14:22.519 --> 00:14:24.679
<v Speaker 3>and you can say we have a table with a

260
00:14:24.799 --> 00:14:29.039
<v Speaker 3>trading strategy, but when the user start that strategy, we

261
00:14:29.120 --> 00:14:31.840
<v Speaker 3>don't look upon that as changing the one value from

262
00:14:31.960 --> 00:14:35.840
<v Speaker 3>stop to start, but it's a they do. They have

263
00:14:35.919 --> 00:14:39.039
<v Speaker 3>an intention that is starting the strategy, and we get

264
00:14:39.039 --> 00:14:42.679
<v Speaker 3>a domain event that says that the strategy is started.

265
00:14:43.080 --> 00:14:47.600
<v Speaker 3>So it's more to actually explain in business terms those

266
00:14:47.840 --> 00:14:52.399
<v Speaker 3>state changes and look upon. It's not the importance here

267
00:14:52.600 --> 00:14:55.080
<v Speaker 3>just to keep track of the state changes, but really

268
00:14:55.159 --> 00:15:00.279
<v Speaker 3>understand what is happening seen from a behavior perspective in

269
00:15:00.320 --> 00:15:05.240
<v Speaker 3>the business. So it is I feel I've been working

270
00:15:05.360 --> 00:15:07.360
<v Speaker 3>with some sort of design for a long time, as

271
00:15:07.360 --> 00:15:11.639
<v Speaker 3>you said in the introduction, and also before when we

272
00:15:11.720 --> 00:15:15.399
<v Speaker 3>did not do event sourcing, we put all these noise

273
00:15:15.480 --> 00:15:18.840
<v Speaker 3>in our tables. Of course, we've put the versions because

274
00:15:18.879 --> 00:15:21.320
<v Speaker 3>we need an audit. But then we added flags. We

275
00:15:21.320 --> 00:15:24.559
<v Speaker 3>added flags that say, oh, this row is updated by

276
00:15:24.600 --> 00:15:27.159
<v Speaker 3>a user, and do you know this user idea that

277
00:15:27.919 --> 00:15:31.519
<v Speaker 3>I've been something that we do and I think everything

278
00:15:31.559 --> 00:15:34.960
<v Speaker 3>we did because we wanted to know what has actually happened.

279
00:15:35.039 --> 00:15:38.480
<v Speaker 3>We wanted that behavior we view. But all we had

280
00:15:38.639 --> 00:15:43.240
<v Speaker 3>was this static table and actually should keep the state,

281
00:15:43.679 --> 00:15:47.960
<v Speaker 3>but we enhanced it and put a lot of stuff

282
00:15:48.039 --> 00:15:51.720
<v Speaker 3>into it in order to be able to detect what

283
00:15:51.879 --> 00:15:55.039
<v Speaker 3>has actually happened. And now doing event sourcing, I can

284
00:15:55.159 --> 00:15:58.480
<v Speaker 3>just save what did actually happen and I really find

285
00:15:58.519 --> 00:15:59.519
<v Speaker 3>that so useful.

286
00:16:01.360 --> 00:16:03.720
<v Speaker 2>The domain event is sort of the starting point of

287
00:16:03.759 --> 00:16:07.440
<v Speaker 2>an event storm. What is the domain event?

288
00:16:07.799 --> 00:16:10.799
<v Speaker 3>It is something that happened in the past, And that's

289
00:16:10.879 --> 00:16:14.840
<v Speaker 3>really diffferent from the command because the command can fail

290
00:16:15.320 --> 00:16:19.159
<v Speaker 3>and the command could trigger a validation error and so on.

291
00:16:19.879 --> 00:16:23.919
<v Speaker 3>But something that has happened. Taking the same example, strategy

292
00:16:23.960 --> 00:16:28.120
<v Speaker 3>is started is completely different from the command starting the strategy.

293
00:16:28.159 --> 00:16:29.919
<v Speaker 3>What if the user is not allowed to do it?

294
00:16:30.000 --> 00:16:34.240
<v Speaker 3>So this has already happened, so it's a fact, but

295
00:16:34.320 --> 00:16:37.080
<v Speaker 3>it should also be something that the business cares about.

296
00:16:37.360 --> 00:16:40.840
<v Speaker 3>And that's one I use as a guidance for thinking

297
00:16:40.879 --> 00:16:45.159
<v Speaker 3>about which event should we take care of and save

298
00:16:45.600 --> 00:16:49.759
<v Speaker 3>which how do we bundle stuff? It shouldn't be meaningful

299
00:16:49.879 --> 00:16:53.799
<v Speaker 3>or be able to discuss with the user. And if

300
00:16:53.840 --> 00:16:56.480
<v Speaker 3>you do this events storming, you try to put those

301
00:16:56.519 --> 00:16:59.960
<v Speaker 3>domain events up in a myro board or a white

302
00:17:00.039 --> 00:17:00.960
<v Speaker 3>board or whatever.

303
00:17:01.399 --> 00:17:04.519
<v Speaker 2>As I understand, it's like it's a whiteboard, sticky note

304
00:17:05.400 --> 00:17:06.240
<v Speaker 2>process approach.

305
00:17:06.440 --> 00:17:08.599
<v Speaker 3>Yeah, it is, absolutely So.

306
00:17:08.519 --> 00:17:11.119
<v Speaker 2>What's the granularity of domain event? Is it like adding

307
00:17:11.160 --> 00:17:14.640
<v Speaker 2>something to a shopping cart or initiating a sale? Like

308
00:17:14.839 --> 00:17:15.920
<v Speaker 2>what's they.

309
00:17:15.640 --> 00:17:19.119
<v Speaker 3>Add item to a shopping card is a typical example

310
00:17:19.160 --> 00:17:22.559
<v Speaker 3>of a domain event and also remove that item, and

311
00:17:22.640 --> 00:17:26.920
<v Speaker 3>of course then you're into one other typical example of

312
00:17:27.119 --> 00:17:31.559
<v Speaker 3>how events sourcing different from other way to building solutions,

313
00:17:31.839 --> 00:17:34.759
<v Speaker 3>because if you only have the shopping cart and someone

314
00:17:34.799 --> 00:17:39.880
<v Speaker 3>asks you how often they do the customer remove just

315
00:17:39.960 --> 00:17:42.519
<v Speaker 3>this kind of shoe from my shopping card? You don't

316
00:17:42.559 --> 00:17:46.039
<v Speaker 3>have that information. So one of the slogan for events

317
00:17:46.119 --> 00:17:49.599
<v Speaker 3>sourcing is that you will never lose any data because

318
00:17:49.640 --> 00:17:52.279
<v Speaker 3>you take care of those so you can answer them.

319
00:17:52.559 --> 00:17:55.799
<v Speaker 3>I used to say, I'm architecting for tomorrow's question. You

320
00:17:55.920 --> 00:17:59.000
<v Speaker 3>never know in a data d even organization, what do

321
00:17:59.079 --> 00:18:01.839
<v Speaker 3>they ask tomorrow? I should ask me something new? Actually,

322
00:18:01.880 --> 00:18:03.839
<v Speaker 3>if they if you are truly data.

323
00:18:03.680 --> 00:18:09.680
<v Speaker 1>Driven, so I imagine that web browsing behavior and how

324
00:18:09.720 --> 00:18:12.880
<v Speaker 1>they use the application in a web for example, which

325
00:18:12.920 --> 00:18:16.640
<v Speaker 1>can all be tracked, right, I imagine that is going to

326
00:18:16.640 --> 00:18:20.640
<v Speaker 1>be very interested to the Mark Zuckerbergs of the world. Interesting.

327
00:18:21.000 --> 00:18:26.920
<v Speaker 3>Yeah, but for us, it's only those events. I mean,

328
00:18:27.440 --> 00:18:32.640
<v Speaker 3>how you are navigating into your browser. We are not tracking.

329
00:18:32.799 --> 00:18:36.559
<v Speaker 3>We are only tracking. Yeah you could, we could. Yeah,

330
00:18:36.599 --> 00:18:40.440
<v Speaker 3>And of course that depends on what information What is

331
00:18:40.480 --> 00:18:41.640
<v Speaker 3>your purpose there?

332
00:18:42.880 --> 00:18:43.119
<v Speaker 1>Yeah?

333
00:18:44.200 --> 00:18:46.200
<v Speaker 2>Okay, what's important to the organization?

334
00:18:46.519 --> 00:18:46.799
<v Speaker 1>Right?

335
00:18:46.920 --> 00:18:49.640
<v Speaker 3>Yes, it is, and also to if you have a

336
00:18:49.720 --> 00:18:53.319
<v Speaker 3>more task based user interface in opposite to a more

337
00:18:53.400 --> 00:18:56.640
<v Speaker 3>crowd base where you actually are thinking about what task

338
00:18:56.759 --> 00:18:58.920
<v Speaker 3>or the user is doing, and you might have button

339
00:18:59.079 --> 00:19:02.960
<v Speaker 3>that face start strategy instead of the just changing a

340
00:19:03.039 --> 00:19:07.960
<v Speaker 3>column in a table from stop to start, then it's

341
00:19:08.039 --> 00:19:10.680
<v Speaker 3>much easier. It is more aligned with doing AM and

342
00:19:10.799 --> 00:19:14.880
<v Speaker 3>sourcing because you're already there knowing the intention behind the

343
00:19:15.000 --> 00:19:19.200
<v Speaker 3>user because it's kind of expressing is through the functionality

344
00:19:19.240 --> 00:19:22.000
<v Speaker 3>the task is doing in the interface, right, If that

345
00:19:22.079 --> 00:19:22.599
<v Speaker 3>makes sense?

346
00:19:22.759 --> 00:19:25.519
<v Speaker 2>Well, and it's something I've always noticed with domain view

347
00:19:25.559 --> 00:19:28.720
<v Speaker 2>is that it's far more agnostic. Like crud speaks to

348
00:19:28.920 --> 00:19:30.839
<v Speaker 2>I'm speaking to an rdbm ass. I mean, I know

349
00:19:30.880 --> 00:19:33.680
<v Speaker 2>I can make it with other things. This idea of

350
00:19:34.200 --> 00:19:36.559
<v Speaker 2>the customer wants to add something to the shopping cart.

351
00:19:36.920 --> 00:19:39.960
<v Speaker 2>Everything plumbing related to that is secondary the point, right,

352
00:19:40.039 --> 00:19:41.759
<v Speaker 2>It's like, this is what the customer wants to do.

353
00:19:41.799 --> 00:19:43.519
<v Speaker 2>There's a ton of ways to go about it. Now

354
00:19:43.559 --> 00:19:46.000
<v Speaker 2>we can work through those options. But more importantly, there's

355
00:19:46.720 --> 00:19:49.920
<v Speaker 2>a series of events that occur from that desire.

356
00:19:50.279 --> 00:19:52.680
<v Speaker 3>It is, and as long as you have that event,

357
00:19:52.920 --> 00:19:57.319
<v Speaker 3>you can at unepoint in time later on play through

358
00:19:57.359 --> 00:20:01.279
<v Speaker 3>those events and construct the information that you need. So

359
00:20:01.359 --> 00:20:03.920
<v Speaker 3>you don't need to pick this is my state of

360
00:20:04.000 --> 00:20:06.680
<v Speaker 3>my application in the start, and I think that is

361
00:20:06.720 --> 00:20:09.559
<v Speaker 3>often very hard to do. To discuss what are a

362
00:20:09.640 --> 00:20:13.519
<v Speaker 3>user doing in this application is such much easier to

363
00:20:13.640 --> 00:20:16.880
<v Speaker 3>agree upon. But actually what information are they going to see?

364
00:20:16.960 --> 00:20:20.400
<v Speaker 3>And how should we save those That is much that's

365
00:20:20.559 --> 00:20:23.480
<v Speaker 3>question that need to when you show the users you

366
00:20:23.519 --> 00:20:26.119
<v Speaker 3>have given them something to say what they actually want

367
00:20:26.160 --> 00:20:30.480
<v Speaker 3>to see. So having this separated like a command, your

368
00:20:30.759 --> 00:20:34.759
<v Speaker 3>responsibility segregation. So you have the events and then the

369
00:20:35.200 --> 00:20:38.119
<v Speaker 3>things that really are changing all the time. What is

370
00:20:38.160 --> 00:20:42.000
<v Speaker 3>the valuable information to show to the users? It's much

371
00:20:42.200 --> 00:20:43.839
<v Speaker 3>easier to change, right.

372
00:20:44.440 --> 00:20:49.519
<v Speaker 1>Would you serialize the state, the relevant state and put

373
00:20:49.559 --> 00:20:54.519
<v Speaker 1>that in an event source record or would you prefer

374
00:20:54.640 --> 00:20:58.599
<v Speaker 1>to calculate the state based on a history or a

375
00:20:58.759 --> 00:20:59.720
<v Speaker 1>range of records.

376
00:21:00.079 --> 00:21:04.279
<v Speaker 3>Yeah, I prefer to just make the state based on

377
00:21:04.319 --> 00:21:07.440
<v Speaker 3>the history of the So it's two side here on

378
00:21:07.480 --> 00:21:10.759
<v Speaker 3>the right side where you need to be. You need

379
00:21:10.799 --> 00:21:13.759
<v Speaker 3>to have the exact state and we don't take any

380
00:21:13.839 --> 00:21:18.519
<v Speaker 3>eventual consistency there. So what we do we actually source

381
00:21:18.599 --> 00:21:21.960
<v Speaker 3>the state by looping through the events. Hence and the

382
00:21:22.119 --> 00:21:26.720
<v Speaker 3>term events sourcing. So your events is the truth. And

383
00:21:26.799 --> 00:21:29.400
<v Speaker 3>of course if you stream get too long, there are

384
00:21:29.680 --> 00:21:32.559
<v Speaker 3>techniques where you can do snapshotting and so, but you

385
00:21:32.640 --> 00:21:35.319
<v Speaker 3>do that when you have to. But for the start,

386
00:21:35.720 --> 00:21:39.839
<v Speaker 3>you just go through source the events. You read each

387
00:21:39.960 --> 00:21:43.920
<v Speaker 3>one event in sequence for that aggregate. And if you

388
00:21:43.960 --> 00:21:46.839
<v Speaker 3>don't know the aggregate term for DDDY, it's more like

389
00:21:46.920 --> 00:21:51.160
<v Speaker 3>the it's like a business entity that has both behavior

390
00:21:51.720 --> 00:21:55.279
<v Speaker 3>and data. So you get the aggregate state by looking

391
00:21:55.279 --> 00:21:57.839
<v Speaker 3>through the event and you just pick up the things

392
00:21:57.880 --> 00:22:01.039
<v Speaker 3>that you need in order to be able to do

393
00:22:01.160 --> 00:22:02.960
<v Speaker 3>the business rules on the right side.

394
00:22:03.200 --> 00:22:06.720
<v Speaker 1>Yeah, that's a big difference from somebody who's just doing logging.

395
00:22:06.839 --> 00:22:09.519
<v Speaker 1>Even with something like Serra log where you're taking the

396
00:22:09.559 --> 00:22:11.799
<v Speaker 1>state of an object or a bunch of objects and

397
00:22:11.799 --> 00:22:18.319
<v Speaker 1>putting them in a in a record, the state is sourced,

398
00:22:18.680 --> 00:22:22.960
<v Speaker 1>as you said, events and the clue is right there

399
00:22:23.000 --> 00:22:23.880
<v Speaker 1>in the name. Yeah.

400
00:22:23.960 --> 00:22:27.000
<v Speaker 3>And on the red side, when you want to display information,

401
00:22:27.440 --> 00:22:30.720
<v Speaker 3>you do have this eventual consistency because you react to

402
00:22:30.799 --> 00:22:35.119
<v Speaker 3>those events, and you can pick events from many different

403
00:22:35.160 --> 00:22:38.519
<v Speaker 3>streams and you build up the information you need to see.

404
00:22:38.599 --> 00:22:43.079
<v Speaker 3>And there we the typical start out at least with

405
00:22:43.279 --> 00:22:45.880
<v Speaker 3>just having that state in memory, because every time we

406
00:22:45.960 --> 00:22:48.799
<v Speaker 3>restart our application, we can just start from the first

407
00:22:48.839 --> 00:22:50.759
<v Speaker 3>event and we can spin it up and makes it

408
00:22:50.839 --> 00:22:54.759
<v Speaker 3>also easy to change early in the process. But when

409
00:22:54.799 --> 00:22:59.119
<v Speaker 3>a database grows and become too big, with just can

410
00:22:59.559 --> 00:23:02.160
<v Speaker 3>then you can build a date and you can save

411
00:23:02.240 --> 00:23:06.720
<v Speaker 3>it in whatever database you want to that is best

412
00:23:06.759 --> 00:23:09.319
<v Speaker 3>fit for that purpose. So it's not the event store

413
00:23:09.519 --> 00:23:12.039
<v Speaker 3>that keeps the remodels is that it could be a

414
00:23:12.079 --> 00:23:14.960
<v Speaker 3>separate one and then if you want to change it,

415
00:23:15.000 --> 00:23:18.519
<v Speaker 3>you can at any point just scratch it and build

416
00:23:18.519 --> 00:23:21.400
<v Speaker 3>it off from scratch it. Just if you actually change

417
00:23:21.440 --> 00:23:23.960
<v Speaker 3>your read model schema, you don't need to do a

418
00:23:24.039 --> 00:23:27.079
<v Speaker 3>database migration. And that's of course something that is.

419
00:23:27.079 --> 00:23:30.559
<v Speaker 2>Nice too, But it makes sense that you can have

420
00:23:30.640 --> 00:23:33.440
<v Speaker 2>reconciliation points so you can say, all right, we're starting

421
00:23:33.440 --> 00:23:37.920
<v Speaker 2>at a balance here now then stream forward, Yeah, depending

422
00:23:37.920 --> 00:23:41.119
<v Speaker 2>on scope, and I can there plenty of streams you

423
00:23:41.119 --> 00:23:43.559
<v Speaker 2>could last a long time, but there's also plenty where

424
00:23:43.599 --> 00:23:46.960
<v Speaker 2>it's like, listen, you're also gonna I mean, I use

425
00:23:47.000 --> 00:23:49.640
<v Speaker 2>the term reconciliation for a reason. From a financial perspectors,

426
00:23:49.640 --> 00:23:51.799
<v Speaker 2>there's a point where you declare, this month is completed,

427
00:23:51.880 --> 00:23:55.839
<v Speaker 2>here is the truth, and from then on you don't

428
00:23:56.079 --> 00:23:58.680
<v Speaker 2>want any possibility that would change. Not that it should,

429
00:23:59.240 --> 00:24:02.559
<v Speaker 2>but there's no reason to go re reconcile at that point.

430
00:24:02.799 --> 00:24:06.480
<v Speaker 3>Yeah. Nice that you take that example, because usually if

431
00:24:06.519 --> 00:24:10.039
<v Speaker 3>you try to explain event sourcing to someone from the business,

432
00:24:10.119 --> 00:24:13.960
<v Speaker 3>you do the accounting story, because accounting has been done

433
00:24:14.160 --> 00:24:16.359
<v Speaker 3>doing event sourcing for one hundreds of years.

434
00:24:16.799 --> 00:24:17.440
<v Speaker 2>That's a legend.

435
00:24:17.920 --> 00:24:22.599
<v Speaker 3>Just to release something and update, they really do it

436
00:24:22.720 --> 00:24:26.039
<v Speaker 3>the right time way like you do event sourcing, and

437
00:24:26.079 --> 00:24:28.680
<v Speaker 3>if there is for it, people you say, okay, that's

438
00:24:28.680 --> 00:24:32.680
<v Speaker 3>what guitar is doing because they also take you were

439
00:24:32.759 --> 00:24:36.960
<v Speaker 3>kicked in a new pull request, and you don't just

440
00:24:37.119 --> 00:24:40.039
<v Speaker 3>update the state, do how the changes lead to that state?

441
00:24:40.440 --> 00:24:44.720
<v Speaker 2>Yeah, no, you always have a journal. From a dba's perspective,

442
00:24:44.759 --> 00:24:48.519
<v Speaker 2>you only insert, you never update, right, and that way

443
00:24:48.559 --> 00:24:51.720
<v Speaker 2>you always have the dialogue of the truth of how

444
00:24:51.720 --> 00:24:56.079
<v Speaker 2>things happened in sequence, even though eventually you want an

445
00:24:56.119 --> 00:25:00.119
<v Speaker 2>aggregate of that because it gets too expensive to constantly recompute.

446
00:25:00.279 --> 00:25:02.599
<v Speaker 3>But there is also a goal the way you're on

447
00:25:02.680 --> 00:25:05.440
<v Speaker 3>the right side again, not on the read side, where

448
00:25:05.440 --> 00:25:09.519
<v Speaker 3>you show the information, but you try to design your

449
00:25:09.519 --> 00:25:14.680
<v Speaker 3>aggregate so they are not that not living forever. So

450
00:25:14.759 --> 00:25:18.480
<v Speaker 3>that's the same ass accounting is doing. Again. So for instance,

451
00:25:18.519 --> 00:25:20.799
<v Speaker 3>might be we are aggregates that only have the event

452
00:25:20.920 --> 00:25:23.799
<v Speaker 3>for a stream that belongs to a day for us

453
00:25:23.880 --> 00:25:29.519
<v Speaker 3>working with traders, and we do that a lot, so

454
00:25:30.000 --> 00:25:33.279
<v Speaker 3>you have techniques for not making those streams so big.

455
00:25:33.400 --> 00:25:37.119
<v Speaker 3>So when the application has run for a while, the

456
00:25:37.279 --> 00:25:39.759
<v Speaker 3>goal kind of and this is hard. It's not always

457
00:25:39.839 --> 00:25:42.079
<v Speaker 3>we managed to do it, but we try to make

458
00:25:42.119 --> 00:25:46.240
<v Speaker 3>those streams so they reset themselves, just as accounting is doing.

459
00:25:46.440 --> 00:25:47.000
<v Speaker 3>Every year.

460
00:25:47.319 --> 00:25:51.519
<v Speaker 2>I've seen a stream system for testing materials and the

461
00:25:51.599 --> 00:25:54.480
<v Speaker 2>data streams are very intensive, but the test runs are

462
00:25:54.880 --> 00:25:58.039
<v Speaker 2>minutes long, so there's clearly a beginning, a run, and

463
00:25:58.079 --> 00:26:01.440
<v Speaker 2>an end and then you can look at them from

464
00:26:01.480 --> 00:26:04.839
<v Speaker 2>an aggrid perspective. But in that time, they're taking measurements

465
00:26:04.920 --> 00:26:07.920
<v Speaker 2>multiple times per second. Like it can be a ton

466
00:26:07.960 --> 00:26:10.000
<v Speaker 2>of data, but at least it has a clear picture.

467
00:26:10.000 --> 00:26:12.400
<v Speaker 2>And I think when you think about domain in general,

468
00:26:12.480 --> 00:26:14.319
<v Speaker 2>for any kind of business case, and again I'm falling

469
00:26:14.319 --> 00:26:16.759
<v Speaker 2>back on e commerce, I did that the most. You know,

470
00:26:16.799 --> 00:26:18.880
<v Speaker 2>the month end is the month end, and we do

471
00:26:19.000 --> 00:26:21.079
<v Speaker 2>maintain those aggriates with only twelve of them of a

472
00:26:21.160 --> 00:26:26.000
<v Speaker 2>year because they're historically relevant. But they once made, never changed.

473
00:26:26.240 --> 00:26:29.880
<v Speaker 3>Yeah, yeah, and that's what we want with our events too.

474
00:26:29.920 --> 00:26:32.480
<v Speaker 3>We don't want them to be immutable. But of course,

475
00:26:32.839 --> 00:26:35.720
<v Speaker 3>since they're a domain event, they also have domain concepts

476
00:26:35.720 --> 00:26:38.880
<v Speaker 3>inside them, and that's a choice, but that's a choice

477
00:26:38.880 --> 00:26:43.079
<v Speaker 3>we have taken. So that's opinionated. But that means that

478
00:26:43.200 --> 00:26:46.440
<v Speaker 3>when we get deeper inside and understand the business concept better,

479
00:26:46.680 --> 00:26:50.440
<v Speaker 3>we might want to change them. So you are able

480
00:26:50.480 --> 00:26:54.759
<v Speaker 3>to do migration of those events. Just as we always

481
00:26:54.759 --> 00:26:57.440
<v Speaker 3>sat down, we'd always stayed in the database when we

482
00:26:57.559 --> 00:27:01.599
<v Speaker 3>need to do any changes, then you are not changing

483
00:27:01.640 --> 00:27:05.160
<v Speaker 3>the events you have. You read them up and you

484
00:27:05.319 --> 00:27:07.960
<v Speaker 3>change them and write them down to a new events store,

485
00:27:08.200 --> 00:27:09.720
<v Speaker 3>so you just start with a new cover.

486
00:27:09.880 --> 00:27:12.480
<v Speaker 2>Yeah, this sounds like even just the change of the

487
00:27:12.519 --> 00:27:14.839
<v Speaker 2>scheme in a database, and they're sort of a breakpoint,

488
00:27:15.000 --> 00:27:17.359
<v Speaker 2>you know, going from B one to V two, and

489
00:27:17.440 --> 00:27:20.400
<v Speaker 2>it is not easy to analyze across the breakpoint.

490
00:27:20.839 --> 00:27:25.400
<v Speaker 3>No. So so even though we have these real models

491
00:27:25.559 --> 00:27:28.599
<v Speaker 3>that we don't need to do migration. Now, that is

492
00:27:28.640 --> 00:27:31.079
<v Speaker 3>really good. The hard part for us then is to

493
00:27:31.160 --> 00:27:33.920
<v Speaker 3>keep those events because there you have you can have

494
00:27:34.079 --> 00:27:36.480
<v Speaker 3>versens or you can migrate them. You have the same

495
00:27:37.279 --> 00:27:39.640
<v Speaker 3>challenges as you have when you have the state in

496
00:27:39.640 --> 00:27:41.960
<v Speaker 3>a database and you can't scratch that. One.

497
00:27:42.400 --> 00:27:45.400
<v Speaker 2>Sure makes a lot of sense, and I think this

498
00:27:45.480 --> 00:27:47.319
<v Speaker 2>is a good moment for us to take a brief

499
00:27:47.359 --> 00:27:49.240
<v Speaker 2>break for these very important messages.

500
00:27:50.319 --> 00:27:54.319
<v Speaker 1>Attention dot net developers looking for the ultimate SDK to

501
00:27:54.400 --> 00:28:01.359
<v Speaker 1>handle electronic document processing. Meet TX text Control. Txtext controls

502
00:28:01.400 --> 00:28:06.759
<v Speaker 1>your go to solution for seamless PDF generation, secure electronics signatures,

503
00:28:07.039 --> 00:28:11.400
<v Speaker 1>and efficient digital forms processing all within your dot net applications.

504
00:28:11.759 --> 00:28:17.240
<v Speaker 1>Empower your products with robust document management capabilities, boost productivity

505
00:28:17.640 --> 00:28:21.559
<v Speaker 1>and deliver top notch solutions to your clients, trusted by

506
00:28:21.599 --> 00:28:25.920
<v Speaker 1>developers worldwide, including me and Richard. Txtext Control is the

507
00:28:26.079 --> 00:28:30.640
<v Speaker 1>SDK that makes a difference. Check out demos dot textcontrol

508
00:28:30.720 --> 00:28:34.400
<v Speaker 1>dot com for live online demos and see it in action.

509
00:28:37.759 --> 00:28:40.880
<v 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
<v Speaker 2>listening to dot net Rocks. Hey, and we're talking to

511
00:28:43.319 --> 00:28:46.240
<v Speaker 2>our friend Anita a bit about event sourcing and the

512
00:28:46.319 --> 00:28:50.519
<v Speaker 2>role of demander of design in that. Where does COSMOSDB

513
00:28:50.680 --> 00:28:51.240
<v Speaker 2>come into this.

514
00:28:52.039 --> 00:28:56.000
<v Speaker 3>Well, we need a place to store over events, but

515
00:28:56.160 --> 00:28:59.720
<v Speaker 3>we also need a lot of part of the solution

516
00:28:59.839 --> 00:29:02.640
<v Speaker 3>to react to those events, if that is to build

517
00:29:02.960 --> 00:29:06.160
<v Speaker 3>update your state, or if that is just to do

518
00:29:06.319 --> 00:29:10.680
<v Speaker 3>our reactions. For instance, we often get events, we call

519
00:29:10.720 --> 00:29:15.079
<v Speaker 3>them the events. Sourcing events is inside events that's part

520
00:29:15.119 --> 00:29:18.720
<v Speaker 3>of your application, but you also get event from the outside.

521
00:29:18.759 --> 00:29:22.200
<v Speaker 3>For instance, for the traders, the order a trade could

522
00:29:22.240 --> 00:29:25.279
<v Speaker 3>be executed and we listen to that and the solution

523
00:29:25.480 --> 00:29:28.920
<v Speaker 3>reacts to it. So we need something that is pushing

524
00:29:28.960 --> 00:29:33.079
<v Speaker 3>out those changes, and we need something that is how

525
00:29:33.240 --> 00:29:37.240
<v Speaker 3>high scales but also is easy to use and in

526
00:29:37.319 --> 00:29:42.279
<v Speaker 3>Microsoft documentation on Christmas TB has something called a change

527
00:29:42.319 --> 00:29:46.279
<v Speaker 3>feed and that is a mechanism for pushing out those changes.

528
00:29:47.279 --> 00:29:51.680
<v Speaker 3>And in Microsoft documentation for this change feed, they have

529
00:29:51.960 --> 00:29:56.079
<v Speaker 3>events sourcing one of the scenarios. So we were like, okay,

530
00:29:56.680 --> 00:30:01.240
<v Speaker 3>we try. We were already committed to working assure, so

531
00:30:01.359 --> 00:30:05.480
<v Speaker 3>it was already in that area. So then Christmas dB

532
00:30:05.799 --> 00:30:09.119
<v Speaker 3>seems like the best option for us to start, and

533
00:30:10.119 --> 00:30:13.880
<v Speaker 3>we really the power of this change Feit is really

534
00:30:13.920 --> 00:30:17.839
<v Speaker 3>good because you can just say I want to listen

535
00:30:18.119 --> 00:30:21.160
<v Speaker 3>to those events a processes listening, or you can have

536
00:30:21.319 --> 00:30:25.079
<v Speaker 3>multiple processes that list to those events, and then the

537
00:30:25.160 --> 00:30:28.599
<v Speaker 3>Christmas DV change feed make sure that one stream will

538
00:30:28.960 --> 00:30:31.400
<v Speaker 3>events from one stream will only be sent to one

539
00:30:31.440 --> 00:30:34.440
<v Speaker 3>of those processes that we also need because we need

540
00:30:35.079 --> 00:30:38.319
<v Speaker 3>the sequence of events are important, but the sequence of

541
00:30:38.519 --> 00:30:45.519
<v Speaker 3>events across different aggregates isn't necessarily important. So you get

542
00:30:45.559 --> 00:30:49.519
<v Speaker 3>this flexibility. And as a software architect, I really like

543
00:30:49.640 --> 00:30:54.559
<v Speaker 3>that because then I can't start small because we know

544
00:30:54.680 --> 00:30:57.200
<v Speaker 3>that we can scale out. We know that Christmas dB

545
00:30:57.319 --> 00:30:58.640
<v Speaker 3>can help us with those things.

546
00:30:58.680 --> 00:31:04.200
<v Speaker 2>Right right is geolocated, synchronized, and distributed. But you can

547
00:31:04.240 --> 00:31:06.960
<v Speaker 2>start with one node. This is an interesting angle on

548
00:31:07.000 --> 00:31:09.519
<v Speaker 2>COSMOSDBI wasn't particularly aware of that it does have the

549
00:31:09.599 --> 00:31:13.200
<v Speaker 2>speed mechanism that serves the streaming of events for sourcing.

550
00:31:13.200 --> 00:31:16.279
<v Speaker 3>Really well, it does, and that is the reason why

551
00:31:16.319 --> 00:31:17.920
<v Speaker 3>we picked just that one.

552
00:31:18.599 --> 00:31:21.240
<v Speaker 1>Well, before you started with dd D, did you do

553
00:31:21.759 --> 00:31:25.480
<v Speaker 1>non DDD development and how many years of that did

554
00:31:25.480 --> 00:31:25.720
<v Speaker 1>you do?

555
00:31:27.079 --> 00:31:31.240
<v Speaker 3>Oh? So when did I start with DDDY? As I said,

556
00:31:31.279 --> 00:31:34.559
<v Speaker 3>it was a period where I was more working with

557
00:31:34.880 --> 00:31:38.160
<v Speaker 3>user experience and as a business analyst, but I was

558
00:31:38.279 --> 00:31:44.799
<v Speaker 3>part of building solutions that didn't do DDITY in the start.

559
00:31:45.000 --> 00:31:49.920
<v Speaker 3>So I think when we started out with this, the

560
00:31:50.039 --> 00:31:53.200
<v Speaker 3>first one I was part of, I guess that was

561
00:31:53.359 --> 00:31:58.920
<v Speaker 3>two thousand and five, six maybe, And that was a

562
00:31:59.000 --> 00:32:06.079
<v Speaker 3>completely different vlication, non event sourcing, of course, and yeah,

563
00:32:06.119 --> 00:32:10.920
<v Speaker 3>a different It was related to partly invoicing and accounting.

564
00:32:11.000 --> 00:32:13.960
<v Speaker 1>Actually, oh okay, so this is great. So you have

565
00:32:14.079 --> 00:32:19.359
<v Speaker 1>experience doing invoicing and accounting without the benefits of events

566
00:32:19.400 --> 00:32:23.519
<v Speaker 1>sourcing and DDD. And then afterwards, so what was that

567
00:32:23.559 --> 00:32:27.079
<v Speaker 1>process like like when did the light bulb come on?

568
00:32:27.440 --> 00:32:30.319
<v Speaker 1>And did you at first think oh, well, this seems

569
00:32:30.359 --> 00:32:32.559
<v Speaker 1>like a lot of ceremony to get started, but then

570
00:32:32.799 --> 00:32:36.119
<v Speaker 1>it got easier like, what was your experience like making

571
00:32:36.160 --> 00:32:36.759
<v Speaker 1>that transition.

572
00:32:37.000 --> 00:32:39.880
<v Speaker 3>Yeah. First, if you take the transition from kind of

573
00:32:40.039 --> 00:32:43.480
<v Speaker 3>non domain driven design solution to domain driven the sign

574
00:32:43.559 --> 00:32:48.799
<v Speaker 3>solution I was rewrite with it a huge monolithic application.

575
00:32:49.000 --> 00:32:52.400
<v Speaker 3>It's actually very still running with the first line of

576
00:32:52.480 --> 00:32:55.200
<v Speaker 3>code written in nineteen ninety four, so there's a really

577
00:32:55.519 --> 00:32:59.039
<v Speaker 3>old one. Having a great value for the business still

578
00:32:59.119 --> 00:33:02.079
<v Speaker 3>would be to take them some technical risk. We needed

579
00:33:02.119 --> 00:33:05.920
<v Speaker 3>to migrate quite a huge part of that application. And

580
00:33:05.960 --> 00:33:11.200
<v Speaker 3>I think for me, I read the domain driven domain

581
00:33:11.359 --> 00:33:13.759
<v Speaker 3>riven the sign book when it came out and having

582
00:33:13.799 --> 00:33:17.440
<v Speaker 3>this UX had on. I think it's kind of the

583
00:33:17.519 --> 00:33:19.839
<v Speaker 3>same because that's what you want to do as a

584
00:33:20.079 --> 00:33:23.000
<v Speaker 3>user experienced person too. You want to understand the business

585
00:33:23.400 --> 00:33:25.759
<v Speaker 3>and you want to try to use those concepts, and

586
00:33:25.799 --> 00:33:28.319
<v Speaker 3>that what we tried to do. So I said that

587
00:33:28.480 --> 00:33:31.960
<v Speaker 3>DDD is X for the developers. You tried to do

588
00:33:32.119 --> 00:33:37.279
<v Speaker 3>the business concept inside your solution. And for me, the

589
00:33:37.359 --> 00:33:42.200
<v Speaker 3>big big change was that you could write this automatically

590
00:33:42.400 --> 00:33:46.119
<v Speaker 3>tests around about the context. All of a sudden, we

591
00:33:46.160 --> 00:33:49.839
<v Speaker 3>could put them into pieces that was possible to handle

592
00:33:50.000 --> 00:33:53.599
<v Speaker 3>and possible we use behavior driven development to write those

593
00:33:53.640 --> 00:33:58.720
<v Speaker 3>tests like spec flow test or feature tests. I guess

594
00:33:58.799 --> 00:34:01.000
<v Speaker 3>you have a lot of different anames of those tests,

595
00:34:01.039 --> 00:34:05.160
<v Speaker 3>but it's more high level than unit tests. So for

596
00:34:05.240 --> 00:34:10.079
<v Speaker 3>me that was Yeah. I had a great, great person

597
00:34:10.119 --> 00:34:13.079
<v Speaker 3>in my team and lip and she knew did it

598
00:34:13.440 --> 00:34:16.519
<v Speaker 3>out and in and was a good teacher. So for me,

599
00:34:16.559 --> 00:34:19.800
<v Speaker 3>it wasn't a lot of overhead. It just makes sense

600
00:34:20.000 --> 00:34:23.880
<v Speaker 3>to think that way and to build the solutions that way.

601
00:34:24.559 --> 00:34:29.039
<v Speaker 1>Right, So rather than building them by business feature, you

602
00:34:29.079 --> 00:34:32.960
<v Speaker 1>built them by technical things that they did, like I

603
00:34:32.960 --> 00:34:34.440
<v Speaker 1>would imagine no.

604
00:34:34.280 --> 00:34:39.159
<v Speaker 3>More opposite, instead of making them model of your software

605
00:34:39.559 --> 00:34:42.599
<v Speaker 3>based on technical concept because you can always solve one

606
00:34:42.639 --> 00:34:48.559
<v Speaker 3>problem technical yeah. Yeah, But if you have a calculation

607
00:34:48.679 --> 00:34:51.960
<v Speaker 3>and you make those technical lists, for instance, instead of

608
00:34:52.000 --> 00:34:55.639
<v Speaker 3>really understanding what is the business concept seen from the

609
00:34:55.679 --> 00:34:59.480
<v Speaker 3>business that is part of this calculation. And my belief

610
00:34:59.599 --> 00:35:02.039
<v Speaker 3>and what I think is the power of domain during

611
00:35:02.039 --> 00:35:06.199
<v Speaker 3>the sign is that when you use the business concept,

612
00:35:06.760 --> 00:35:10.199
<v Speaker 3>is this more likely that the next business requirements actually

613
00:35:10.239 --> 00:35:13.519
<v Speaker 3>fit into your code with because it's coming from the

614
00:35:13.559 --> 00:35:17.320
<v Speaker 3>same business. So I can't prove it, I usually say,

615
00:35:17.440 --> 00:35:21.440
<v Speaker 3>but I have experienced it. Yeah.

616
00:35:21.480 --> 00:35:25.360
<v Speaker 1>So I'm working on an application right now and while

617
00:35:25.360 --> 00:35:31.079
<v Speaker 1>it's not formal DDD We certainly grouped the projects into

618
00:35:31.360 --> 00:35:36.880
<v Speaker 1>their different domains, but then we ended up with a

619
00:35:36.920 --> 00:35:40.960
<v Speaker 1>shared project that has code that they're all going to use,

620
00:35:41.079 --> 00:35:43.920
<v Speaker 1>but in different ways. So then we would subclass in

621
00:35:43.960 --> 00:35:48.559
<v Speaker 1>the domain the appropriate domain what we needed and strip

622
00:35:48.599 --> 00:35:52.239
<v Speaker 1>out the generic fundamental stuff in the shared project. I

623
00:35:52.280 --> 00:35:54.880
<v Speaker 1>guess that's something that you probably I think. I mean,

624
00:35:55.039 --> 00:35:57.119
<v Speaker 1>you know, somebody could be out there saying, yeah, but

625
00:35:57.119 --> 00:36:00.239
<v Speaker 1>wounce you duplicate a lot of code. Well, no, not

626
00:36:00.360 --> 00:36:04.719
<v Speaker 1>necessarily not if you just have good architecture design up front.

627
00:36:05.159 --> 00:36:08.559
<v Speaker 3>Yeah, And I think if it's two different bonding concepts

628
00:36:08.840 --> 00:36:11.639
<v Speaker 3>bond the context of its two different business area, they'd

629
00:36:11.679 --> 00:36:16.440
<v Speaker 3>be probably changed for different reasons and at at different pace.

630
00:36:16.960 --> 00:36:19.400
<v Speaker 3>So even though it's if it is a duplication from

631
00:36:19.440 --> 00:36:23.519
<v Speaker 3>the start, I'm much more concerned that Okay, what if

632
00:36:23.559 --> 00:36:26.239
<v Speaker 3>it is the same, but then they start to change

633
00:36:26.760 --> 00:36:30.280
<v Speaker 3>independent of each other, because it doesn't really long together

634
00:36:30.480 --> 00:36:33.360
<v Speaker 3>seen from the business So I find this thinking in

635
00:36:33.400 --> 00:36:37.519
<v Speaker 3>the business term as a really good guideline for forgetting

636
00:36:37.559 --> 00:36:41.679
<v Speaker 3>the right part of your application together, and that makes

637
00:36:41.719 --> 00:36:43.920
<v Speaker 3>it easier to maintain it.

638
00:36:44.239 --> 00:36:46.840
<v Speaker 2>Okay, So, Anita, how do you go about actually building

639
00:36:46.880 --> 00:36:48.400
<v Speaker 2>an event so driven application.

640
00:36:48.760 --> 00:36:51.599
<v Speaker 3>Well, actually I get a lot of help from some

641
00:36:51.719 --> 00:36:54.960
<v Speaker 3>building blocks for building bloxes all you need and this

642
00:36:55.199 --> 00:36:58.360
<v Speaker 3>was coined by Sebastian phone Conrad. I just picked upon

643
00:36:59.599 --> 00:37:03.559
<v Speaker 3>talking had I looked up at YouTube that wasn't even

644
00:37:03.599 --> 00:37:07.519
<v Speaker 3>at the conference, but I think it helps me demystify

645
00:37:07.679 --> 00:37:11.280
<v Speaker 3>event sourcing because what you need is first you need

646
00:37:11.320 --> 00:37:14.519
<v Speaker 3>a building block that is writing with commands and that

647
00:37:14.599 --> 00:37:18.960
<v Speaker 3>takes care of whatever the user is doing. So when

648
00:37:18.960 --> 00:37:22.800
<v Speaker 3>the user is doing something in the application, that intention

649
00:37:23.079 --> 00:37:26.960
<v Speaker 3>is captured in a command and then that command need

650
00:37:27.039 --> 00:37:30.199
<v Speaker 3>to do something to something and it is something. Here

651
00:37:30.320 --> 00:37:33.119
<v Speaker 3>is to aggregate from ddity, as I say, a business

652
00:37:33.280 --> 00:37:37.800
<v Speaker 3>entity with behavior and state, and the result of that

653
00:37:38.679 --> 00:37:42.400
<v Speaker 3>is some new events or it could be zero events.

654
00:37:42.840 --> 00:37:44.920
<v Speaker 3>So that is the one building block, and this is

655
00:37:45.280 --> 00:37:49.079
<v Speaker 3>the one that is most similar from what we did before.

656
00:37:49.679 --> 00:37:52.519
<v Speaker 3>But then of course, since we have an event source

657
00:37:52.559 --> 00:37:55.880
<v Speaker 3>and just save those events, we need also to get

658
00:37:56.039 --> 00:37:59.159
<v Speaker 3>the state in place. And here we have the concept

659
00:37:59.239 --> 00:38:02.960
<v Speaker 3>or the building block of red models. And when you

660
00:38:03.000 --> 00:38:05.880
<v Speaker 3>have this remodel, you just listen to those events that

661
00:38:05.960 --> 00:38:09.599
<v Speaker 3>we briefly mention and you pick out the pieces of

662
00:38:09.719 --> 00:38:13.599
<v Speaker 3>information you need and you build up the information that

663
00:38:13.639 --> 00:38:17.079
<v Speaker 3>you want to display for the users. So this back

664
00:38:17.159 --> 00:38:20.239
<v Speaker 3>end for front and pattern is really easy and a

665
00:38:20.239 --> 00:38:24.119
<v Speaker 3>good way to go about for that. And then you

666
00:38:24.239 --> 00:38:27.480
<v Speaker 3>have what sebast And from Conrad says is the cool stuff,

667
00:38:27.519 --> 00:38:30.039
<v Speaker 3>and I really tend to agree with him. But that's

668
00:38:30.079 --> 00:38:34.079
<v Speaker 3>the reactors. So what do the reactors, Well, they react

669
00:38:34.119 --> 00:38:37.280
<v Speaker 3>to events. And I think living in a world where

670
00:38:37.599 --> 00:38:40.400
<v Speaker 3>there is more and more automation, that what our solution

671
00:38:40.599 --> 00:38:43.400
<v Speaker 3>is doing more and more is not necessarily the users

672
00:38:43.400 --> 00:38:47.000
<v Speaker 3>pushing the buttons anymore. So you get events from other

673
00:38:47.599 --> 00:38:52.360
<v Speaker 3>you're part of the event driven acle system kind of,

674
00:38:53.119 --> 00:38:56.000
<v Speaker 3>and you need to react to those events. For us

675
00:38:56.679 --> 00:38:59.920
<v Speaker 3>that is working related to the traders, the trades execute

676
00:39:00.280 --> 00:39:04.760
<v Speaker 3>or the strategy started. Everything needs to react to each other.

677
00:39:05.480 --> 00:39:09.119
<v Speaker 3>And these reactors is also the only one that where

678
00:39:09.119 --> 00:39:14.119
<v Speaker 3>we isolate any side effects calling off APIs and all

679
00:39:14.159 --> 00:39:18.639
<v Speaker 3>those or sending outside events, so other solutions should react

680
00:39:18.679 --> 00:39:21.599
<v Speaker 3>to that is part of the reactors.

681
00:39:21.679 --> 00:39:23.880
<v Speaker 2>Sure, and the users are one source of events, but

682
00:39:24.199 --> 00:39:26.159
<v Speaker 2>I mean you've said a couple of times trading and

683
00:39:26.280 --> 00:39:31.480
<v Speaker 2>equinors here in the petroleum business, so you're dealing with production,

684
00:39:31.719 --> 00:39:34.800
<v Speaker 2>you're dealing with refinement and we're dealing with commodities markets,

685
00:39:34.840 --> 00:39:38.639
<v Speaker 2>so you have a lot of disparate sources of events.

686
00:39:39.280 --> 00:39:43.039
<v Speaker 3>Yeah, and I think there's a lot of areas out

687
00:39:43.039 --> 00:39:46.400
<v Speaker 3>there where there are a lot of events. And when

688
00:39:46.440 --> 00:39:49.719
<v Speaker 3>we do automation, we need to identify those events because

689
00:39:49.760 --> 00:39:53.480
<v Speaker 3>we need to know when should other solutions do something

690
00:39:53.559 --> 00:39:57.320
<v Speaker 3>when something has happened in the one solution. And so

691
00:39:57.440 --> 00:40:02.400
<v Speaker 3>for us, it's a lot of different events. And the

692
00:40:02.440 --> 00:40:05.440
<v Speaker 3>application I'm working with now is more like the traders

693
00:40:05.440 --> 00:40:08.960
<v Speaker 3>for the gas traders, and yeah, they have products, so

694
00:40:09.320 --> 00:40:12.000
<v Speaker 3>they and there is a lot of events when you

695
00:40:12.079 --> 00:40:14.800
<v Speaker 3>are on an exchange, even if it was money.

696
00:40:14.800 --> 00:40:17.880
<v Speaker 2>Training you has been let's say important.

697
00:40:18.679 --> 00:40:24.519
<v Speaker 3>Yes, that's true. And so that is the third building block,

698
00:40:24.679 --> 00:40:28.239
<v Speaker 3>and the fourth one is just this event store. And

699
00:40:28.400 --> 00:40:31.599
<v Speaker 3>I think some of the secret of actually not making

700
00:40:31.679 --> 00:40:35.360
<v Speaker 3>our applications too complex because you could say, okay, before

701
00:40:35.519 --> 00:40:38.280
<v Speaker 3>I only had one building bock. It was so much easier.

702
00:40:38.360 --> 00:40:42.480
<v Speaker 3>I don't need the reactor or the command and the remodels.

703
00:40:43.320 --> 00:40:48.159
<v Speaker 3>But then again they tend to be very complex. Now

704
00:40:48.199 --> 00:40:51.639
<v Speaker 3>we can divide where we put different business rules. For instance,

705
00:40:51.679 --> 00:40:55.079
<v Speaker 3>if you have heavy calculation, if you have calculation like

706
00:40:55.440 --> 00:40:59.920
<v Speaker 3>you should use that number of digit after in the calculation,

707
00:41:00.239 --> 00:41:04.480
<v Speaker 3>or if you use this factor to go from energy

708
00:41:04.519 --> 00:41:07.199
<v Speaker 3>to volume and all those things. You can do that

709
00:41:07.440 --> 00:41:10.079
<v Speaker 3>just in the real models because it's not part of

710
00:41:10.119 --> 00:41:14.800
<v Speaker 3>the force events. So you can place the business rules

711
00:41:14.840 --> 00:41:18.400
<v Speaker 3>in the different part of the different building blocks. And

712
00:41:18.599 --> 00:41:21.360
<v Speaker 3>I think the clue of it all is to make

713
00:41:22.119 --> 00:41:26.760
<v Speaker 3>application because event sourcing is a bit complex. So it's

714
00:41:26.800 --> 00:41:29.519
<v Speaker 3>a complex our infant and there is no way around it.

715
00:41:29.559 --> 00:41:32.039
<v Speaker 3>But you have to make sure it's a complex arrangement

716
00:41:32.239 --> 00:41:36.239
<v Speaker 3>of small parts so each part is not growing. And

717
00:41:36.280 --> 00:41:39.639
<v Speaker 3>I think we at least us that I work in

718
00:41:39.639 --> 00:41:42.519
<v Speaker 3>the IT area for years and years, we have been

719
00:41:42.639 --> 00:41:47.880
<v Speaker 3>so used to build those big solutions, so we actually

720
00:41:48.440 --> 00:41:51.400
<v Speaker 3>we tend to put everything together. And I think that's

721
00:41:51.400 --> 00:41:53.760
<v Speaker 3>what we as a industry are trying to solve. And

722
00:41:53.880 --> 00:41:57.280
<v Speaker 3>we want it more distributed. We want to split things

723
00:41:57.360 --> 00:41:59.440
<v Speaker 3>up so we can change them and so on. So

724
00:41:59.559 --> 00:42:02.480
<v Speaker 3>here to we have to keep eye on the different

725
00:42:02.519 --> 00:42:03.199
<v Speaker 3>building box.

726
00:42:03.559 --> 00:42:08.280
<v Speaker 2>Sure you don't not every app makes sense for event sourcing,

727
00:42:08.360 --> 00:42:14.079
<v Speaker 2>but you have a complex multi event problem. Other techniques

728
00:42:14.119 --> 00:42:17.239
<v Speaker 2>could be applied, but they may have more residency problems,

729
00:42:17.239 --> 00:42:20.559
<v Speaker 2>like you might have more problems maintaining that there's something

730
00:42:20.599 --> 00:42:24.239
<v Speaker 2>about the architecture of event sourcing that tolerates adding new

731
00:42:24.239 --> 00:42:28.000
<v Speaker 2>event feeds really well, adding new reactions to it to

732
00:42:28.039 --> 00:42:34.239
<v Speaker 2>those event feeds, well, that's very tolerant to content diversity.

733
00:42:34.800 --> 00:42:36.800
<v Speaker 2>More and more things can come at it and it

734
00:42:36.880 --> 00:42:40.639
<v Speaker 2>doesn't get in the n over n mindus. One problem

735
00:42:40.719 --> 00:42:44.199
<v Speaker 2>doesn't compound the problem when you add more diversity that way.

736
00:42:44.679 --> 00:42:47.920
<v Speaker 3>Yeah, and I think that's the better. The can we

737
00:42:48.000 --> 00:42:52.360
<v Speaker 3>get to a place where adding new stuff isn't becoming

738
00:42:52.440 --> 00:42:57.760
<v Speaker 3>harder and harder, right because it's the smaller that the software,

739
00:42:58.639 --> 00:43:02.320
<v Speaker 3>And of course we can't stop believe that we we

740
00:43:02.400 --> 00:43:04.119
<v Speaker 3>get there some day, so we have to try. But

741
00:43:04.199 --> 00:43:06.960
<v Speaker 3>at least I think it's easier for event sourcing to

742
00:43:07.480 --> 00:43:09.320
<v Speaker 3>add smaller part well.

743
00:43:09.599 --> 00:43:13.159
<v Speaker 2>And arguably if you've really done this well, it gets

744
00:43:13.199 --> 00:43:17.039
<v Speaker 2>easier because the services are already there for a lot

745
00:43:17.079 --> 00:43:19.559
<v Speaker 2>of these things. So as a new event class comes

746
00:43:19.559 --> 00:43:22.199
<v Speaker 2>in or as a new reactor is needed, you don't

747
00:43:22.199 --> 00:43:24.519
<v Speaker 2>have to build a bunch of stuff because the infrastructure

748
00:43:24.559 --> 00:43:25.320
<v Speaker 2>is already there.

749
00:43:25.760 --> 00:43:26.199
<v Speaker 3>Yeah.

750
00:43:26.400 --> 00:43:30.440
<v Speaker 2>I almost think it's a dream, But you know, all

751
00:43:30.440 --> 00:43:33.119
<v Speaker 2>we're hoping for is it doesn't get worse. It'd be

752
00:43:33.199 --> 00:43:34.400
<v Speaker 2>nice if it actually got better.

753
00:43:35.000 --> 00:43:39.400
<v Speaker 3>Yeah, And of course event sourcing isn't dissolution for everything,

754
00:43:39.719 --> 00:43:43.960
<v Speaker 3>and it's everybody said that event sourcing is not a

755
00:43:44.039 --> 00:43:48.320
<v Speaker 3>high level architecture pattern and it's not something that you choose. Okay,

756
00:43:48.400 --> 00:43:51.679
<v Speaker 3>everything that I make should be events source, or everything

757
00:43:51.719 --> 00:43:55.760
<v Speaker 3>we make in our company. It doesn't because you have

758
00:43:55.880 --> 00:43:58.800
<v Speaker 3>some simple problems that is really just a crowd problem.

759
00:43:58.840 --> 00:44:03.079
<v Speaker 3>It's just updates in some information. And the same discussion

760
00:44:03.159 --> 00:44:05.679
<v Speaker 3>we have had for domain during design for years too,

761
00:44:05.960 --> 00:44:09.880
<v Speaker 3>how complex should it be for Actually it really the

762
00:44:10.000 --> 00:44:13.679
<v Speaker 3>extra effort you put into doing ddity is something you

763
00:44:13.719 --> 00:44:17.199
<v Speaker 3>should do. So but as I said, I've been working

764
00:44:17.280 --> 00:44:21.760
<v Speaker 3>mainly with complex business application and there it makes sense

765
00:44:22.000 --> 00:44:24.440
<v Speaker 3>for some of the problems we solve. And then what

766
00:44:24.559 --> 00:44:28.119
<v Speaker 3>I'm working on now, I sometimes just thinking how should

767
00:44:28.159 --> 00:44:31.039
<v Speaker 3>I solve this if I haven't had events sourcing, And

768
00:44:31.159 --> 00:44:36.320
<v Speaker 3>that feels like, okay, we have gotten a good pattern

769
00:44:36.519 --> 00:44:40.360
<v Speaker 3>just for this hour problem space. But of course each

770
00:44:40.480 --> 00:44:44.159
<v Speaker 3>problem space is different and that's always the starting point

771
00:44:44.559 --> 00:44:46.000
<v Speaker 3>understanding what you are solving.

772
00:44:46.199 --> 00:44:48.800
<v Speaker 2>Yeah, yeah, well, and it makes me wonder can you

773
00:44:49.199 --> 00:44:52.320
<v Speaker 2>decide this ahead of time? Do you know enough or

774
00:44:52.360 --> 00:44:55.159
<v Speaker 2>do you have to make the wrong thing first, like

775
00:44:55.199 --> 00:44:57.440
<v Speaker 2>do you have to start down a path building something

776
00:44:57.599 --> 00:45:00.800
<v Speaker 2>addressing Some ask this, they realize, well, this is going

777
00:45:00.840 --> 00:45:04.559
<v Speaker 2>to be a problem. We need to re architect into

778
00:45:04.599 --> 00:45:07.079
<v Speaker 2>an event source model. I would think the answer is

779
00:45:07.159 --> 00:45:10.039
<v Speaker 2>read the book first. Only if you know you have

780
00:45:10.079 --> 00:45:10.559
<v Speaker 2>the problem.

781
00:45:11.360 --> 00:45:13.920
<v Speaker 1>Well you might not know. Yeah, maybe I would think

782
00:45:13.960 --> 00:45:17.199
<v Speaker 1>that the first thing is look up what event sourcing

783
00:45:17.400 --> 00:45:21.159
<v Speaker 1>is and then consider how you're going to be accessing

784
00:45:21.239 --> 00:45:24.960
<v Speaker 1>data and and you know, make the decision because it

785
00:45:25.000 --> 00:45:27.000
<v Speaker 1>can you You're right, it can't apply everywhere.

786
00:45:27.519 --> 00:45:30.360
<v Speaker 3>Yeah, And that's why when I have the talk ahead

787
00:45:30.360 --> 00:45:33.480
<v Speaker 3>at end the see, I try to focus on what

788
00:45:33.639 --> 00:45:35.519
<v Speaker 3>is the good part and what is the hard part?

789
00:45:35.760 --> 00:45:39.880
<v Speaker 3>Because you can't tell people when you should use it

790
00:45:39.920 --> 00:45:42.840
<v Speaker 3>based on business domains or so on. But I try

791
00:45:42.920 --> 00:45:46.800
<v Speaker 3>to figure to line out this is really nice with

792
00:45:46.920 --> 00:45:51.000
<v Speaker 3>event sourcing, and this is quite make it harder when

793
00:45:51.000 --> 00:45:54.360
<v Speaker 3>you do event sourcing. And then I think each team

794
00:45:54.480 --> 00:45:57.400
<v Speaker 3>need to think about a problem they are solving, and see,

795
00:45:57.719 --> 00:46:00.679
<v Speaker 3>do you think that the benefits are better than the pain,

796
00:46:00.840 --> 00:46:04.400
<v Speaker 3>But of course you might. For instance, the first product

797
00:46:04.480 --> 00:46:07.880
<v Speaker 3>where I used it, we had this event sourcing is

798
00:46:07.920 --> 00:46:11.800
<v Speaker 3>really known for being a time machine. We can't travel

799
00:46:11.840 --> 00:46:15.239
<v Speaker 3>into the future, but we can travel back. And our

800
00:46:15.280 --> 00:46:18.039
<v Speaker 3>youser told us they had some autitudes on the fabric

801
00:46:18.159 --> 00:46:20.400
<v Speaker 3>that they needed to keep track of, and I said,

802
00:46:21.079 --> 00:46:24.079
<v Speaker 3>we would like in the future to know which of

803
00:46:24.119 --> 00:46:27.920
<v Speaker 3>these outages did we know about three months before they happened,

804
00:46:28.480 --> 00:46:31.800
<v Speaker 3>And event sourcing is kind of the really really good

805
00:46:31.840 --> 00:46:35.360
<v Speaker 3>fit for that. So it was one of our motivations

806
00:46:35.360 --> 00:46:38.239
<v Speaker 3>for picking that pattern. And then it turns out we

807
00:46:38.320 --> 00:46:41.760
<v Speaker 3>didn't get to that part when they needed that information.

808
00:46:42.000 --> 00:46:45.360
<v Speaker 3>So yeah, sometimes you have to might be changed. But

809
00:46:45.440 --> 00:46:47.920
<v Speaker 3>I think focusing on a good and a hard part

810
00:46:47.960 --> 00:46:51.960
<v Speaker 3>to understanding how are it different, and then each team

811
00:46:52.039 --> 00:46:54.960
<v Speaker 3>need to think about, okay, here we see that we

812
00:46:55.039 --> 00:46:59.320
<v Speaker 3>can solve a lot of things that event sourcing has

813
00:46:59.440 --> 00:47:03.039
<v Speaker 3>the good spot, and then it might be a good

814
00:47:03.360 --> 00:47:06.920
<v Speaker 3>time of using it. And one of the main pain

815
00:47:07.000 --> 00:47:10.960
<v Speaker 3>point is actually the mindset is different from what people

816
00:47:11.000 --> 00:47:14.159
<v Speaker 3>are used to. But I guess in it industry we

817
00:47:14.199 --> 00:47:17.400
<v Speaker 3>are used to needing to change over mindset and learn

818
00:47:17.440 --> 00:47:21.880
<v Speaker 3>new stuff all the time, So you have to have

819
00:47:21.920 --> 00:47:25.639
<v Speaker 3>a team that embraced that part to think differently.

820
00:47:25.880 --> 00:47:29.679
<v Speaker 1>Sure, you reminded me of when you said, you know,

821
00:47:29.760 --> 00:47:31.960
<v Speaker 1>we how do how would we know three months ahead

822
00:47:31.960 --> 00:47:34.199
<v Speaker 1>of time when we look at the event sources. Is

823
00:47:34.239 --> 00:47:38.280
<v Speaker 1>there room for predictive analytics and other AI to look

824
00:47:38.320 --> 00:47:43.800
<v Speaker 1>at the event source data and maybe notify us when

825
00:47:43.800 --> 00:47:45.079
<v Speaker 1>they see patterns coming.

826
00:47:45.360 --> 00:47:47.880
<v Speaker 3>We haven't been playing in that area, but yeah, I

827
00:47:47.920 --> 00:47:51.440
<v Speaker 3>think so. I think you know, as I said, I

828
00:47:51.559 --> 00:47:55.519
<v Speaker 3>use this schlogan of architecting for tomorrow questions because you

829
00:47:55.639 --> 00:47:59.280
<v Speaker 3>have those events and you can do analytics on them,

830
00:47:59.639 --> 00:48:03.719
<v Speaker 3>and you don't need to know ahead of time, Actually

831
00:48:03.760 --> 00:48:07.159
<v Speaker 3>what information do we need because they're only thinking what

832
00:48:07.199 --> 00:48:11.000
<v Speaker 3>are happening in the business and the critical information related

833
00:48:11.000 --> 00:48:14.800
<v Speaker 3>to that event a bit independent if it's useful or not,

834
00:48:15.679 --> 00:48:17.079
<v Speaker 3>because one day it will be.

835
00:48:17.280 --> 00:48:19.840
<v Speaker 1>You also have to you also have to put in

836
00:48:19.519 --> 00:48:25.320
<v Speaker 1>the event source catastrophic failure if you're going to try

837
00:48:25.360 --> 00:48:26.599
<v Speaker 1>to prevent it in the future.

838
00:48:27.639 --> 00:48:30.000
<v Speaker 2>About I mean, this is going to be more data intensive,

839
00:48:30.039 --> 00:48:32.159
<v Speaker 2>but goodness knows, we have enough storage base like that.

840
00:48:32.599 --> 00:48:34.280
<v Speaker 2>Once upon a time, we were really careful about how

841
00:48:34.320 --> 00:48:36.159
<v Speaker 2>much data we stored it, so we tended to stare

842
00:48:36.199 --> 00:48:38.760
<v Speaker 2>of the agree because it costs less. That's not the

843
00:48:38.800 --> 00:48:41.760
<v Speaker 2>issue anymore. Now. The issue is we don't know why

844
00:48:41.800 --> 00:48:44.599
<v Speaker 2>we did what we did. Last year because we only

845
00:48:44.599 --> 00:48:46.679
<v Speaker 2>have the aggregate data, not the whole chain.

846
00:48:47.280 --> 00:48:51.679
<v Speaker 3>Yeah. I actually had a very interesting discussion with Alberto

847
00:48:51.760 --> 00:48:55.199
<v Speaker 3>Brandolini at the explore Ddity conference when he was talking

848
00:48:55.360 --> 00:48:59.159
<v Speaker 3>that sometimes, if I understood it correctly, I sometimes see

849
00:48:59.280 --> 00:49:02.280
<v Speaker 3>that issues you try to solve, for instance, in the

850
00:49:02.360 --> 00:49:06.280
<v Speaker 3>data warehouse could have been kind of easily extracted if

851
00:49:06.320 --> 00:49:08.840
<v Speaker 3>you have the events, because I think when you get

852
00:49:08.960 --> 00:49:12.000
<v Speaker 3>to on the other side, you try to do the analytics.

853
00:49:12.639 --> 00:49:15.519
<v Speaker 3>As I said, even in our solution back in time,

854
00:49:15.519 --> 00:49:18.559
<v Speaker 3>we put all this flag because I think we need

855
00:49:18.599 --> 00:49:22.000
<v Speaker 3>to know what have happened and why, and before we

856
00:49:22.079 --> 00:49:26.840
<v Speaker 3>only had this data, so we do different things just

857
00:49:26.920 --> 00:49:30.840
<v Speaker 3>to try to analyze it to understand what did happen

858
00:49:30.880 --> 00:49:33.960
<v Speaker 3>in the business. And this gives you that as the

859
00:49:33.960 --> 00:49:37.800
<v Speaker 3>core part of your information. So I really believe that

860
00:49:38.159 --> 00:49:41.360
<v Speaker 3>as organizations get more and more data driven and more

861
00:49:41.519 --> 00:49:44.800
<v Speaker 3>part are looking at the data, that it's easier to

862
00:49:44.920 --> 00:49:48.039
<v Speaker 3>compare because you have fitted in a context already.

863
00:49:48.679 --> 00:49:51.599
<v Speaker 2>Yeah, and the sort of modern data analytics model now

864
00:49:51.599 --> 00:49:54.679
<v Speaker 2>where you have the quote unquote data lake rather than

865
00:49:54.679 --> 00:49:58.920
<v Speaker 2>a warehouse, you're literally just dropping those blocks of events

866
00:49:59.480 --> 00:50:02.719
<v Speaker 2>up into the lake for analytical tools to be able

867
00:50:02.760 --> 00:50:05.239
<v Speaker 2>to have access to the truth rather than they aggregate.

868
00:50:05.480 --> 00:50:08.960
<v Speaker 3>Yeah, I know. We also try to at least an

869
00:50:08.960 --> 00:50:12.960
<v Speaker 3>equino to embrace this Tata mesh concepts. So instead of

870
00:50:13.000 --> 00:50:15.960
<v Speaker 3>having one big lake that every events are swimming in,

871
00:50:16.400 --> 00:50:19.440
<v Speaker 3>you have it into a mesh. That is I call

872
00:50:19.519 --> 00:50:22.679
<v Speaker 3>it to manduin the sign for a data because you

873
00:50:22.840 --> 00:50:28.000
<v Speaker 3>try to make a domain around your collective data that

874
00:50:28.039 --> 00:50:32.840
<v Speaker 3>you before put just in aware else because that will

875
00:50:32.880 --> 00:50:35.000
<v Speaker 3>also give you more context. And I think that's the

876
00:50:35.079 --> 00:50:39.159
<v Speaker 3>hard part with data without context? What is it actually?

877
00:50:39.480 --> 00:50:40.519
<v Speaker 3>That is hard to say.

878
00:50:40.960 --> 00:50:43.639
<v Speaker 2>The challenge with the mesh is the intersection points right

879
00:50:44.159 --> 00:50:48.440
<v Speaker 2>each If each different set of applications has its own customer,

880
00:50:48.519 --> 00:50:51.239
<v Speaker 2>how do we have a unified customer. Yeah, but those

881
00:50:51.280 --> 00:50:53.840
<v Speaker 2>are good problems to tackle, it is, and.

882
00:50:53.800 --> 00:50:56.880
<v Speaker 3>I guess that's the challenge of the distributed application too.

883
00:50:57.400 --> 00:50:59.960
<v Speaker 3>When we put things, it's hard to put it together.

884
00:51:00.559 --> 00:51:04.480
<v Speaker 3>When everything is together, it's really really hard just to

885
00:51:04.639 --> 00:51:07.920
<v Speaker 3>move it anyway. Balance.

886
00:51:08.079 --> 00:51:10.639
<v Speaker 2>Yeah, the monolith is in the answer to everything, and

887
00:51:10.639 --> 00:51:12.880
<v Speaker 2>the distributed system is the answer to everything. So there's

888
00:51:12.880 --> 00:51:15.079
<v Speaker 2>always going to be seams, Yeah, where we're going to

889
00:51:15.119 --> 00:51:16.840
<v Speaker 2>have to figure out where that how to battle with

890
00:51:16.880 --> 00:51:17.920
<v Speaker 2>those particularly.

891
00:51:17.760 --> 00:51:20.320
<v Speaker 1>Common topic we've been discussing here for the last year

892
00:51:20.440 --> 00:51:24.719
<v Speaker 1>or so. During two years, yeah, two years, good lord, at.

893
00:51:24.679 --> 00:51:29.039
<v Speaker 2>Least dely longer, just because the sort of the reality

894
00:51:29.079 --> 00:51:30.639
<v Speaker 2>of we're now at a place where we have as

895
00:51:30.719 --> 00:51:35.440
<v Speaker 2>much compute, as much uh storage as we want, so

896
00:51:35.679 --> 00:51:38.159
<v Speaker 2>now you're sort of designing for the optimal. Maybe it's

897
00:51:38.159 --> 00:51:40.360
<v Speaker 2>a cost control thing, but it's most Most of the

898
00:51:40.400 --> 00:51:43.159
<v Speaker 2>cost controls are about maintaining software, being able to do

899
00:51:43.199 --> 00:51:46.719
<v Speaker 2>the new versions quickly, being able to respond to business opportunities,

900
00:51:47.320 --> 00:51:51.840
<v Speaker 2>and so you architectures are hard. There isn't a right way.

901
00:51:51.840 --> 00:51:54.039
<v Speaker 2>If there was, we'd all be doing it right. You

902
00:51:54.039 --> 00:51:56.199
<v Speaker 2>can buy it at seven eleven. If it was easy.

903
00:51:56.800 --> 00:51:59.960
<v Speaker 3>I heard someone saying that, look at all the conference

904
00:52:00.199 --> 00:52:04.960
<v Speaker 3>is out there on it. If it was easy, why

905
00:52:04.960 --> 00:52:07.320
<v Speaker 3>should we have them. It's because we need to learn

906
00:52:07.400 --> 00:52:11.239
<v Speaker 3>from each other to solve those problems, because everything depends.

907
00:52:11.599 --> 00:52:14.639
<v Speaker 3>So you need to learn enough to really be able

908
00:52:14.760 --> 00:52:18.280
<v Speaker 3>to think about how is how should we do it?

909
00:52:18.320 --> 00:52:19.320
<v Speaker 3>In our context?

910
00:52:19.920 --> 00:52:23.639
<v Speaker 1>So what's next for you? Anita? Speaking anywhere? Writing some

911
00:52:23.679 --> 00:52:25.559
<v Speaker 1>more stuff? What are you what are you working on?

912
00:52:25.599 --> 00:52:27.360
<v Speaker 1>What's in your inbox? Yeah?

913
00:52:27.400 --> 00:52:32.000
<v Speaker 3>Well we'll go to London to the jacks y X

914
00:52:32.360 --> 00:52:36.360
<v Speaker 3>London conference. That's the next one. That's the only one

915
00:52:36.400 --> 00:52:39.920
<v Speaker 3>I know for now. But I also are preparing thinking

916
00:52:39.960 --> 00:52:44.719
<v Speaker 3>about talks for both explore d d D and ddity Europe,

917
00:52:44.920 --> 00:52:48.320
<v Speaker 3>just because I think those conferences is I learned so

918
00:52:48.400 --> 00:52:51.239
<v Speaker 3>much every time I go there, and I really want

919
00:52:51.280 --> 00:52:54.920
<v Speaker 3>to to both learn from others and share what I

920
00:52:55.000 --> 00:53:00.280
<v Speaker 3>have learned by working as hands on every day. So

921
00:53:00.920 --> 00:53:05.039
<v Speaker 3>the main part it's to make this application that we

922
00:53:05.079 --> 00:53:08.360
<v Speaker 3>are working on for the traders better and better and

923
00:53:08.480 --> 00:53:12.159
<v Speaker 3>more and more functionality every day together in the team.

924
00:53:12.320 --> 00:53:14.880
<v Speaker 3>It's really enjoy working in the.

925
00:53:14.960 --> 00:53:18.480
<v Speaker 1>Team fantastic, you know I before we go, I really

926
00:53:18.480 --> 00:53:22.639
<v Speaker 1>appreciate just a plain English way that you explain these things.

927
00:53:22.840 --> 00:53:26.400
<v Speaker 1>It's great. I thank you, and I really appreciate your

928
00:53:26.559 --> 00:53:31.239
<v Speaker 1>approach to events, sourcing and DDD and on all of it.

929
00:53:31.239 --> 00:53:33.840
<v Speaker 1>It's great. So thank you very much for joining us

930
00:53:33.880 --> 00:53:34.280
<v Speaker 1>this hour.

931
00:53:34.880 --> 00:53:38.199
<v Speaker 3>Thank you so much for having me. Have a nice evening, all.

932
00:53:38.159 --> 00:53:41.000
<v Speaker 1>Right, and we'll talk to you next time on dot

933
00:53:41.079 --> 00:54:04.320
<v Speaker 1>net rocks. Dot net Rocks is brought to you by

934
00:54:04.400 --> 00:54:09.079
<v Speaker 1>Franklin's Net and produced by Pop Studios, a full service audio,

935
00:54:09.199 --> 00:54:13.639
<v Speaker 1>video and post production facility. Located physically in New London, Connecticut,

936
00:54:13.880 --> 00:54:18.679
<v Speaker 1>and of course in the cloud online at pwop dot com.

937
00:54:18.880 --> 00:54:21.000
<v Speaker 1>Visit our website at d O T N E t

938
00:54:21.239 --> 00:54:25.280
<v Speaker 1>R O c k S dot com for RSS feeds, downloads,

939
00:54:25.400 --> 00:54:29.079
<v Speaker 1>mobile apps, comments, and access to the full archives going

940
00:54:29.119 --> 00:54:32.519
<v Speaker 1>back to show number one, recorded in September two thousand

941
00:54:32.559 --> 00:54:35.199
<v Speaker 1>and two. And make sure you check out our sponsors.

942
00:54:35.360 --> 00:54:38.400
<v Speaker 1>They keep us in business. Now go write some code,

943
00:54:38.719 --> 00:54:46.000
<v Speaker 1>See you next time. You got jam vanst