Event Modeling with Adam Dymirtuk

you know we're gonna there coming. We're gonna geek out with our guests.

twenty twenty five. And if you're a fan of you know, Food Network and Celebrity chefs like I Am.

last year. Some of them like to be a little more private than others and they don't really come out and greet and talk, but others will hang out with you like the whole time. Wow. So I'm just really really excited to go on this. I've actually bought a ticket, so oh you're going, I'm going. So if you want to go on this cruise with me, just get a ticket.

So thanks. I have a reputation for coming into work and saying I was listening to dot at rocks And anyway, onto the real meat. We've been using aka dot net and event sourcing ideas that I need to talk about and it's a match made in heaven. All the positive things that I need to had to say, but wanted to point out one other benefit that's been very interesting.

When you have an event store and an unexpected question arises, you can always write a bit of code to reprocess that event streamer streams to calculate the answer to a new question. I believe Anita mentioned the time travel or something like that, the events can always be replayed up to a desired time and allowing you to view the state as it was at the time. In my experience, the business is delighted when you can perform magic tricks like this. Thanks so much for the great show.

comment and a copy of music Cobi. It's on its way to you. And if you'd like a copy of music code by, I write a comment on the website at dot at Rocks dot com or on the Facebook to publish every show there. And if you comment there and I reading on the show, we'll send you copy of music Coba.

and event sourcing. He has been instrumental in advancing these methodologies, particularly through his work on event modeling, which we'll talk about today, and that provides a transparent, inclusive and collaborative approach to system design. Adam is a frequent speaker at international conferences and has contributed significantly to the responsible, efficient system design and implementation in software industry. Welcome Adam, and apologies that you haven't been on this show before.

being responsible with your information system. So sure, really the whole kind of background of how our parallel lives kind of weave in and out.

systems throughout thousands of years. Most of the organizations and systems that happened before computing were literally record keeping and you needed those carbon copies to know where the heck things are people filing cabinets by their desks to you know, to have the old copies there. So events sourcing is actually quite natural for human beings.

One of the simplest things about it is that you really don't have to think about you know, am I going to have to follow a whole bunch of relationships between tables right away? When I have a form and I press submit, it's like, the only thing I need to do is just store that that was submitted. It's almost like the systems thinking boundary and capturing things at the ingress and the outgress, like and that is your source of truth. So there's very little subjectivity about it.

When you know that your business requires this information that user is going to be adding something, it really takes away that subjective kind of discussion of like how am I going to design this? And oftentimes in this event way, the event modeling is not really modeling the events themselves. It's modeling using the building blocks that the events provide because they're kind of dictated to you, like the business says this has to happen at this time, so you

have no choice but to capture that information. The subjective stuff is left how you interpret it later. But the other good thing about that is is that you are not really restricted to one way to abstract that projection. You're free to really do a lot of different projections for different purposes, so that same information can be used in an entirely different way further along in the workflow.

And so there's this natural sort of fanning out into purpose built abstractions, which really gives a lot of awesome capabilities for people working on the projects. That's also have a list of one hundred benefits of this approach, and one of them is this really good autonomy so that people don't step on each other's toes and so that you're free to build the abstraction that fits that particular

step in a workflow one percent. Right, You're not make one abstraction that tries to make all the different pieces happy, because you're never going to make everyone happy all the time. So that's kind of one of the really benefits of that.

makes sense. So you need to have both, or you end up with water World. You know, if it looks really good, you don't want you don't want a water World. So that's and vice versa, right, I mean you can have the really you know, a really good story and you hear about this an excellent book with a horrible movie adaptation, right, so you don't want the opposite either, or something is a visual to just you don't.

you log in? Okay, you press this Okay, I understand. You set it up, and now I can put things in the cart and my customers can pay for things.

or not? That's highly subjective and also silos a lot of the conversations into just the dev circles, so it doesn't really have a good collaborative platform for talking with your business users. Now State. I sometimes explain this as like this, you know the pyramid you have in an organization where we have your you know, boss, CEO, whatever,

they have a vision statement. That vision statement gets broken down into a set of goals or whatever, and then it gets keeps getting broken down into requirements, into actual you know, implementation and tests. So it really fans out. But there's that really good common area in the middle of that triangle called understanding state. And as I go through this, you know, storyboard of what what people see, what gets stored in the system as the time moves on.

