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.
Hey Carl and Richard here with your twenty twenty four NDC schedule.
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.
Ndcporto is happening October fourteenth through the eighteenth. Tickets at Ndcporto dot com.
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.
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.
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.
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.
Yeah, that's right.
And I've been smoking a lot of salmon and ribs and you know that kind of thing.
Is that good for your lungs? I'm not smoke smoking salmon.
Yeah, but plus it's really hard to keep it lit.
Yeah. All right, Well let's jump into the way we start the show with better not a framework?
Awesome, man, what do you got? Well?
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.
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.
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.
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.
That's great. So that's what I got. Who's talking to us today, Richard?
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.
Yeah.
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.
So, and it's really getting good, Like voice commands have always been around.
Yeah, it's just dragon naturally speaking in the eighties for god's sake.
That's right, where you trained your parrot to turn the lights on and off.
But don't do that.
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.
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.
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?
Oh yeah, many many time.
Oh goodness, Oh great.
Should be a k quak for you.
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.
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.
I think, did you say Eric Evans has has joined you equan No.
No, but we kind of hire it him as a consultant for our guests for some weeks or something.
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.
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.
It the cake driven or domain driven cake.
Yeah.
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.
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.
So why is the main drive design essential to event sourcing?
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?
Right?
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.
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.
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.
The domain event is sort of the starting point of an event storm. What is the domain event?
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.
As I understand, it's like it's a whiteboard, sticky note process approach.
Yeah, it is, absolutely So.
What's the granularity of domain event? Is it like adding something to a shopping cart or initiating a sale? Like what's they.
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.
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.
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?
Yeah?
Okay, what's important to the organization?
Right?
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?
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.
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.
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.
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.
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.
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.
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.
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.
That's a legend.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Really well, it does, and that is the reason why we picked just that one.
Well, before you started with dd D, did you do non DDD development and how many years of that did you do?
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.
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.
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.
Right, So rather than building them by business feature, you built them by technical things that they did, like I would imagine no.
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.
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.
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.
Okay, So, Anita, how do you go about actually building an event so driven application.
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.
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.
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.
Training you has been let's say important.
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.
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.
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.
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.
Yeah.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Common topic we've been discussing here for the last year or so. During two years, yeah, two years, good lord, at.
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.
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?
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?
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.
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.
Thank you so much for having me. Have a nice evening, all.
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