Speaker 1: How'd you like to listen to dot NetRocks with no ads? Easy?
Speaker 1: Become a patron For just five dollars a month, you
Speaker 1: get access to a private RSS feed where all the
Speaker 1: shows have no ads. Twenty dollars a month will get
Speaker 1: you that and a special dot NetRocks patron mug. Sign
Speaker 1: up now at Patreon dot dot NetRocks dot com.
Speaker 2: Hey Carl and Richard here with your twenty twenty four
Speaker 2: NDC schedule.
Speaker 1: We'll be at as many NDC conferences as possible this year,
Speaker 1: and you should consider attending no matter what. The Copenhagen
Speaker 1: Developers Festival happens August twenty sixth through the thirtieth. Tickets
Speaker 1: at Cphdevfest dot com.
Speaker 2: Ndcporto is happening October fourteenth through the eighteenth. Tickets at
Speaker 2: Ndcporto dot com.
Speaker 1: We'll see you there, we hope. Hey, guess what it's
Speaker 1: dot net rocks. I'm Carl Franklin and I'm Richard Campbell.
Speaker 1: We're here again. Yes, you can't get rid of us.
Speaker 1: It's still the summertime too, so we've been at home
Speaker 1: for a while. Yeah. I had a sad weekend. I
Speaker 1: went to a funeral of my cousin who was three
Speaker 1: years younger than me, and it was too soon for her.
Speaker 1: But cancer sucks.
Speaker 2: Yeah, no, I know what you mean. Man, it's reality.
Speaker 2: We're living with her now older than friends of ours
Speaker 2: that we're losing.
Speaker 1: However, I did get a chance to visit with the
Speaker 1: other Franklins in the family, and they're a stoic bunch. Man.
Speaker 1: There was nary a tear, even though they felt the
Speaker 1: loss deeply. It was very strange. Anyway, I won't go
Speaker 1: into that. How are you.
Speaker 2: I'm good, you know, with the summer winding down, getting
Speaker 2: ready to go to Copenhagen Developers Festival in the near
Speaker 2: future here, and that'll be the first trip since June.
Speaker 2: So it's been a good couple of months on the
Speaker 2: coast and you know it's nice up here.
Speaker 1: Yeah, that's right.
Speaker 2: And I've been smoking a lot of salmon and ribs
Speaker 2: and you know that kind of thing.
Speaker 1: Is that good for your lungs? I'm not smoke smoking salmon.
Speaker 2: Yeah, but plus it's really hard to keep it lit.
Speaker 1: Yeah. All right, Well let's jump into the way we
Speaker 1: start the show with better not a framework?
Speaker 2: Awesome, man, what do you got? Well?
Speaker 1: This started out of course, is a way that I
Speaker 1: could poke, uh, you know, a little dive into little
Speaker 1: parts of the framework, the dot net framework back when
Speaker 1: it was a Windows framework, and then it just sort
Speaker 1: of evolved to Carl says something something somebody once said
Speaker 1: this is Carl does a Google search five minutes before
Speaker 1: the show. But today we have something different and it
Speaker 1: involves you, mister Campbell. So it's about dev Intersection, So
Speaker 1: tell me what's going on.
Speaker 2: So we've got a side by shote show, as we
Speaker 2: like to do in at dev Intersection. We're going side
Speaker 2: byside with a new show, or at least a new name,
Speaker 2: which is the Next Gen Ai Show. So this is
Speaker 2: at the MGMGEN in Las Vegas from the tenth to
Speaker 2: the twelfth of September, so coming up right away, right
Speaker 2: and we've got a special offer putting on we call
Speaker 2: the Bogo offer. You buy one get one free.
Speaker 1: That's right. So if you haven't registered yet and you
Speaker 1: want to go and you want to get a free ticket,
Speaker 1: what you do is you use the code gen Ai
Speaker 1: bogo g E n AI b O g O discount
Speaker 1: code when you're registering at either next gen ai com
Speaker 1: for dev Intersection dot com and with a full price registration,
Speaker 1: you'll receive an email confirmation which will include a unique
Speaker 1: discount code for a free second registration to pass on
Speaker 1: to an additional attendee. Right, so there you go. It's
Speaker 1: buy one, get one free.
Speaker 2: And by the way, you can registered to either show,
Speaker 2: it doesn't matter which, and you have access to everything.
Speaker 2: We just we tend to do, you know, the marketing
Speaker 2: towards the Microsoft community, Visual Studio C Shop on the
Speaker 2: internest the radiosexual side, and the marketing towards the AI
Speaker 2: community on the next gen AI side, but we want those,
Speaker 2: you know, we call it intersection for reason. It's a
Speaker 2: crossing over of different interest areas, and so that's why
Speaker 2: we have the two names and the two websites, but
Speaker 2: it's all the same show.
Speaker 1: That's great. So that's what I got. Who's talking to
Speaker 1: us today, Richard?
Speaker 2: Awesome dude. And speaking of AI stuff, I grabbed a
Speaker 2: comment of Show eighteen ninety four, which you did back
Speaker 2: in April of this year with Carl Getz. We were
Speaker 2: talking about programming with speech in AI, and this particular
Speaker 2: comment comes from SD Penner who said, I thought this
Speaker 2: was great. This opened my eyes to new ways of
Speaker 2: working with visual Studio, because that's the problem with visual Studio,
Speaker 2: like everything's in there, you just can't find it, right,
Speaker 2: Like there's so many tools. Oddly enough, or maybe suspiciously,
Speaker 2: this recent code rush video came across my feed where
Speaker 2: they talked about supporting voice commands that we're mentioned in
Speaker 2: a podcast on dot net rocks because we've already done this, right, Yeah,
Speaker 2: talk to Mark Miller will He was playing with the
Speaker 2: idea as well. So you're right, there's an exploration of
Speaker 2: tooling right now.
Speaker 3: Yeah.
Speaker 2: I think a general pressure against the user interface to
Speaker 2: just include sort of that chat mechanism and or voice
Speaker 2: mechanism with it in a way to describe your goals,
Speaker 2: describe your ideas, and use large language models to pull
Speaker 2: value from it to save you some time.
Speaker 1: So, and it's really getting good, Like voice commands have
Speaker 1: always been around.
Speaker 2: Yeah, it's just dragon naturally speaking in the eighties for
Speaker 2: god's sake.
Speaker 1: That's right, where you trained your parrot to turn the
Speaker 1: lights on and off.
Speaker 2: But don't do that.
Speaker 1: I do not, But anyway, Yeah, so it's getting really
Speaker 1: good in just about every interface that I have. I
Speaker 1: use it to I use a speech to talk to
Speaker 1: chat GPT on my phone. Hm, I use speech in
Speaker 1: my car. We'll talk about that next show. Sure, I
Speaker 1: use I don't use speech at the PC though, but yeah,
Speaker 1: but yeah, I'm getting toward it because yeah, just mousing around, Yeah,
Speaker 1: it gets tiring.
Speaker 2: I didn't even think about the fact that today, when
Speaker 2: I walk into my office to record a show, I
Speaker 2: do command Home Assistant via voice to switch to video mode,
Speaker 2: which switches the computer around, turns on the lights, like
Speaker 2: configures everything to get ready to record. That's really cool,
Speaker 2: normal workflow. And then when it's done, tell okay, go
Speaker 2: back to normal and it switches everything backed off again.
Speaker 2: So yeah, it's happening. So as do you? Thank you
Speaker 2: so much for your comment. Copy of music Cobey is
Speaker 2: on its way to you. And if you'd like a
Speaker 2: copy of music Gobe, I write a comment on the
Speaker 2: website at dot at Rocks dot com or on the facebooks.
Speaker 2: We publish every show there, and if you comment there
Speaker 2: in a really we'll send you copy of music go by.
Speaker 1: Music to code by still very popular option for developers
Speaker 1: who want help getting into the zone. And yeah, we'll
Speaker 1: send you a free one if like what just happened
Speaker 1: right here, somebody's getting a free music yestaed by Yeah, okay,
Speaker 1: let me introduce our guest today. Anita Kavama is a
Speaker 1: hands on software architect with more than twenty five years
Speaker 1: of experience from building business solutions. In the late nineties,
Speaker 1: she advocated for the importance of UX before it was
Speaker 1: accepted as important by the software community. Today, Anita feels
Speaker 1: at home in the domain driven Design community, where she's
Speaker 1: been a frequent speaker the last years. Currently, she has
Speaker 1: a great time as a coding software architect at Equanor
Speaker 1: in a team delivering custom business solutions to the in
Speaker 1: house trading desk. Welcome Anita, Thank you, yes, thank you.
Speaker 1: You have Have you heard the show before?
Speaker 3: Oh yeah, many many time.
Speaker 2: Oh goodness, Oh great.
Speaker 1: Should be a k quak for you.
Speaker 2: And I originally twigged on the talk you were doing
Speaker 2: it in DC. I was all about event sourcing. But
Speaker 2: I Equinor is a big company and if DDD is
Speaker 2: a playing a role in there, I'd love to hear
Speaker 2: a bit of the story of what you what you're doing,
Speaker 2: about how our organization like that approaches software development.
Speaker 3: Yeah, actually, when d d D and the book Eric
Speaker 3: Evans's book came out Eclinor engaged in this and invited
Speaker 3: him over here in Norway to visit us to tell
Speaker 3: more about what is d d D and also to
Speaker 3: engage with some of our teams. And of course that's
Speaker 3: a long long time ago. It was around I wasn't
Speaker 3: coding much on that at the times. I was just
Speaker 3: partly part of that as a consultant and equinor. But
Speaker 3: he came over and it was a lot of you know,
Speaker 3: groups and a community building inside Ecuinor for actually doing
Speaker 3: the main dream in design. And then I think we
Speaker 3: still are a bunch of people doing this and h
Speaker 3: really engaged in the community. But there is also of
Speaker 3: course teams that are not doing the main driven design.
Speaker 3: But for me, I call myself a d d D lower.
Speaker 3: I think I've seen the power for some of the
Speaker 3: tip of application we are doing where is highly complicated
Speaker 3: business application. I think the main driven design has a
Speaker 3: big role. And really the d d D community is
Speaker 3: so open and so warm and I have learned so
Speaker 3: much from that. But I think that we really from
Speaker 3: the start had to buying from some management, actually getting
Speaker 3: d Garrick evans Or to our to our campus and
Speaker 3: helping us out. I think was a great start, because
Speaker 3: yet then you don't you can use your energy in
Speaker 3: understanding and doing things that it is and easy. It's
Speaker 3: always related to building hard solutions too, so you have
Speaker 3: to focus. And if you use all your focus just
Speaker 3: to convince the management and other around you that this
Speaker 3: is something you to do, then you lose the focus
Speaker 3: of actually doing the good work interesting in building the
Speaker 3: IT solutions. So having that support from the start is
Speaker 3: really really critical.
Speaker 1: I think, did you say Eric Evans has has joined
Speaker 1: you equan No.
Speaker 3: No, but we kind of hire it him as a
Speaker 3: consultant for our guests for some weeks or something.
Speaker 2: But that book is more than twenty years old now,
Speaker 2: like it's been around a while, and we interviewed him
Speaker 2: in two thousand and seven and found he's a very
Speaker 2: kind man, very very pleasant to talk to.
Speaker 3: Absolutely. I was so lucky that I was part of
Speaker 3: the Explored DDDY conference in Denver this year and there
Speaker 3: we had this Diametics cake at a speaker's dinner where
Speaker 3: Eric Ebbans was there, and it was for the twenty
Speaker 3: years since the book came out. So it was a
Speaker 3: cake with a picture of the front side of the book,
Speaker 3: and we were kind of kidding that when he take
Speaker 3: a bit, it was dividing into bond the context each got.
Speaker 1: It the cake driven or domain driven cake.
Speaker 3: Yeah.
Speaker 2: Nice, Yeah, that's great, very funny. Yeah, oh right, Well,
Speaker 2: I didn't mean to distract you much, but it's a
Speaker 2: you know, awesome story, and I appreciate your viewpoint on that.
Speaker 2: It certainly it realized like it's a career length kind
Speaker 2: of thing too.
Speaker 3: Yeah, And for me it's not a distraction because events
Speaker 3: sourcing without the main driven the sign, I really will
Speaker 3: not know how to do that. I think events sourcing
Speaker 3: gives me the toolbox that is so helpful when doing
Speaker 3: no the other way of around. Of course, the main
Speaker 3: driven the sign gives me the toolbox with the concept
Speaker 3: of aggregates the context and all that of make doing
Speaker 3: events sourcing much much easier. And I think that also
Speaker 3: grew out of that community, so that was how I
Speaker 3: was introduced to it actually, So for me it was
Speaker 3: not distraction. It was completely inside the context where I
Speaker 3: think it belongs.
Speaker 2: So why is the main drive design essential to event sourcing?
Speaker 3: Well, for me, first of all, if this what events
Speaker 3: are we focusing on, and you can do events sourcing
Speaker 3: much more technical, but all I have been part of doing.
Speaker 3: Then we focus on domain events and with all that's
Speaker 3: a fact, it's something that has happened and really important,
Speaker 3: something that the business cares about. So actually having that
Speaker 3: and also when you do events sourcing, you need to
Speaker 3: those events need to belong to something. And that's something
Speaker 3: is the concept of aggregates that I know from domain
Speaker 3: driven design. And if I haven't kind of understood that
Speaker 3: concept from before, I think it would be harder to understand.
Speaker 3: So where are these events belonging to?
Speaker 2: Right?
Speaker 3: So they need to have a place to live. So
Speaker 3: that's I guess the two main things. And of course
Speaker 3: events storming. That all back to Brandolini introduced also really
Speaker 3: a member of the dd D community where you is
Speaker 3: a brainstorming technique where you identify or all these domain
Speaker 3: events also fits perfect into this picture and helps me
Speaker 3: out on my team. We are using that heavily.
Speaker 1: When I think of event sourcing, I think of you know,
Speaker 1: like let's say you have a financial application and people
Speaker 1: are in a spreadsheet and they make a change. Rather
Speaker 1: than changing a value in a table, you add a
Speaker 1: record to a table that the value was changed from
Speaker 1: this to that with a time stamp, and who did it.
Speaker 1: I never really thought of it when you were describing
Speaker 1: what you're using for. It almost sounds more like a
Speaker 1: logging feature.
Speaker 3: Well, in that case, when you change that value, you
Speaker 3: probably have the business have something in their mind. What
Speaker 3: are they actually doing transferred to in business terms. So
Speaker 3: it's for instance, I've been working with some trading strategies
Speaker 3: and you can say we have a table with a
Speaker 3: trading strategy, but when the user start that strategy, we
Speaker 3: don't look upon that as changing the one value from
Speaker 3: stop to start, but it's a they do. They have
Speaker 3: an intention that is starting the strategy, and we get
Speaker 3: a domain event that says that the strategy is started.
Speaker 3: So it's more to actually explain in business terms those
Speaker 3: state changes and look upon. It's not the importance here
Speaker 3: just to keep track of the state changes, but really
Speaker 3: understand what is happening seen from a behavior perspective in
Speaker 3: the business. So it is I feel I've been working
Speaker 3: with some sort of design for a long time, as
Speaker 3: you said in the introduction, and also before when we
Speaker 3: did not do event sourcing, we put all these noise
Speaker 3: in our tables. Of course, we've put the versions because
Speaker 3: we need an audit. But then we added flags. We
Speaker 3: added flags that say, oh, this row is updated by
Speaker 3: a user, and do you know this user idea that
Speaker 3: I've been something that we do and I think everything
Speaker 3: we did because we wanted to know what has actually happened.
Speaker 3: We wanted that behavior we view. But all we had
Speaker 3: was this static table and actually should keep the state,
Speaker 3: but we enhanced it and put a lot of stuff
Speaker 3: into it in order to be able to detect what
Speaker 3: has actually happened. And now doing event sourcing, I can
Speaker 3: just save what did actually happen and I really find
Speaker 3: that so useful.
Speaker 2: The domain event is sort of the starting point of
Speaker 2: an event storm. What is the domain event?
Speaker 3: It is something that happened in the past, And that's
Speaker 3: really diffferent from the command because the command can fail
Speaker 3: and the command could trigger a validation error and so on.
Speaker 3: But something that has happened. Taking the same example, strategy
Speaker 3: is started is completely different from the command starting the strategy.
Speaker 3: What if the user is not allowed to do it?
Speaker 3: So this has already happened, so it's a fact, but
Speaker 3: it should also be something that the business cares about.
Speaker 3: And that's one I use as a guidance for thinking
Speaker 3: about which event should we take care of and save
Speaker 3: which how do we bundle stuff? It shouldn't be meaningful
Speaker 3: or be able to discuss with the user. And if
Speaker 3: you do this events storming, you try to put those
Speaker 3: domain events up in a myro board or a white
Speaker 3: board or whatever.
Speaker 2: As I understand, it's like it's a whiteboard, sticky note
Speaker 2: process approach.
Speaker 3: Yeah, it is, absolutely So.
Speaker 2: What's the granularity of domain event? Is it like adding
Speaker 2: something to a shopping cart or initiating a sale? Like
Speaker 2: what's they.
Speaker 3: Add item to a shopping card is a typical example
Speaker 3: of a domain event and also remove that item, and
Speaker 3: of course then you're into one other typical example of
Speaker 3: how events sourcing different from other way to building solutions,
Speaker 3: because if you only have the shopping cart and someone
Speaker 3: asks you how often they do the customer remove just
Speaker 3: this kind of shoe from my shopping card? You don't
Speaker 3: have that information. So one of the slogan for events
Speaker 3: sourcing is that you will never lose any data because
Speaker 3: you take care of those so you can answer them.
Speaker 3: I used to say, I'm architecting for tomorrow's question. You
Speaker 3: never know in a data d even organization, what do
Speaker 3: they ask tomorrow? I should ask me something new? Actually,
Speaker 3: if they if you are truly data.
Speaker 1: Driven, so I imagine that web browsing behavior and how
Speaker 1: they use the application in a web for example, which
Speaker 1: can all be tracked, right, I imagine that is going to
Speaker 1: be very interested to the Mark Zuckerbergs of the world. Interesting.
Speaker 3: Yeah, but for us, it's only those events. I mean,
Speaker 3: how you are navigating into your browser. We are not tracking.
Speaker 3: We are only tracking. Yeah you could, we could. Yeah,
Speaker 3: And of course that depends on what information What is
Speaker 3: your purpose there?
Speaker 1: Yeah?
Speaker 2: Okay, what's important to the organization?
Speaker 1: Right?
Speaker 3: Yes, it is, and also to if you have a
Speaker 3: more task based user interface in opposite to a more
Speaker 3: crowd base where you actually are thinking about what task
Speaker 3: or the user is doing, and you might have button
Speaker 3: that face start strategy instead of the just changing a
Speaker 3: column in a table from stop to start, then it's
Speaker 3: much easier. It is more aligned with doing AM and
Speaker 3: sourcing because you're already there knowing the intention behind the
Speaker 3: user because it's kind of expressing is through the functionality
Speaker 3: the task is doing in the interface, right, If that
Speaker 3: makes sense?
Speaker 2: Well, and it's something I've always noticed with domain view
Speaker 2: is that it's far more agnostic. Like crud speaks to
Speaker 2: I'm speaking to an rdbm ass. I mean, I know
Speaker 2: I can make it with other things. This idea of
Speaker 2: the customer wants to add something to the shopping cart.
Speaker 2: Everything plumbing related to that is secondary the point, right,
Speaker 2: It's like, this is what the customer wants to do.
Speaker 2: There's a ton of ways to go about it. Now
Speaker 2: we can work through those options. But more importantly, there's
Speaker 2: a series of events that occur from that desire.
Speaker 3: It is, and as long as you have that event,
Speaker 3: you can at unepoint in time later on play through
Speaker 3: those events and construct the information that you need. So
Speaker 3: you don't need to pick this is my state of
Speaker 3: my application in the start, and I think that is
Speaker 3: often very hard to do. To discuss what are a
Speaker 3: user doing in this application is such much easier to
Speaker 3: agree upon. But actually what information are they going to see?
Speaker 3: And how should we save those That is much that's
Speaker 3: question that need to when you show the users you
Speaker 3: have given them something to say what they actually want
Speaker 3: to see. So having this separated like a command, your
Speaker 3: responsibility segregation. So you have the events and then the
Speaker 3: things that really are changing all the time. What is
Speaker 3: the valuable information to show to the users? It's much
Speaker 3: easier to change, right.
Speaker 1: Would you serialize the state, the relevant state and put
Speaker 1: that in an event source record or would you prefer
Speaker 1: to calculate the state based on a history or a
Speaker 1: range of records.
Speaker 3: Yeah, I prefer to just make the state based on
Speaker 3: the history of the So it's two side here on
Speaker 3: the right side where you need to be. You need
Speaker 3: to have the exact state and we don't take any
Speaker 3: eventual consistency there. So what we do we actually source
Speaker 3: the state by looping through the events. Hence and the
Speaker 3: term events sourcing. So your events is the truth. And
Speaker 3: of course if you stream get too long, there are
Speaker 3: techniques where you can do snapshotting and so, but you
Speaker 3: do that when you have to. But for the start,
Speaker 3: you just go through source the events. You read each
Speaker 3: one event in sequence for that aggregate. And if you
Speaker 3: don't know the aggregate term for DDDY, it's more like
Speaker 3: the it's like a business entity that has both behavior
Speaker 3: and data. So you get the aggregate state by looking
Speaker 3: through the event and you just pick up the things
Speaker 3: that you need in order to be able to do
Speaker 3: the business rules on the right side.
Speaker 1: Yeah, that's a big difference from somebody who's just doing logging.
Speaker 1: Even with something like Serra log where you're taking the
Speaker 1: state of an object or a bunch of objects and
Speaker 1: putting them in a in a record, the state is sourced,
Speaker 1: as you said, events and the clue is right there
Speaker 1: in the name. Yeah.
Speaker 3: And on the red side, when you want to display information,
Speaker 3: you do have this eventual consistency because you react to
Speaker 3: those events, and you can pick events from many different
Speaker 3: streams and you build up the information you need to see.
Speaker 3: And there we the typical start out at least with
Speaker 3: just having that state in memory, because every time we
Speaker 3: restart our application, we can just start from the first
Speaker 3: event and we can spin it up and makes it
Speaker 3: also easy to change early in the process. But when
Speaker 3: a database grows and become too big, with just can
Speaker 3: then you can build a date and you can save
Speaker 3: it in whatever database you want to that is best
Speaker 3: fit for that purpose. So it's not the event store
Speaker 3: that keeps the remodels is that it could be a
Speaker 3: separate one and then if you want to change it,
Speaker 3: you can at any point just scratch it and build
Speaker 3: it off from scratch it. Just if you actually change
Speaker 3: your read model schema, you don't need to do a
Speaker 3: database migration. And that's of course something that is.
Speaker 2: Nice too, But it makes sense that you can have
Speaker 2: reconciliation points so you can say, all right, we're starting
Speaker 2: at a balance here now then stream forward, Yeah, depending
Speaker 2: on scope, and I can there plenty of streams you
Speaker 2: could last a long time, but there's also plenty where
Speaker 2: it's like, listen, you're also gonna I mean, I use
Speaker 2: the term reconciliation for a reason. From a financial perspectors,
Speaker 2: there's a point where you declare, this month is completed,
Speaker 2: here is the truth, and from then on you don't
Speaker 2: want any possibility that would change. Not that it should,
Speaker 2: but there's no reason to go re reconcile at that point.
Speaker 3: Yeah. Nice that you take that example, because usually if
Speaker 3: you try to explain event sourcing to someone from the business,
Speaker 3: you do the accounting story, because accounting has been done
Speaker 3: doing event sourcing for one hundreds of years.
Speaker 2: That's a legend.
Speaker 3: Just to release something and update, they really do it
Speaker 3: the right time way like you do event sourcing, and
Speaker 3: if there is for it, people you say, okay, that's
Speaker 3: what guitar is doing because they also take you were
Speaker 3: kicked in a new pull request, and you don't just
Speaker 3: update the state, do how the changes lead to that state?
Speaker 2: Yeah, no, you always have a journal. From a dba's perspective,
Speaker 2: you only insert, you never update, right, and that way
Speaker 2: you always have the dialogue of the truth of how
Speaker 2: things happened in sequence, even though eventually you want an
Speaker 2: aggregate of that because it gets too expensive to constantly recompute.
Speaker 3: But there is also a goal the way you're on
Speaker 3: the right side again, not on the read side, where
Speaker 3: you show the information, but you try to design your
Speaker 3: aggregate so they are not that not living forever. So
Speaker 3: that's the same ass accounting is doing. Again. So for instance,
Speaker 3: might be we are aggregates that only have the event
Speaker 3: for a stream that belongs to a day for us
Speaker 3: working with traders, and we do that a lot, so
Speaker 3: you have techniques for not making those streams so big.
Speaker 3: So when the application has run for a while, the
Speaker 3: goal kind of and this is hard. It's not always
Speaker 3: we managed to do it, but we try to make
Speaker 3: those streams so they reset themselves, just as accounting is doing.
Speaker 3: Every year.
Speaker 2: I've seen a stream system for testing materials and the
Speaker 2: data streams are very intensive, but the test runs are
Speaker 2: minutes long, so there's clearly a beginning, a run, and
Speaker 2: an end and then you can look at them from
Speaker 2: an aggrid perspective. But in that time, they're taking measurements
Speaker 2: multiple times per second. Like it can be a ton
Speaker 2: of data, but at least it has a clear picture.
Speaker 2: And I think when you think about domain in general,
Speaker 2: for any kind of business case, and again I'm falling
Speaker 2: back on e commerce, I did that the most. You know,
Speaker 2: the month end is the month end, and we do
Speaker 2: maintain those aggriates with only twelve of them of a
Speaker 2: year because they're historically relevant. But they once made, never changed.
Speaker 3: Yeah, yeah, and that's what we want with our events too.
Speaker 3: We don't want them to be immutable. But of course,
Speaker 3: since they're a domain event, they also have domain concepts
Speaker 3: inside them, and that's a choice, but that's a choice
Speaker 3: we have taken. So that's opinionated. But that means that
Speaker 3: when we get deeper inside and understand the business concept better,
Speaker 3: we might want to change them. So you are able
Speaker 3: to do migration of those events. Just as we always
Speaker 3: sat down, we'd always stayed in the database when we
Speaker 3: need to do any changes, then you are not changing
Speaker 3: the events you have. You read them up and you
Speaker 3: change them and write them down to a new events store,
Speaker 3: so you just start with a new cover.
Speaker 2: Yeah, this sounds like even just the change of the
Speaker 2: scheme in a database, and they're sort of a breakpoint,
Speaker 2: you know, going from B one to V two, and
Speaker 2: it is not easy to analyze across the breakpoint.
Speaker 3: No. So so even though we have these real models
Speaker 3: that we don't need to do migration. Now, that is
Speaker 3: really good. The hard part for us then is to
Speaker 3: keep those events because there you have you can have
Speaker 3: versens or you can migrate them. You have the same
Speaker 3: challenges as you have when you have the state in
Speaker 3: a database and you can't scratch that. One.
Speaker 2: Sure makes a lot of sense, and I think this
Speaker 2: is a good moment for us to take a brief
Speaker 2: break for these very important messages.
Speaker 1: Attention dot net developers looking for the ultimate SDK to
Speaker 1: handle electronic document processing. Meet TX text Control. Txtext controls
Speaker 1: your go to solution for seamless PDF generation, secure electronics signatures,
Speaker 1: and efficient digital forms processing all within your dot net applications.
Speaker 1: Empower your products with robust document management capabilities, boost productivity
Speaker 1: and deliver top notch solutions to your clients, trusted by
Speaker 1: developers worldwide, including me and Richard. Txtext Control is the
Speaker 1: SDK that makes a difference. Check out demos dot textcontrol
Speaker 1: dot com for live online demos and see it in action.
Speaker 2: And we're back. I'm Richard Campbell. That's Carl Franklin. You're
Speaker 2: listening to dot net Rocks. Hey, and we're talking to
Speaker 2: our friend Anita a bit about event sourcing and the
Speaker 2: role of demander of design in that. Where does COSMOSDB
Speaker 2: come into this.
Speaker 3: Well, we need a place to store over events, but
Speaker 3: we also need a lot of part of the solution
Speaker 3: to react to those events, if that is to build
Speaker 3: update your state, or if that is just to do
Speaker 3: our reactions. For instance, we often get events, we call
Speaker 3: them the events. Sourcing events is inside events that's part
Speaker 3: of your application, but you also get event from the outside.
Speaker 3: For instance, for the traders, the order a trade could
Speaker 3: be executed and we listen to that and the solution
Speaker 3: reacts to it. So we need something that is pushing
Speaker 3: out those changes, and we need something that is how
Speaker 3: high scales but also is easy to use and in
Speaker 3: Microsoft documentation on Christmas TB has something called a change
Speaker 3: feed and that is a mechanism for pushing out those changes.
Speaker 3: And in Microsoft documentation for this change feed, they have
Speaker 3: events sourcing one of the scenarios. So we were like, okay,
Speaker 3: we try. We were already committed to working assure, so
Speaker 3: it was already in that area. So then Christmas dB
Speaker 3: seems like the best option for us to start, and
Speaker 3: we really the power of this change Feit is really
Speaker 3: good because you can just say I want to listen
Speaker 3: to those events a processes listening, or you can have
Speaker 3: multiple processes that list to those events, and then the
Speaker 3: Christmas DV change feed make sure that one stream will
Speaker 3: events from one stream will only be sent to one
Speaker 3: of those processes that we also need because we need
Speaker 3: the sequence of events are important, but the sequence of
Speaker 3: events across different aggregates isn't necessarily important. So you get
Speaker 3: this flexibility. And as a software architect, I really like
Speaker 3: that because then I can't start small because we know
Speaker 3: that we can scale out. We know that Christmas dB
Speaker 3: can help us with those things.
Speaker 2: Right right is geolocated, synchronized, and distributed. But you can
Speaker 2: start with one node. This is an interesting angle on
Speaker 2: COSMOSDBI wasn't particularly aware of that it does have the
Speaker 2: speed mechanism that serves the streaming of events for sourcing.
Speaker 3: Really well, it does, and that is the reason why
Speaker 3: we picked just that one.
Speaker 1: Well, before you started with dd D, did you do
Speaker 1: non DDD development and how many years of that did
Speaker 1: you do?
Speaker 3: Oh? So when did I start with DDDY? As I said,
Speaker 3: it was a period where I was more working with
Speaker 3: user experience and as a business analyst, but I was
Speaker 3: part of building solutions that didn't do DDITY in the start.
Speaker 3: So I think when we started out with this, the
Speaker 3: first one I was part of, I guess that was
Speaker 3: two thousand and five, six maybe, And that was a
Speaker 3: completely different vlication, non event sourcing, of course, and yeah,
Speaker 3: a different It was related to partly invoicing and accounting.
Speaker 1: Actually, oh okay, so this is great. So you have
Speaker 1: experience doing invoicing and accounting without the benefits of events
Speaker 1: sourcing and DDD. And then afterwards, so what was that
Speaker 1: process like like when did the light bulb come on?
Speaker 1: And did you at first think oh, well, this seems
Speaker 1: like a lot of ceremony to get started, but then
Speaker 1: it got easier like, what was your experience like making
Speaker 1: that transition.
Speaker 3: Yeah. First, if you take the transition from kind of
Speaker 3: non domain driven design solution to domain driven the sign
Speaker 3: solution I was rewrite with it a huge monolithic application.
Speaker 3: It's actually very still running with the first line of
Speaker 3: code written in nineteen ninety four, so there's a really
Speaker 3: old one. Having a great value for the business still
Speaker 3: would be to take them some technical risk. We needed
Speaker 3: to migrate quite a huge part of that application. And
Speaker 3: I think for me, I read the domain driven domain
Speaker 3: riven the sign book when it came out and having
Speaker 3: this UX had on. I think it's kind of the
Speaker 3: same because that's what you want to do as a
Speaker 3: user experienced person too. You want to understand the business
Speaker 3: and you want to try to use those concepts, and
Speaker 3: that what we tried to do. So I said that
Speaker 3: DDD is X for the developers. You tried to do
Speaker 3: the business concept inside your solution. And for me, the
Speaker 3: big big change was that you could write this automatically
Speaker 3: tests around about the context. All of a sudden, we
Speaker 3: could put them into pieces that was possible to handle
Speaker 3: and possible we use behavior driven development to write those
Speaker 3: tests like spec flow test or feature tests. I guess
Speaker 3: you have a lot of different anames of those tests,
Speaker 3: but it's more high level than unit tests. So for
Speaker 3: me that was Yeah. I had a great, great person
Speaker 3: in my team and lip and she knew did it
Speaker 3: out and in and was a good teacher. So for me,
Speaker 3: it wasn't a lot of overhead. It just makes sense
Speaker 3: to think that way and to build the solutions that way.
Speaker 1: Right, So rather than building them by business feature, you
Speaker 1: built them by technical things that they did, like I
Speaker 1: would imagine no.
Speaker 3: More opposite, instead of making them model of your software
Speaker 3: based on technical concept because you can always solve one
Speaker 3: problem technical yeah. Yeah, But if you have a calculation
Speaker 3: and you make those technical lists, for instance, instead of
Speaker 3: really understanding what is the business concept seen from the
Speaker 3: business that is part of this calculation. And my belief
Speaker 3: and what I think is the power of domain during
Speaker 3: the sign is that when you use the business concept,
Speaker 3: is this more likely that the next business requirements actually
Speaker 3: fit into your code with because it's coming from the
Speaker 3: same business. So I can't prove it, I usually say,
Speaker 3: but I have experienced it. Yeah.
Speaker 1: So I'm working on an application right now and while
Speaker 1: it's not formal DDD We certainly grouped the projects into
Speaker 1: their different domains, but then we ended up with a
Speaker 1: shared project that has code that they're all going to use,
Speaker 1: but in different ways. So then we would subclass in
Speaker 1: the domain the appropriate domain what we needed and strip
Speaker 1: out the generic fundamental stuff in the shared project. I
Speaker 1: guess that's something that you probably I think. I mean,
Speaker 1: you know, somebody could be out there saying, yeah, but
Speaker 1: wounce you duplicate a lot of code. Well, no, not
Speaker 1: necessarily not if you just have good architecture design up front.
Speaker 3: Yeah, And I think if it's two different bonding concepts
Speaker 3: bond the context of its two different business area, they'd
Speaker 3: be probably changed for different reasons and at at different pace.
Speaker 3: So even though it's if it is a duplication from
Speaker 3: the start, I'm much more concerned that Okay, what if
Speaker 3: it is the same, but then they start to change
Speaker 3: independent of each other, because it doesn't really long together
Speaker 3: seen from the business So I find this thinking in
Speaker 3: the business term as a really good guideline for forgetting
Speaker 3: the right part of your application together, and that makes
Speaker 3: it easier to maintain it.
Speaker 2: Okay, So, Anita, how do you go about actually building
Speaker 2: an event so driven application.
Speaker 3: Well, actually I get a lot of help from some
Speaker 3: building blocks for building bloxes all you need and this
Speaker 3: was coined by Sebastian phone Conrad. I just picked upon
Speaker 3: talking had I looked up at YouTube that wasn't even
Speaker 3: at the conference, but I think it helps me demystify
Speaker 3: event sourcing because what you need is first you need
Speaker 3: a building block that is writing with commands and that
Speaker 3: takes care of whatever the user is doing. So when
Speaker 3: the user is doing something in the application, that intention
Speaker 3: is captured in a command and then that command need
Speaker 3: to do something to something and it is something. Here
Speaker 3: is to aggregate from ddity, as I say, a business
Speaker 3: entity with behavior and state, and the result of that
Speaker 3: is some new events or it could be zero events.
Speaker 3: So that is the one building block, and this is
Speaker 3: the one that is most similar from what we did before.
Speaker 3: But then of course, since we have an event source
Speaker 3: and just save those events, we need also to get
Speaker 3: the state in place. And here we have the concept
Speaker 3: or the building block of red models. And when you
Speaker 3: have this remodel, you just listen to those events that
Speaker 3: we briefly mention and you pick out the pieces of
Speaker 3: information you need and you build up the information that
Speaker 3: you want to display for the users. So this back
Speaker 3: end for front and pattern is really easy and a
Speaker 3: good way to go about for that. And then you
Speaker 3: have what sebast And from Conrad says is the cool stuff,
Speaker 3: and I really tend to agree with him. But that's
Speaker 3: the reactors. So what do the reactors, Well, they react
Speaker 3: to events. And I think living in a world where
Speaker 3: there is more and more automation, that what our solution
Speaker 3: is doing more and more is not necessarily the users
Speaker 3: pushing the buttons anymore. So you get events from other
Speaker 3: you're part of the event driven acle system kind of,
Speaker 3: and you need to react to those events. For us
Speaker 3: that is working related to the traders, the trades execute
Speaker 3: or the strategy started. Everything needs to react to each other.
Speaker 3: And these reactors is also the only one that where
Speaker 3: we isolate any side effects calling off APIs and all
Speaker 3: those or sending outside events, so other solutions should react
Speaker 3: to that is part of the reactors.
Speaker 2: Sure, and the users are one source of events, but
Speaker 2: I mean you've said a couple of times trading and
Speaker 2: equinors here in the petroleum business, so you're dealing with production,
Speaker 2: you're dealing with refinement and we're dealing with commodities markets,
Speaker 2: so you have a lot of disparate sources of events.
Speaker 3: Yeah, and I think there's a lot of areas out
Speaker 3: there where there are a lot of events. And when
Speaker 3: we do automation, we need to identify those events because
Speaker 3: we need to know when should other solutions do something
Speaker 3: when something has happened in the one solution. And so
Speaker 3: for us, it's a lot of different events. And the
Speaker 3: application I'm working with now is more like the traders
Speaker 3: for the gas traders, and yeah, they have products, so
Speaker 3: they and there is a lot of events when you
Speaker 3: are on an exchange, even if it was money.
Speaker 2: Training you has been let's say important.
Speaker 3: Yes, that's true. And so that is the third building block,
Speaker 3: and the fourth one is just this event store. And
Speaker 3: I think some of the secret of actually not making
Speaker 3: our applications too complex because you could say, okay, before
Speaker 3: I only had one building bock. It was so much easier.
Speaker 3: I don't need the reactor or the command and the remodels.
Speaker 3: But then again they tend to be very complex. Now
Speaker 3: we can divide where we put different business rules. For instance,
Speaker 3: if you have heavy calculation, if you have calculation like
Speaker 3: you should use that number of digit after in the calculation,
Speaker 3: or if you use this factor to go from energy
Speaker 3: to volume and all those things. You can do that
Speaker 3: just in the real models because it's not part of
Speaker 3: the force events. So you can place the business rules
Speaker 3: in the different part of the different building blocks. And
Speaker 3: I think the clue of it all is to make
Speaker 3: application because event sourcing is a bit complex. So it's
Speaker 3: a complex our infant and there is no way around it.
Speaker 3: But you have to make sure it's a complex arrangement
Speaker 3: of small parts so each part is not growing. And
Speaker 3: I think we at least us that I work in
Speaker 3: the IT area for years and years, we have been
Speaker 3: so used to build those big solutions, so we actually
Speaker 3: we tend to put everything together. And I think that's
Speaker 3: what we as a industry are trying to solve. And
Speaker 3: we want it more distributed. We want to split things
Speaker 3: up so we can change them and so on. So
Speaker 3: here to we have to keep eye on the different
Speaker 3: building box.
Speaker 2: Sure you don't not every app makes sense for event sourcing,
Speaker 2: but you have a complex multi event problem. Other techniques
Speaker 2: could be applied, but they may have more residency problems,
Speaker 2: like you might have more problems maintaining that there's something
Speaker 2: about the architecture of event sourcing that tolerates adding new
Speaker 2: event feeds really well, adding new reactions to it to
Speaker 2: those event feeds, well, that's very tolerant to content diversity.
Speaker 2: More and more things can come at it and it
Speaker 2: doesn't get in the n over n mindus. One problem
Speaker 2: doesn't compound the problem when you add more diversity that way.
Speaker 3: Yeah, and I think that's the better. The can we
Speaker 3: get to a place where adding new stuff isn't becoming
Speaker 3: harder and harder, right because it's the smaller that the software,
Speaker 3: And of course we can't stop believe that we we
Speaker 3: get there some day, so we have to try. But
Speaker 3: at least I think it's easier for event sourcing to
Speaker 3: add smaller part well.
Speaker 2: And arguably if you've really done this well, it gets
Speaker 2: easier because the services are already there for a lot
Speaker 2: of these things. So as a new event class comes
Speaker 2: in or as a new reactor is needed, you don't
Speaker 2: have to build a bunch of stuff because the infrastructure
Speaker 2: is already there.
Speaker 3: Yeah.
Speaker 2: I almost think it's a dream, But you know, all
Speaker 2: we're hoping for is it doesn't get worse. It'd be
Speaker 2: nice if it actually got better.
Speaker 3: Yeah, And of course event sourcing isn't dissolution for everything,
Speaker 3: and it's everybody said that event sourcing is not a
Speaker 3: high level architecture pattern and it's not something that you choose. Okay,
Speaker 3: everything that I make should be events source, or everything
Speaker 3: we make in our company. It doesn't because you have
Speaker 3: some simple problems that is really just a crowd problem.
Speaker 3: It's just updates in some information. And the same discussion
Speaker 3: we have had for domain during design for years too,
Speaker 3: how complex should it be for Actually it really the
Speaker 3: extra effort you put into doing ddity is something you
Speaker 3: should do. So but as I said, I've been working
Speaker 3: mainly with complex business application and there it makes sense
Speaker 3: for some of the problems we solve. And then what
Speaker 3: I'm working on now, I sometimes just thinking how should
Speaker 3: I solve this if I haven't had events sourcing, And
Speaker 3: that feels like, okay, we have gotten a good pattern
Speaker 3: just for this hour problem space. But of course each
Speaker 3: problem space is different and that's always the starting point
Speaker 3: understanding what you are solving.
Speaker 2: Yeah, yeah, well, and it makes me wonder can you
Speaker 2: decide this ahead of time? Do you know enough or
Speaker 2: do you have to make the wrong thing first, like
Speaker 2: do you have to start down a path building something
Speaker 2: addressing Some ask this, they realize, well, this is going
Speaker 2: to be a problem. We need to re architect into
Speaker 2: an event source model. I would think the answer is
Speaker 2: read the book first. Only if you know you have
Speaker 2: the problem.
Speaker 1: Well you might not know. Yeah, maybe I would think
Speaker 1: that the first thing is look up what event sourcing
Speaker 1: is and then consider how you're going to be accessing
Speaker 1: data and and you know, make the decision because it
Speaker 1: can you You're right, it can't apply everywhere.
Speaker 3: Yeah, And that's why when I have the talk ahead
Speaker 3: at end the see, I try to focus on what
Speaker 3: is the good part and what is the hard part?
Speaker 3: Because you can't tell people when you should use it
Speaker 3: based on business domains or so on. But I try
Speaker 3: to figure to line out this is really nice with
Speaker 3: event sourcing, and this is quite make it harder when
Speaker 3: you do event sourcing. And then I think each team
Speaker 3: need to think about a problem they are solving, and see,
Speaker 3: do you think that the benefits are better than the pain,
Speaker 3: But of course you might. For instance, the first product
Speaker 3: where I used it, we had this event sourcing is
Speaker 3: really known for being a time machine. We can't travel
Speaker 3: into the future, but we can travel back. And our
Speaker 3: youser told us they had some autitudes on the fabric
Speaker 3: that they needed to keep track of, and I said,
Speaker 3: we would like in the future to know which of
Speaker 3: these outages did we know about three months before they happened,
Speaker 3: And event sourcing is kind of the really really good
Speaker 3: fit for that. So it was one of our motivations
Speaker 3: for picking that pattern. And then it turns out we
Speaker 3: didn't get to that part when they needed that information.
Speaker 3: So yeah, sometimes you have to might be changed. But
Speaker 3: I think focusing on a good and a hard part
Speaker 3: to understanding how are it different, and then each team
Speaker 3: need to think about, okay, here we see that we
Speaker 3: can solve a lot of things that event sourcing has
Speaker 3: the good spot, and then it might be a good
Speaker 3: time of using it. And one of the main pain
Speaker 3: point is actually the mindset is different from what people
Speaker 3: are used to. But I guess in it industry we
Speaker 3: are used to needing to change over mindset and learn
Speaker 3: new stuff all the time, So you have to have
Speaker 3: a team that embraced that part to think differently.
Speaker 1: Sure, you reminded me of when you said, you know,
Speaker 1: we how do how would we know three months ahead
Speaker 1: of time when we look at the event sources. Is
Speaker 1: there room for predictive analytics and other AI to look
Speaker 1: at the event source data and maybe notify us when
Speaker 1: they see patterns coming.
Speaker 3: We haven't been playing in that area, but yeah, I
Speaker 3: think so. I think you know, as I said, I
Speaker 3: use this schlogan of architecting for tomorrow questions because you
Speaker 3: have those events and you can do analytics on them,
Speaker 3: and you don't need to know ahead of time, Actually
Speaker 3: what information do we need because they're only thinking what
Speaker 3: are happening in the business and the critical information related
Speaker 3: to that event a bit independent if it's useful or not,
Speaker 3: because one day it will be.
Speaker 1: You also have to you also have to put in
Speaker 1: the event source catastrophic failure if you're going to try
Speaker 1: to prevent it in the future.
Speaker 2: About I mean, this is going to be more data intensive,
Speaker 2: but goodness knows, we have enough storage base like that.
Speaker 2: Once upon a time, we were really careful about how
Speaker 2: much data we stored it, so we tended to stare
Speaker 2: of the agree because it costs less. That's not the
Speaker 2: issue anymore. Now. The issue is we don't know why
Speaker 2: we did what we did. Last year because we only
Speaker 2: have the aggregate data, not the whole chain.
Speaker 3: Yeah. I actually had a very interesting discussion with Alberto
Speaker 3: Brandolini at the explore Ddity conference when he was talking
Speaker 3: that sometimes, if I understood it correctly, I sometimes see
Speaker 3: that issues you try to solve, for instance, in the
Speaker 3: data warehouse could have been kind of easily extracted if
Speaker 3: you have the events, because I think when you get
Speaker 3: to on the other side, you try to do the analytics.
Speaker 3: As I said, even in our solution back in time,
Speaker 3: we put all this flag because I think we need
Speaker 3: to know what have happened and why, and before we
Speaker 3: only had this data, so we do different things just
Speaker 3: to try to analyze it to understand what did happen
Speaker 3: in the business. And this gives you that as the
Speaker 3: core part of your information. So I really believe that
Speaker 3: as organizations get more and more data driven and more
Speaker 3: part are looking at the data, that it's easier to
Speaker 3: compare because you have fitted in a context already.
Speaker 2: Yeah, and the sort of modern data analytics model now
Speaker 2: where you have the quote unquote data lake rather than
Speaker 2: a warehouse, you're literally just dropping those blocks of events
Speaker 2: up into the lake for analytical tools to be able
Speaker 2: to have access to the truth rather than they aggregate.
Speaker 3: Yeah, I know. We also try to at least an
Speaker 3: equino to embrace this Tata mesh concepts. So instead of
Speaker 3: having one big lake that every events are swimming in,
Speaker 3: you have it into a mesh. That is I call
Speaker 3: it to manduin the sign for a data because you
Speaker 3: try to make a domain around your collective data that
Speaker 3: you before put just in aware else because that will
Speaker 3: also give you more context. And I think that's the
Speaker 3: hard part with data without context? What is it actually?
Speaker 3: That is hard to say.
Speaker 2: The challenge with the mesh is the intersection points right
Speaker 2: each If each different set of applications has its own customer,
Speaker 2: how do we have a unified customer. Yeah, but those
Speaker 2: are good problems to tackle, it is, and.
Speaker 3: I guess that's the challenge of the distributed application too.
Speaker 3: When we put things, it's hard to put it together.
Speaker 3: When everything is together, it's really really hard just to
Speaker 3: move it anyway. Balance.
Speaker 2: Yeah, the monolith is in the answer to everything, and
Speaker 2: the distributed system is the answer to everything. So there's
Speaker 2: always going to be seams, Yeah, where we're going to
Speaker 2: have to figure out where that how to battle with
Speaker 2: those particularly.
Speaker 1: Common topic we've been discussing here for the last year
Speaker 1: or so. During two years, yeah, two years, good lord, at.
Speaker 2: Least dely longer, just because the sort of the reality
Speaker 2: of we're now at a place where we have as
Speaker 2: much compute, as much uh storage as we want, so
Speaker 2: now you're sort of designing for the optimal. Maybe it's
Speaker 2: a cost control thing, but it's most Most of the
Speaker 2: cost controls are about maintaining software, being able to do
Speaker 2: the new versions quickly, being able to respond to business opportunities,
Speaker 2: and so you architectures are hard. There isn't a right way.
Speaker 2: If there was, we'd all be doing it right. You
Speaker 2: can buy it at seven eleven. If it was easy.
Speaker 3: I heard someone saying that, look at all the conference
Speaker 3: is out there on it. If it was easy, why
Speaker 3: should we have them. It's because we need to learn
Speaker 3: from each other to solve those problems, because everything depends.
Speaker 3: So you need to learn enough to really be able
Speaker 3: to think about how is how should we do it?
Speaker 3: In our context?
Speaker 1: So what's next for you? Anita? Speaking anywhere? Writing some
Speaker 1: more stuff? What are you what are you working on?
Speaker 1: What's in your inbox? Yeah?
Speaker 3: Well we'll go to London to the jacks y X
Speaker 3: London conference. That's the next one. That's the only one
Speaker 3: I know for now. But I also are preparing thinking
Speaker 3: about talks for both explore d d D and ddity Europe,
Speaker 3: just because I think those conferences is I learned so
Speaker 3: much every time I go there, and I really want
Speaker 3: to to both learn from others and share what I
Speaker 3: have learned by working as hands on every day. So
Speaker 3: the main part it's to make this application that we
Speaker 3: are working on for the traders better and better and
Speaker 3: more and more functionality every day together in the team.
Speaker 3: It's really enjoy working in the.
Speaker 1: Team fantastic, you know I before we go, I really
Speaker 1: appreciate just a plain English way that you explain these things.
Speaker 1: It's great. I thank you, and I really appreciate your
Speaker 1: approach to events, sourcing and DDD and on all of it.
Speaker 1: It's great. So thank you very much for joining us
Speaker 1: this hour.
Speaker 3: Thank you so much for having me. Have a nice evening, all.
Speaker 1: Right, and we'll talk to you next time on dot
Speaker 1: net rocks. Dot net Rocks is brought to you by
Speaker 1: Franklin's Net and produced by Pop Studios, a full service audio,
Speaker 1: video and post production facility. Located physically in New London, Connecticut,
Speaker 1: and of course in the cloud online at pwop dot com.
Speaker 1: Visit our website at d O T N E t
Speaker 1: R O c k S dot com for RSS feeds, downloads,
Speaker 1: mobile apps, comments, and access to the full archives going
Speaker 1: back to show number one, recorded in September two thousand
Speaker 1: and two. And make sure you check out our sponsors.
Speaker 1: They keep us in business. Now go write some code,
Speaker 1: See you next time. You got jam vanst