By example, you know, no branching, nothing like that, just like no no flow charts. Is not a flow chart. You really understand, you know what happens, and people can work together using this. It's kind of like a blueprint. If you go to a construction site, there's a big blueprint on a big table. The carpenters and the and

the and the plumbers can can look at it. And so the key there is that the carpenter knows exactly where to cut the holes in the walls so that the plumber can put the pipes through where they need to go.

we've never actually practiced them. So this, you know, this event modeling can actually be done as little as an afternoon, and it can also be done and often is done as a way to maintain the system because you upgrade your schematic of what's happening. So you know, if I come back to a system four years later and we do this often you kind of roll out the schematic and say, hey, someone needs a feature and it requires you know, this extra workflow to be at it, so

we'll make space on it. Plunk in what needs to be done, do what's called information completeness check, which is a real fancy way of saying, do I have a source for that piece of information somewhere? And if the arrow's doing add up, we know we're missing something and so we're going to have to you know, this is where we really understand the coupling in a system. We start to actually see where you know, that field value

must come from. Okay, we probably need to add date of birth on the registration page because we're obviously using date of birth and the thing that we just imagined we want to have in the next release. So that's

kind of how it works. I also think of old history of when you had a vacuum tube television and you opened up the back panel, you'd have the entire schematic with the where each wire goes to which vacuum tube, so that if something went wrong with your TV, you know, it's not today's throwaway society where you go back to Costco and return it. You actually, you know, had a TV repairman and go and you know find that too. And you know, I think someone mentioned that there's at

stores there used to be vacuum tube testers. We'd plug in your vacuum tube and click and then see which ones work or whatever. So we kind of want to have that responsible way of maintaining our software systems. And so an event model is a is a really human friendly diagram of what the system's doing. And I also call it inform architecture, which is really the backbone of all architecture because no matter what cool stuff we're doing in tech, it all serves the purpose of getting information

to people, right. And the reason that the screens and the UX is in event modeling is because all systems we build are for humans, and so we need that human face to it. And so where previous attempts to do even like business specific things like BPMN, oftentimes this is more of an extra feature or a benefit that you can or can't use, event modeling says, no, you've got to have these things in here because humans are

using it. So I really want to know if my process is at fifty percent, you know, with these steps, if I navigate to this web page, what would I see right? And on those relevant things, we kind of do that, and so an event model is organized as well, so you have your subsystems and swim lanes below, and you also have the different users that are interacting with the system at the top in their own swim lanes.

And the middle part is really like the watermark of like the input and output, Like where does the information come in? And then how is it project it out to a particular screen, And you can connect all those things together and it's a real fun, fast way to get going, but also a really responsible way of maintaining really crazy large systems. So we had these event models that you know, span giant projects worth millions of dollars, and so it ends up scaling from you know, startup

to giant enterprise. And it's kind of like skills like this I kind of see as carpentry, right, Like if you know the shape of wood, you can build a really good chair, you can build a really good house. Right. How does a good carpenter work at all these levels, Well, they really understand the nature of what they're working with, right, And so understanding information is kind of like the backbone of being able to you know, build small systems or build large systems.

We don't have the ability to shift the culture to do it that way, but they still use event modeling for that. So your question, Richard, is about kind of two areas. So yeah, underlying technology, there's tooling there to support event sourcing if you want, but you can use it with traditional stuff, right, doesn't make it any harder. But there's also the what do you use especially around COVID.

A lot of this stuff used to be done in person before COVID, on whiteboards where you would use sticky notes to kind of elaborate what's our workflow, you know, what are we going to be capturing. Let's put up some you know, mockups that we drew with with felt markers on white pages and just put them across and kind of say, yeah, that looks like a really cool system. I can see this working, and I can.

out there. There's open source ones like Diagrams, dot net and on and on, Lucid, chart Excala draw. All of those work as long as we can draw a rectangle and connect them with arrows. You pretty much got all you need for event modeling and you can get started right away. And so the other thing that makes this tech agnostic on the front end of actually designing it is that it's really synonymous to what a lot of

