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