people are happy with already. Most systems that you have that people want to design, people are quite familiar with mockups and they want, you know, mockups of the screens that a user will see in generally, so a lot of places already have kind of the basics in their muscle memory to go through this kind of process. So that's why it's getting quite a lot of traction.

been vetted as much as with another platform. So you know, if you were to do a wireframe mockup of sending a message from one user to another on a wireframe, that would look like, oh, that's just two steps. There's a send message and that oh this person's receiving it, great specs, right, But like in the middle is about twelve steps of we got to spam check, we got to translate it, and you know, replace dollar signs for essays and all sorts of tricks that people play to

do that. So you know, when we actually did this with them, event modeling elaborates this to make this complexity drawn out horizontally to actually see the size. So where this makes an impact is in your agile estimation, so or you have extra L T shirt sizes or whatever. We kind of don't want to be subjective saying like, hey, Adam, how hard do you think this is?

other person on this platform. I need to then see and illustrate to the business in a human friendly way that this is going to take twelve steps along the way to transform the information and filter the information along the way, and we can label those things such as bad word filter and spam filter and you know alternate character Unicode filter where people are trying to well, you know, the old hack with a semicolon being replaced with the

Unicode version from I forget what it is. I think it's an an Indian language of some sort, but it looks like a semi colon, but your thing doesn't compile because it's not actually a semi place.

And if you systematize things that like, can we just work together shoulder shoulder looking at the system and kind of you know, spread out this highly complex unit of sending a message on this platform that's got these vulnerabilities and explain how that actually works instead. But the trick was always that that was always looked at as a technical thing and always got chucked over the fence to the devs.

know that goes to how we do specification. So we do a lot of spec a specification by example from the behavior driven design stuff with guys like Joshua Kariewski and Dan North and others that have really pushed this. Goyko is another one, so growing software with Objura, I forget what it is. There's a there's a growing software book, the Goose Book I think it's called that also talks about a lot of this stuff. But really it's going

back to that human friendly thing. And the reason that event modeling is a story like thing is because humanity kind of built on stories.

the story really sticks in your head? So when I'm done with the event modeling workshop or a meeting about it and I was looking at it, actually retain at much higher percentage of what was discussed because it sticks in my head. As in a story format.

dot com, slash dot net. And we're back. It's dot net rocks. I'm Carl Franklin. That's my friend Richard Campbell. Hey, and Adam Dimitrek is here. And we were just about to sing tub thumping songs.

different things that worked in the industry. So one of the things that worked was a workshop type of environment versus a meeting, so that there's constructive things going on and you're actually collaborating. There's no I just have action items at the end. Of a meeting, like we actually did stuff during the meeting, which is much better the yeah, exactly like my meeting.

all that. We have obviously this idea of multiple models to make sure that we can express what a specific part of a workflow needs based on a common source of truth, which is very easily implement if you are doing events sourcing. Back again, as I say, it's not necessary to do event modeling, but oftentimes they're highly complementary.

So there's also this idea which we touched upon of immutability, So everything in here in terms of the source of truth is not utable, and so this additive only approach is also it gives you, you know, caching is way easier when you're dealing with additive only, like you're just moving up point you're to validate cash and things like that, or see how far you caught up to so a lot of you know, technical things are are much better. It also opens up the door to functional style programming.

You don't have to have a functional language. So all the f sharp proponents really do like events sourcing because of this immutability part, and like you know, growing ledger, it's really easy to feed that into your functions and do mathematical map produce on these things and all that kind of stuff left folds and all sorts of you know,

functional paradigms. But you don't need that. You can actually explain those benefits in human language to business that you have a guarantee that anytime you've had this history, if you try to do this, you're always going to end up with this result. So this idea of a pure function enters into the arena as well where things that you test in your unit tests, etc. Are always going to be deterministic, so given the same inputs, you're always

going to have the same output. That makes for really really strong unit tests and you know, brings a lot of benefits there. So that's you know, all of these things are are kind of at play. So you know, things like domain driven design with organizing things within bounded context so that things are related using ubiicuous language to make sure that the terminology is something that everyone understands for a particular context that ends up being embedded in

the event names and the event model. So all of the things that you're trying to do with all of the kind of best practices that I've seen kind of you know, when I started a company, it's that we don't have people like I don't have money to spend on project managers. I don't have money to spend on product owners. I don't have money to spend on QA.

I don't have money to spend on any of these How can we make a system that takes care of what those jobs took care of, or at least scale their efficiency so that I don't have to hire twelve pms. I can just hire one to do that to take care of these projects. And so if event modeling was kind of born out of needing to fullfill all those goals.

time sort of dropping the you know, copying the database again. Is that is that something that you do normally? Yeah?

database that can do that. A lot of times, technologies that Kafka can have something that keeps track of x amount of days or weeks worth of data to go and interrogate as you wish on the side. Yeah, and it's really easy with event source.

lot of times we will have that. A lot of times with most events stores, they are just sitting as flat files on discs, either as a giant chunks of you know, two hundred and fifty megabyte files that have the events serialized within them, and you can just literally just pull them as copies and then you're really you can really leverage you know, your infrastructure and the hard drive tech that you have to kind of have that work done for you if you're mirroring.

here to see what the heck you were doing. So, and there's other strategies such as snapshotting and and closing the books, which is really making sure that the streams of data don't live forever, because that's not how usual. You know, businesses run like a trading at af your if you go to a stock trading exchange or whatever, they they end their day, right, a reconciliation, right, So there's a natural seam in the timeline for different things.

And so you know, same thing. If we were doing this on pen and paper, the end of the year, you probably empty out your filing cabinet, put it in archives or something like that.

a serious business. And that doesn't really change that much when you think about it when you're going digital from pen and paper.

price for each one. So when we do work. We do fixed cost only and we fix bugs for free because both the client and the subcontractors are happy with that deal. In fact, it's something that drives quality with the right carrots and sticks. If I go super fast and like do twelve steps in a day, I'm going to have a whole bunch of bugs. Well, our contract says that you have to fix anything before you get to work on new work, So you're not going to

be able to charge for any work. If you just blit, you know, totally chat GPT way through twelve things and think they're popping up all over the place next week, you're not going to be having a good time for the next three weeks of fixing them. The things that you kind of went through pretty quickly, so it self adjusts really well, and I think both the clients and the contractors appreciate that. And also, those units of work are highly autonomous because now, as I said, we have

different projections, different you know, abstractions for each piece. So if I do a bad job, I'm not impacting the person working on the on the piece of workflow right next to me, right as long as we're adhering to those pre and post conditions of every little workflow step, we're good. And if I do a crappy job, I can replace that entire workflow step and I don't really have to coordinate with the others. So this is like the pizza sized team for Agile kind of goes away.

We can start to really measure the size of teams based on how mature our design is. That's the thing that pulls back. If I don't have time to make an event model, then I only have, you know, enough work for a team of size five. But if I actually take the time to build out and understand how the system is going to treat information, how many work workflow steps I have, then I can have the latitude too.

Ten fifteen people work on the same thing, and we know that they're not gonna step on each other's toes and and things will click like lego. And that's kind of how other engineering disciplines work. You know, car manufacturing, all these other things are they have standardized pieces now where you know you don't have to You can get a rebuilt alternator from an alternative you know, some other manufacturer,

and they work just fine. So we're trying to really make if you know this type of approach bring software development to be more of a true engineering practice rather than you know, being a lot of experiments and just feedback cycles as we really wanted to, like, oh, iterate, iterate, that's going to solve everything. Well, you know, we look at other industries, they kind of take time to design

things a little bit. So we're kind pushing the needle back a little bit to the middle because you know, we came up, we came up through this idea in the eighties and nineties of this big design up front and the waterfall method and all this kind of stuff, and you know, take a whole year to plan something and then you know, things don't go as well when in reality, we one all the way to agile, right,

the to just iterate, yeah, because we hate planning. So I think, you know, agile missed a chance to really focus on that small design up front, which is a big opportunity. And I think don't mean driven design specific example, all of them kind of attacked that a little bit and said, hey, that's a good way.

Safe BC. Someone got injured on the job and they had to switch careers and work Safe BC augmented their pay for us. But they were able to start this because you know, each of these workflow steps, at least in event sourcing, is identical. Like there's only two patterns. So you're either working with a command handler or you're working with a read model. And if I'm a new person, all I have to do is like, hey, Tim, how did you do that command handler? I copy their code

and just and all that. It's like the same pattern over and over again. So this repeatability is highly valuable because you get a lot of cadence. It also gives the excellent you know, estimates because you're doing the same thing over and over again. So you're sample sized growth, you know, mathematically speaking, your sample size for how long

things take. You get a really good idea. Whereas if you were to throw a whole bunch of patterns all the time at every problem, you're going to have a smattering of small amounts of statistics for each pattern, and that's not going to be enough confidence to say that, yeah, I can do that for X amount of money. You're you're not going to have that amount of track record with that. So by repeating you know, a few core

patterns over and over again, you really do that. And after ten like we've been in business for about ten years now, we've got like a ton of statistics to go on. And so when you know, when we say a project, will you know cost this much and take this much time, it's pretty spot on, especially if the client is there collaborating on the design saying yeah, these are the screens we want, Yeah, these are the steps

that have to be taken to capture this information. From that, we can say, yeah, everyone's happy to sign on for you know, fixed costs and all that, and I think something that's really worthwhile and you're confident and you should be able to do for fixed costs. That I think is a sign of like maturity to be able to have you know, people take on that quote unquote risk and it's actually de risking a lot for both sides.

And so back to that point, you know, someone that you know came into to work in software for the first time, they felt really at home because there was really good guardrails of how a framework within which to learn programming. So they can make all sorts of mistakes when they're making a command handler or they're making a read model, and they could iterate themselves to learn that. And of course their throughput is not going to be

as much. They get paid the same amount for that piece of work as someone that's senior, so it might take them three weeks to do it. A senior person might take three hours if they're really really good. So we've seen a huge variance. It's also exposed a lot of the inequality in the industry, like a staff engineer's a senior engineer level one versus a level two, or there's like a five thousand dollars difference in pay. Well, the difference in pay for levels of skill we've seen

is insane. We've had people make as low as three thousand dollars because they're new, to as high as seventy thousand in a month because they're so good. It's insane. How the variance of people's ability or incentive or devoting themselves to the amount of time, it's been very enlightening, and I just like the fact that you know, it kind of manages itself because when you have these standards, you have a system that kind of operates on its

way on its own. You don't need to fill a whole bunch of other jobs to manage it, or at least if you have those jobs, you can scale out the amount of work under those jobs way further out. So you know, we've been pretty much a flat organization

much like get hub started or Valve. It's just myself and everyone else doing the works, about twenty thirty people at peaks when we have larger projects, and there's really very little need for any kind of management like these event models kind of you know, we color them in as the project moves on. There's no backlog, so as we look at the schematic people just fill in the rectangles that represent the slices of the workflows. You know, they paint them yellow maybe if it's in progress, and

the pink them green when they're done. And we always look at it and say, hey, this looks like it's fifty percent done. And some have done automation of miuro, for example the Whiteboard to kind of use its API to give you like a burn down chart equivalent. Right, they'll count how many of these slices are actually colored in versus not, and then you can see how many your own progress instead of have a nice little bar graph shows you what's going on. So we've replaced all

the tooling with just an event model. But we're the extreme, like we just want to show what's possible, and most organizations are not going to be able to do that, we understand, but at least we kind of show what's possible, and then you know, for most people that's an answer somewhere in the middle. So we've had to integrate with Jira and other things for certain projects because that's what

they have in their organizations. That's fine. You can translate these things and we're happy to do that so it's compatible with other things. But we always want to just push the envelope and and just show what can work so that people have the confidence to pick something in the middle.

But this is like a concise kind of way of looking at it all in one place, and a lot of people want that. But yeah, you can see. I don't know if I can be legible or not, but yeah you can see. I guess the people who are listening to the radio they can't see what I'm showing.

spot wow for weekly sales the whole time. It's it's been something that a lot of the community has been asking for because a lot of people have been doing event modeling or trying to you know, promote it and use it because they like it and they want to carry it through to the rest of the organizations. So you know, I've been threatening to write a book myself on it, but running a business and doing that is a little bit too much. But I'm glad that Martin did it and included it.

the community has been doing. And the original article that I wrote was from really twenty eighteen that kind of got pushed. I think I wrote it on Medium. I forget where I wrote it, but it went viral in the fall of twenty eighteen October, and I don't know what the heck was going on, why my phone's going off, but it got the top story on Hacker News, and I'm like, what the heck? Why is everyone so interested? And that kind of gave me like, Okay, this is

not just how we were. People actually want the same things as we want. They want to do things this way. So I made a website for it, eventmodeling dot org, and I basically stick all the resources on there. I'm not very good at keeping it up to date as much, but I try to stick in like links to books and research and the videos, the YouTube channels of examples,

it's all on there, link to that. But yeah, the history of how this whole thing evolved, it wasn't I did not intend to make event well, it was just you know, we found a really good way of working that's effective and then captured you know, how we worked into both a process and the notation that people could reuse. And so that's essentially what event modeling is and from it,

you know, other people are writing books on it. There's a lot of tools also that kind of Martin has an ad in to MIRO that allows you to more easily manipulate things that are event modeling on a mirror board to what to mural you know, MIRO, the real time board. It's now called MIRO the Whuro Collaborative whiteboard. So a lot of companies use MIRO as a whiteboard. I mean same you know, just like maybe dot net teams use the white collaborative whiteboard. Yeah, exactly. Yeah, so

it used to be called real time board. Like if you look back in the day, that was kind of a very popular thing in the startups, and I don't know, ten fifteen years ago, but they rebranded I forget exactly how long to Miro because maybe those copyright things are just they wanted a unique name. I don't know, you can ask them, but anyway, they Yeah, so Martin's written

an ad in for that. Other people have written plugins that basically take an event model and they and it interrogates it and creates all your tests for it, I like for your solution, which is really cool because yeah, these given when ND tests in the style of a specification by example BDD style tests are really good with

event solutions. You just say, what's my given You always say, you know, your setup is always a set of events that you can just pull directly from the event model, and then your when what you're testing is the command that you're trying to poke the system with, and then your assertion is always that you it spits out the

event you expect. So it's really awesome and in fact, actually there's another benefit of this is that things like integration tests and acceptance tests, we've pushed them to be subcutaneous and then have the green boxes from an event model and kind of capture long running processes. So we've kind of shoved all integration testing to be just a unit test. So even if we have like a end to end test of some long process. The projections that

we use encompass that. And because there are pure functions, these run within seconds, so we don't use any mocks anything like that. It's just all poco pojo, whatever your

language is. There are all the property bags that sit there for setting things up, and in fact there's a highly kind of opinionated way of doing things, to the point where I'm thinking that most people will rewrite their own test harnesses for unit testing, because you're taking slices of a history that you can predefine as in the ray, and then you can take slice length of zero from the top to say, what's the default view of this window, and then you take the next one that's your next

test case. Okay, what happens when this event's in there? Does it change anythink great like that you can assert on that. So it ends up being quite quite neat, and in fact, below each slice in the event model we do have like an alternate little timeline that points downwards, and there we have a different sample of events and happenings that are particular to that workflow. So an example will be an invoice. The event model kind of wants to show me the happy path of how the system works.

So you don't want about twelve different steps to show just how differently the event the invoice can look. It's just gonna take up way too much real estate. So we kind of go downwards and say that, Okay, here's some scenarios of like if you have a discount code, you're shipping to a different country, et cetera, et cetera, all sorts of different things volume, discount, reward points, whatever. You can put those events to make different scenarios down below.

So you're not kind of polluting the space of the general idea of what the system does with the event model, but you're diving into those nitty gritty specifications that you need to build a robust system. What's really interesting about this NAI is that when I did this on the stream just last week or two weeks ago, I took a screenshot of that set of events and on the side, what does that invoice look like? Along the way is

an arrow down. I took a screenshot of this an incursor AYI, which is a fork of vs code, pasted that into the chat window and say finish the tests, and it did exactly that. It made an addition to the test correct first try. I'm not kidding. First try, I was blown away. So yes, AI hallucinates, but not when you give a good specs relation like yeah, and we know what's more interesting is that AI has been trained on human interactions. We talked about stories, we talked

about timelines. Guess what happens when the thing that you show it or ask of it is following storylines the things that it's been trained on. It's been trained on conversations. Conversations are like stories. So I think that's why it got it spot on because the format of what I was giving it wasn't the mockup of a UI. It wasn't anything weird like UML diagram with entities connected in whichever way. It was a timeline, and we showed how information changed. It got that on the first try. I'm

not kidding you. You should try this yourself. If you're wanting to test where AI hallucinates where it doesn't, I can give you an example of where it does not. And it's these things of these given win then specifications or in the case of state views like I just have given then because there's nothing to test like given some events. This invoice will look like this. There's no action, so slightly different take on it, but the main way

that it works as the same. So I've been floored just by you know how much this helps in the whole AI thing, just by having a better structure in terms of how you think about your systems, Like you get way more help from these tools. So yeah, I don't mind.

for me. I think that's what we've secretly wanted, and I think that's kind of what fell out of event modeling. So just like UML, I mean I talked to Grady Butcha last year in Hawaii or was it the year before, I forget anyway, he lives in Maui. It does really good work with conservation of whales and all that. But he's he's really interested in how UMLGA kind of taken away to be a case tool to generate code instead

of being a general notation to do that. And I think the UML two point zero folks kind of went and said, we can build a business around mL to create solutions kind of for free or buy the business. And I think, I think what you're taught talking about, Carl's kind of this this approach of like, hey, we can take you know, a human recognizable way to talk about a workflow of information and kind of press go and it'll do it.

not for the same purposes anymore. That level of abstraction is being bumped very hard right now up again, right just like we had from you know, assembler to compiled

languages to whatever interpreted languages, et cetera. So I think the same thing's again happening out of very rapid pace because in essence, I think AI right now has really just taken what we do with stack overflowing Google searching from four hours to be four minutes type of thing, right, So that is the affordance of the level of abstraction.

So you know, when I'm when I'm taking a snapshot of you know, some sticky notes on a whiteboard and putting it into cursor AI, and it's giving me the code, that's you know, I can feel the change, right I can. I know that that would have taken me to write those things wouldn't have been you know, a second or two or three or however long it took the chat to produce. It would definitely be taking minutes, an hour or whatever. And it even caught something that I there's

an assertion in there that I didn't think of. And when one of the events was uh, you know, this was for a conference organizing software, and it was I'm going to change the name of a room because I'm adding rooms to set up the conference. The assert that the AI ended up putting in there was make sure that the old name doesn't exist in the collection already.

I missed that, Like I just wasn't thinking, and I'm like, oh, yeah, right, of course, Like I could definitely have a bug in there where instead of renaming, I just added another room and left the old one in there, right, or something like that. So that's a really good assert and it

did it for me. Okay, that's really good. So we all have like spikes of being really good, but we also have things when we're not on and we'll miss things, right, And I think AI draws a kind of a safety net at the average, so if you ever make a mistake, you're obviously falling below average of what's out there, and

the AI will catch it for you. So you know, if you're expressing things in a story like manner and you're really in tune with what AI has been trained on, I think event modeling because of its story like nature, the way that these things are specified, they have basically given a very low probability of hallucination with these things, so you could go incredibly fast asked with event modeling

and event sourcing. Event sourcing for the point that you're working with, you know, multiple purpose built models for just that one workflow step, which is a very finite scope. And I think AI does a tremendous job when the scope is finite, Like really you know it? Yeah, if you say, hey, build me an online store, it will, but it's probably not what you're the one you're imagining, right.

helps our entire community. There's also a discord group that we have if you have questions about this. Martin, myself, all sorts of other people are there to answer questions. It's a highly active group. Is messages there every single day about this stuff. So if it's event sourcing or event modeling, even domain driven design topics pop up in there, anything around this whole way of working, you'll find good people there to help you. I'll be there to help

you if I'm not. There's others, So thanks guys for having me. And yeah, we have workshops too, so all sorts of things on that site. I hopefully we will have a few. Actually, we also had our first event modeling conference in Vancouver and one in Germany this year, so starting to grow. So anyway, we'll have to have your booth that one of these when we grow big enough.

Visit our website at d O T N E t R O c k S 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.