Adam Dymitruk - Event Modeling (introduction talk)

[Music] [Applause] welcome everyone to the event driven microservices conference 2020 a virtual conference because of our current situation it's a big pleasure for me to present the keynote about event driven systems it's uh it's something that's changed the way i work over the last uh more than a decade now i come from a long tradition of software development from the 80s all the way through to today so um my name is adam demetric and i've been working in event driven systems like i said for quite a while and there's been an incredible amount of insights gained by thinking about events and how we understand our information systems around us we kind of can see now that human beings have kind of thought of uh information systems as records of account for for a majority of what we did throughout our history this gave us quite an interesting insight so through this conference we'll have many people give examples of the advantages of writing systems this way constructing systems this way and having basically uh a much more human way to think about larger more complex solutions that you have to automate and i'm trying not to use the word software here because we really are talking about the entire system the usability everything that's involved we'll see how by getting the technical sides to be in sync with how we work in putting together information systems in any kind of way that it's uh it's a big advantage and removes this mismatch that we have sometimes we're looked at as geeks that don't understand the business and i think that's a indication of a bigger problem within organizations how we communicate and organize and so this is one really big advantage that i saw with event driven systems from the very beginning and once i switched to writing systems with event sourcing specifically for myself we'll get into all the different topics such as ckrs domain driven design event sourcing uh event storming event modeling everything to do with events uh we'll we'll have at this uh at our conference so hopefully after this presentation uh you'll stick around for um all the other people that are presenting and see their uh trials and tribulations as they introduce this better way of thinking uh personally i switched my entire business to only uh work off of event-sourced solutions to have a record of account for everything that's done in the system it's been a tremendous advantage uh technically but also from the business perspective many clients that we have um like the fact that they have a a trail of breadcrumbs as to how they got into a specific predicament when inevitably problems arise in our systems from whatever source another interesting thing about event driven systems is that no business is static so if we look at the traditional way of thinking about systems we if you go back to uml or anything else like this and object-oriented programming and traditional three-layer architectures we we try to do a job of capturing and encapsulating that business in a set of objects or something that represent how we understand it now um well that even even if we're correct um that abstraction is almost immediately stale so event driven is a is a way to really give a count as to what's going on any particular time and not be tied to what we thought the best abstraction was somewhere so it's a very natural way to progress alongside with business and keep up a proper account of what happened along the way it's also a really good way to integrate separate systems to rely on publish subscribe as you will definitely have some presentations about kafka and other technologies to be able to broadcast what one system is doing so that other systems can react and really have what we generally have in uh in the real world as human beings when we subscribe to a newspaper we have a source of information and then there's the consumers of that information so we have natural patterns by doing event driven and so this has greatly affected as i said how things are how things are done in my uh organization uh to the point that we had to develop our own way of doing specifications because that old static view of uh what an abstraction is and what we want to do is much different uh when you're doing things in event-sourced ways so we had to come up with a a better way to uh show uh or collaborate on on requirements and of course there's a lot uh of prior work to uh to get people into a workshop to collaborate together and that was a lot of work done by alberto brandolini with uh event storming where he had a lot of people go in and and basically collaborate from from a number of uh different disciplines if you're a product owner if you're a developer tester um all the way up to ceo of the if the organization is in the right structure to allow for that so and depending maybe for obviously a startup that's a that's something that you would naturally do so getting that collaboration having people together to really not do things behind closed doors or in silos was really eye-opening the story aspect of it came from greg young who did a lot of work in ckrs and event sourcing and being able to talk about long-running workflows as a set of events over a timeline well putting albertos and greg's ideas together gave rise to event modeling which really is about you know the thing that we can relate about systems is that if we talk about stories we'll have something that everyone can relate to and so event modeling is my contribution to how we think about event driven systems so i'd like to take you through a set of slides uh quickly and then go through some of the tools and techniques and other resources that you can use to help you and yourself and your organization uh do similar things and have another tool in your tool belt if you will to to tackle some of the problems with either in your own organization or if you're consulting to help your clients out faster in a more human way so let's see if i can get the zoom sharing correct i had a little trial run before let's test out how i can present okay sharing the presentation now all right so i call this event modeling with 1l simply because that's the less common spelling so if you google for this you'll be able to find everything that's written about the subject [Music] as i said that's my introduction if you have any questions about this particular presentation or any topics that i touched on here your feel free to reach out to me on twitter there'll be also other places like slack channels that i'll note and show so as i said the human mind is a very uh interesting advantage that humans have over the other animals and that really makes us different because uh what we can do and i think there's some research showing that some animals can do this but what we do is we can save our memories and instill them in the next generation so civilization is built on this we simply don't have to reinvent the wheel every time we have a new generation so information in societies is key if we understand how that developed in the human mind through evolution and how we became had this advantage we'll understand how to build systems that are in a way that's more advantageous for for us because we'll be using the same mechanisms as uh as we had so one of those interesting things is that this is a ledger for trading back in the 1800s but um the human mind if we go back to this how did that first occurrence happen when we passed on some information to the next generation well it's usually some stories usually it's a tale of what happened to a previous generation or some you know great warrior or any any if you can imagine cavemen sitting around a fire and drawing in the sand with a stick to tell a story painting on a cave a series of pictures depicting how to hunt or verbally talking about a fairy tale to a child all the way through to the bible so this happened well before the written word and and it's our mind's ability to to take a few cues take a few key frames and be able to retell an entire story so even a five-year-old child can remember a story of hensel and gretel or any of the other favorite hills um and you know you probably didn't need to study that fairy tale until you had your own kids and somehow you were very quickly able to pick up what the story was and make up the in between pieces but the same story continues through generations so the idea that the human mind can store a lot of things is taken from these cues of key frames and we'll see how event modeling takes advantage of that that these keyframes are very very strong they're very small pieces of information but they're incredibly powerful if we just trust the human mind to fill in the blanks we really reduce the complexity of how we talk about systems so this will all make sense together at the end of the presentation but it's really important to see and be honest to how how humans can relay information uh to one another um in larger organizations or you know from different roles so we see a lot of this evidence in once we get formal systems such as organizations and companies and this is a trading ledger from the hudson bay company in in north america i believe and it has uh some sort of record of account of what the prices were for beaver pelts and things like this you can also see that inc was one of the first ways to paint so we had a very permanent way of talking about information and we just ended up adding more information rather than having a pencil um and and uh with an eraser now there are some clay tablets where the clay on purpose was not um hardened and you could erase it just by pressing down on it and reuse it again but those are the exceptions for the most for the most part information was put into some sort of a ledger we always used ink so it was an additive only process and we'll see how that relates to for example event sourcing by not storing a particular state and changing uh those entries but rather adding more entries and then allowing the analysis of what was entered to to make up your mind as to what state our system is in our part of our system is in so hopefully that makes sense for you to see that we have already had a lot of this way before we digitized anything one of the key insights that we gained in um uh in the early days of computing was in the mythical man month by fred brooks where he liked you know he could appreciate all of the fancy flowcharts and algorithms that we do but ultimately what would tell him what the system does is by looking at the state and seeing what's on disk seeing what's in the tables in our case it's seeing what events have been stored those are the things that will ultimately determine what the system does so information systems fundamentally are about information and fred brooks had this nice insight into it back in the 60s so none of this stuff that we're talking about is really that new these are really really old concepts and what we found is that just the computing power around us has made it made computers way more ubiquitous and that that level of being close to them we're not an arm's length anymore we don't need as many interpretations to do something with computers so it's kind of time to go back to the way we were because we don't have to make special amends for computers we'll see how traditional architectures kind of did that i kind of were forced to do that you know there's another presentation that i do where i talk about where i talk about uh the storage problem and uh moore's law but looked at from the perspective of storage that we really couldn't at the beginning of computing store everything have a ledger because hard drives were expensive um in 19 in the 1950s an ibm hard drive was a million dollars and that's not inflation adjusted uh weighed a ton you know and stored 10 megabytes so if you wanted to store the old address for your client as well as the new one well you have to have a very strong business case because you don't want to have to buy two of those hard drives you only wanted to buy one so everything that we see about how we organize information in computers is kind of um it's based on those early years of uh needing to make some sacrifices with what we have to do with information now there are backups and things like this obviously but the key point is that it wasn't online information so absolutely i could go manually find some printout or some backup and see what that old address was for my client but you certainly have to have a strong business case to make it online so i could just see that um see that old address at the press of a button um so i encourage people to look at what fred brooks has talked about back in those days and and see that state is really a powerful way to think about systems and that code is really just a means to an end and that's quite important to how we evolved from what was good for static systems that needed to look at a specific point in time to something that's more dynamic and has evolved over time which is event modeling so as fred brooks said show me your state well let's even do better let's show how we got to each state so we do the specification by example to get storyline this is uh a system that is my canonical example of uh a hotel uh an automated hotel where people can check in book rooms rooms get clean um people come and go and the reservations are made and we have sales report but interesting thing is that this blueprint is done over time and this goes back to my initial slide about how humans are better able to think about stories and be able to record recall things so when we walk through if you're teaching someone a new concept it's always nice to be the example set the example uh show them how you do it and then they can see what's what things you do in what sequence and they can copy it and that's that's essentially what we're we're doing here so whether it's telling stories whether it's showing techniques whether it's uh seeing a series of images of progression our minds are built to consume this linear progression and and so when we present a system instead of a bunch of static boxes with many arrows going different ways if we have this sequence over time sort of like your version history for source code you know it only moves forward for the most part and and you can see where how you got to certain places and why and there's code comments on there and shows you know commit comments i i should say uh it tells you why things changed right we're not just looking at this as a bunch of entries that we uh use a pencil eraser to take out the old entry and put another one in we're talking about you know people leaving the hotel room people registering there's business there's business language this is what our business is doing our organization is doing and we're and we're capturing that um there are some projections that are your typical tabular ones or you can have graph databases or anything else you like which are our green boxes that are projections of the state you know our room availability we certainly don't want to read a whole bunch of uh you know statements of account of what happened with people you know leaving and coming going to the hotel we just need to know what right now what is that room availability but it's important to see where that information came from so it's quite important um so specification by example is traditionally known as a act range assert given when then and a few other flavors depending on where you're coming from even the ui ux people have an intention val situation motivation value i believe is what they have so in each discipline we have this going back to this by example and uh and so if we if we actually have a blueprint that satisfies the ux and the ui and the actual logic people will be able to know what's going on now for complex systems with a lot of background tasks and automation where there's really no view um we actually want to have these little gears that i'm showing here that these are processors that we show on the timeline and in the real world maybe there's a little spinning circle as you're waiting for the system to do something for you but if you're talking about what the system is doing you need to show what transformation that the information is being subjected to how is it how is it logically being manipulated to have the outcome that you need and this has to be something that everyone can understand so as you can see we've really put in the emphasis on the ux ui so that because a lot of people are visual you know there's a certain large percentage of visual thinkers that human beings certain percentage of the population is and there's a lot of analytical people absolutely lots of them are programmers obviously but we need to satisfy both sides because that's what comprises most of our organizations people that are visual and people that are analytical so in an event model we marry the two so that people can follow along if they're more visual they can see the example data at the top i've left out the example data in here just for simplicity just too many things that that would be writing i did add it for some longitude and latitude the other thing that we've done is that we don't want to have a really large amount of patterns to follow etc we want to find out what the core small little patterns we have so we don't have to study a book of 100 patterns to be able to use something like this because then it becomes a niche thing we now have a silo of information and we have a really tough um tough challenge to teach everyone what to do so here's some more of the details you might say well yes our invoice might look you know might have 12 different ways that that it can calculate something um yeah those interesting parts of our domain we can explore with given when then and this shows those given when lens below an event model we'll go to some more example event models but we can show how certain views evolve with more and more events and we can graphically represent that of course this seems very formulaic and that's good that means we can automate quite a bit of this which we'll get into later on but this is essentially a way to still use that story like [Music] attribute of our brains just talk about a detail and what we're doing here is basically the yellow stickies are events and we can show more and more of them happening you just build up on the previous one and then below we can show what specific views or reports or screens what they're showing and what they would what change would happen with each additional event that we would do so it's very easy to deconstruct a complex problem by slicing up this uh set of changes to state and explain at each point why a certain change has happened so there's been a lot of examples of really complex domains where a 45-minute discussion in front of a whiteboard doing things by example has made it clear some of the largest companies in the world have used this to to deconstruct quite simply and effectively a complex problem but more importantly in a way that's consumable by many different roles in many different departments so that we really allow freer communication and more collaboration so that's why we have fewer patterns and as you can see we only have four state change state view at the bottom you can see that there's a state change a state view external state input and external state output really the last two are just a variation of the first two but we're talking about system to system communication either receiving or sending information if we follow these we can get a very nice velocity because we're continually using the same four patterns so the occurrence of these patterns will be very plentiful whereas if we start to talk about the details of implementation we talk about uh observer pattern and whatever else you have out there even enterprise integration patterns we really start to put a huge amount of information that we need to learn before we were able to commute communicate so the goal with event modeling is to take the opposite approach give us some simple patterns very few of them and elaborate more complex things on the timeline and spread that complexity out horizontally so that we can analyze it and that gives us some interesting advantages which we'll get into so this is one of the most complex ones a trading system uh automated trading desk system that was deconstructed the core part of it was done in two days follow-up event modeling sessions happened but it's a blueprint that this company now uses to continue to evolve the system and uh it really is like a blueprint for your house you know where the plumbing is you know where the uh where the electrical is and if you need something done on your house you always pull out this blueprint so that you know where you can uh what you can do which which walls you can uh drill into or where you can make an addition to the house so those are that's essentially what we're doing for information systems so it's making information system information system automation more like an engineering practice where usually we've been kind of throw things over the wall to the technical people and we'll just use agile to see how they're doing here we can be more responsible together for the whole system so it's a more more collaborative approach more dedicated it's kind of like small design up front instead of big design up front so we can do everything that uml was trying to do but without all the complexity and the details notice that we also don't look at you know which algorithms are going to use and how the code is going to behave we're strictly looking at what is the state of the system we don't care what happens when we press that button we know that we have an intention to register and that we only store the fact that we're registered whether this is running in scala or or kotlin or whatever language is really immaterial what matters is that if we shut the power off after that happened that's the truth that's stored in the system and it's really important to have that separation of the means and the end if we concentrate of what the goals are along each step of the system through time then we can allow people to be a lot more free to basically implement whatever way they want as long as the slas are met and the data is correct so it gives a tremendous amount of freedom [Music] and again we would want to have if we could put all of domain-driven design the contents of all the great books on the main driven side in people's heads we would do it in a second but we know that that's a lot to learn so what we need to do is find something that does the this has the same effect but does it in a much faster way because if i was going to give a couple of thick books about domain driven design to everyone in my company um it's probably going to get a month it's going to take a month for everyone to read it and try to understand it we're going to have a we're going to have hit and miss understanding and obviously some people may be too busy so after that month of initial reading it's going to probably take a year before we get you know 90 plus percent of our organization to be on board and understand how to use it i certainly have gone through many years at different organizations trying to instill the ranger and design across many different roles within the organization and it wasn't easy and so i asked myself how can i do this without that tremendous burden of having to learn so much and so event modeling is something that you can explain about 15 minutes you can say it's a it's a storyboard we're making a movie about the system we would like and we're going to walk you through what that looks like it's as simple as that and so we need to now concentrate on actually practicing so you want the explanation to be very short and the concepts to be easy to understand so we should be able to get pretty pretty familiar with what that is within 15 minutes but then use the rest of the day to really become familiar with it through practice so those two timelines are very important to consider if you're wanting something in your organization this is very important when you're moving a new organization to event systems you're going to have to worry about how long uh something is going to take to teach and there's going to be people that are not interested there's going to be people that actively don't want to change and there's people that actually want to change and you have to really think about um what you're using to do that so i'm hoping that event modeling gives you a very fast way to gain the goals that you're looking at through user story mapping through domain driven design through all sorts of other uh disciplines and and practices that that you like but that you have another method of doing the same thing and it could be as simple as having a napkin over lunch that you're drawing with a pen and you can draw a few screens and write down a few events over a timeline um so if that's usable almost immediately to actually implement some of the system that's that's great then your the business person you had lunch with can see that that particular piece of the workflow was automated so what did we get from planning you know we had this big design upfront problem back in the day and um it was quite onerous and actually came from the legal side of the business where the people that are specifying the system couldn't be the same people that implemented the system so he had a fight for the budget and so um this is where uh this is where uh waterfall has a really bad name but it's really an abused waterfall the history that we have so it's always a scapegoat for agile but small design up front really does give you a constant cost curve especially with event sourcing and and other event uh driven ways of dissecting a workflow so what we found is that if we work with an event model if we talk about what events are going to be stored in the system when they're going to play with different you know come into contact with different screens etc we notice that we're removing rework so in the traditional way of developing we would have maybe a registration screen where if we're now doing email recovery or sorry password recovery or a verification code we'd have to go back to that initial registration piece and and change that table to now maybe store that verification code a number of retries and things like this so as we add more features we add a rework and these stack up so this is usually why we end up with a death march to projects where we have this you know things are really on the green field project the first two weeks first two months are wonderful we're uh we're getting features out you know three four five features a week even more but once uh six months or a year or two years rolls by it's it's like moving through mud you can't get a feature in there and that's because we have this coupling and there's another thing that event driven systems do a good job at if done properly is that they have a good handle on where the coupling is and how you avoid all the bad coupling which gives you that really bad red up curve here in cost so the more system the more pieces that are interacting the more relationships you have to analyze and so that's where the complexity goes however if you concentrate on state and have a place for each piece and where it's going to go you reduce that rework significantly to the point where you can follow open close principle almost to the letter and you can also see it from a business perspective so that open close principle is not a technical uh concept it's an information system concept and this is where business work will appreciate what you're doing that you are talking about not having to add extra expenses to rework things because you have the ability to say i'm done with this feature and really unless my requirements change i don't have to crack open that code i can see that piece of the workflow already working for traditional systems this is quite important for us if we're doing event driven architectures and we love doing all the pub sub and all the things that uh you know that really works for us we have ubiquitous language we we have we have different models that we that we employ for different purposes so we don't have a canonical model that gets rid of a lot of some of the bad coupling the reality is that most of the world is still traditional so the last thing that i'm adding with event modeling is talking about event modeling for non-event driven systems and you'll get so so much further ahead if you have a bridge between traditional and event-driven systems sometimes we're in a bit of an echo chamber talking to another i know we're trying to perfect our craft that's great but at the same time we need to be building bridges so that we bring onto our side uh all the people that want to build systems in a better way so event modeling works uh the same way for traditional systems the only thing we're doing is the views of state and the commands which are green and blue are your sql statements uh it's interesting to show how the coupling you know happens and that if we if we were to uh do the user registration that that code part wouldn't be in that table so this is that example of cracking open something that we were finished with and that's a simple example but these can get much more complex so the idea is you know these events don't get stored in a traditional system right they get thrown out but this is the truth this is what was in the user's mind when they did that action to register you know they in their mind they know what their password is um the system is actually storing the hash so we start to see where we have the mismatches in terms of what state we store how our system acts with what the person was trying to do with the system and that's quite important so in a traditional system that's not event driven these these orange stickies in this case get thrown out you don't have um you don't have that in your implementation but sooner or later some people will start to ask you know why are we throwing away the information in those orange stickies i get it we have our ruby on rails and we're going fast and we have these tables in our orm but i'm looking at this event model and saying you know is there an advantage to keeping this around because i'd like to see you know what the old verification code was or what the old email was for that user right now i'm trying to even you know get old versions of the source code to see how that happened well with events on uh with event sourcing this this is particularly for event sort system you can talk about the advantages of keeping your events and and how um how that's an advantage of course there are challenges from moving someone to to this way of thinking this way of doing things as you get more and more events people say that it takes a long time to replay them and find things so you still have problems of organizing information they're just different they're not harder but they're different here you can show exactly those differences and what the system would have to do if we were to keep those around so hopefully this gives you a way to uh transition people from traditional architectures to event driven architectures where you can do your microservices and all the decoupling that you want and be a polyglot developer but yeah the one of the things that i i bring up is that uh with with an event source system that's done this way and and uh and actually planned this way is that you can start to really mix and match um all the different types of uh technical stacks together even in the same workflow for the same application simply because that amount the the rework is is removed so um if there's any real changes in the uh in the requirements you're replacing entire workflow steps so there's no need to have a ruby person uh change your java code or vice versa you simply replace those state transitions new things like serverless are really good at doing these types of things so you know looking at this from a functional perspective a lot of people like functional programming and the functional perspective on this if we look at all the events that have happened over time we can start to whittle them down this is this is when we start talking about kafka topics versus event store fine grain streams and how we can start i usually start with event driven systems or event source systems with um just storing the event and not even having any projections at the fir you know when you're in the proof of concept stage you don't even need to have materialized views of some of the models you can just keep reiterating over those sources of truth that are the events now obviously past the demo stage it's not going to be very performant so we start to materialize those and actively listen to them and keep them updated whether it's in memory or on disk it doesn't matter but you start to make but you start to make adjustments for for performance the interesting thing about that though is that this the integrity of the system stays the same your actual event handlers and command handlers don't change which is beautiful that's when you can really show that you can throw different infrastructures on your problems but it doesn't affect your functionality that's a big advantage some things like aggregates and domain driven design when we look at it from a functional perspective we can see that really we have um a whole bunch of things we assume about state that we don't need to so for example if i was to close an order i really don't need to know what address it's at etc so we start to dissect some of those things that we learned in domain-driven design to be a little bit you know not not quite as as simple or performant as they could be so moving fro through functional perspectives and this is just uh one way that event driven uh changes even domain-driven design thinking where you can split an aggregate apart into a more functional paradigm and start to look at the events themselves instead of always artificially grouping them together just because they share the same entity id of whatever the aggregate root is so hopefully that gives you more ways to slice that up so when we look at some of our specific pieces of our event model we can also mark it up with certain things so the given when thens are interesting we have cross entity invariants and things like that we could really spell out why certain things cost twice as much to build to our business uh if you have a cross cross entity very invariant you'll have to show that you need to first get a view of of what the other entities have and then put that through into your command and and then do that so in terms of those workflow steps that may be two of these instead of one and so that's why some of our requirements may be twice as expensive these are just some examples the polyglot approach we we do this in our meetup to explore but we certainly can have multiple ways of uh implementing a system and uh the user will be none the wiser that that website that they're using even workflow steps that are very close to one another are are implemented in entirely different stacks they sit on entirely different docker containers with entirely different people working on them that's quite important from an organizational perspective this ability to dissect a workflow into slices gives you the ability to hire someone that doesn't have the same technical experience but they have domain experience so if you if you're in the inventory management kind of uh domain and you have someone that's worked at you know automating the amazon warehouse but they're highly skilled in ruby but you're a you know you're a java shop are you going to send them on their way or are you going to allow them to to come in and contribute to uh to your solutions so we all of course we want to hire that person and we don't want to force them to learn a language they're not efficient in unless they of course want to that's fine but we start to see that the polyglot approach is not as expensive as it is with traditional approaches where you can't have this segregated way of doing these workflows now you can to an extent but it's a lot easier when you're dealing with um with an event driven system event source system uh where you've really lined up state transitions as these slices and you have command handlers and event handlers that are quite um isolated for for being you know automated on their own they really don't rely much on anything else besides state so there's many advantages of that and this is just scratching the surface of this there's some things you want to share besides the state such as templates for some html and other things but you certainly can come up with a scheme where you allow this to to go across multiple programming disciplines at least so looking at this how does this blueprint help everyone else well the top swim lanes really help the ui ux designer but they're held accountable to what information they put into their mockups right they can't just dream up crazy situations that are gonna cause the developers headaches and you know they'll come back after two weeks going this is impossible we don't have the right information so having the ability to work with ux ui people collaboratively about what information is there uh is is incredibly uh important the architects they look at the swim lanes we have inventory authentication payments and gps in this particular one so architects can look at timelines for slas input output um what what is in the what is actually getting stored they can start to analyze storage requirements all sorts of things developers can develop every vertical slice at a time so this is very important because from the pm and the developer side these give you a really good velocity to the point where we only do fixed cost contracts because once we have an event model we have a really good grasp on what the project's going to uh cost and we put you know our name on the line saying that this will be done for this amount because hey if we rush it we have to fix these things for free if it's not done up to spec you have to fix it for free of course there are changes with requirements that's a different story but at least you have a quantitative way of saying what the changes will cost so if the if the client or the organization wants to change the requirements they have a very natural change management process here where they basically hold up one blueprint versus the next and they can see which parts are already done which will require rework because you're going to have to remove those pieces that no longer apply but the ones that aren't implemented yet well that's a free change and you specifically see how that state is done so um qa obviously has a very easy way to elaborate stories they can mix and match to see if there's a bad actor in the system as well so even from a security perspective if you have a security auditor if they understand how your system is used they're not just blankly staring at apis who knows when they're called and how and why now they can refer to this and see that this is the way the system is used and now from a security perspective i can do some different threat analysis to see if if people can take advantage of a blind spot in some sort of different order that i can you know call call these apis and create a situation where i can do something um against this company so it's it's quite uh it's quite uh it's quite useful so hopefully this gives you some you know some thought and as you uh as you listen to all the presentations today and over the conference you'll think about how you can present all those technical concepts to to your clients to the non-technical people to your ux ui people whoever else whatever other teams you have i'm hoping that through event modeling you'll be able to have something that you can rely on throughout your project not just at the beginning um to to collaborate once at the beginning but you continue to use it to reference uh as a map later to find things it acts as a blueprint and then as a map to find things so um it's uh i'm hoping that uh you get some use out of it there's a book coming out on this and there's all these different ways to get involved in this event modeling i can show some of these right now as well let me just stop my sharing for a second here and i can show some of these [Music] all right so of first resources we're looking where can you read in depth about this so i'm going to share my screen one more time [Music] and here we are so the first place to where you can find a lot of this information is in the event modeling.org website in the main article which was the main blog post what is uh event modeling what is it and it has all the sections that uh uh that that we talked about but in a lot more thorough explanations so we go through a very detailed way of explaining each piece that we talked about we really didn't have time to dive into all of this but i'm hoping that as you look at how to hold our event modeling workshop how you evolve and build one with people in a nice structured way um how you can do the project management by counting which slices have been done uh analyze that cost curve because this is gonna save your bacon quite a lot of times on projects it's quite a good one to understand and and many other things including legacy systems so how do you go from a monolith to some sort of really badly coupled monolith but monolith itself is not a bad word but but you know where there's a single canonical model inside etc and code you don't understand and it's walking on eggshells to change something those are yeah how do you apply event modeling to show how you're going to sidecar a new event source solution and uh not have to swim in that code and start to analyze it scientifically and uh and and do that so i have a nice example here of fixing a bug and adding a feature to an existing system and uh and yeah so that's uh that's the main article that is uh they're gonna give you the most uh the most information about this uh we've been using amiro for a time tracking application during our meetup so you can you can join us in our meetups if you like to to play around with uh with our with our time tracking application and over the last year or so a lot of different companies have been looking at automating this to generate code but also to have some of those opinions so oh note is the latest and greatest in that way where you simply can drag new events up and call them whatever you like i'll just say example because i can't think of one right now but more importantly if you need to show a particular command that will jump up notice that there's notice that we can only drop them in certain places so it has some guidance as to how to do this so you have a tool that will guide you to do it correctly and so also the connections are as they're supposed to be we have this cadence commands going live end up as as events events can only be looked at by read models this is quite important to to ensure that we follow those four patterns that we that we showed before um remodel or view i like to call them views because i don't want to explain to someone what a read model is but some people just know that the view of state is something that's a report maybe so i try to use common language so not to confuse others or have to make them study some more things before we can communicate so as you notice we can't [Music] we can't connect a command straight to a read model the nice thing is that this saves uh you know to json so you can transform this to any code that you have so if you have boilerplate code and you have a certain way to do command handlers and event handlers already you can you can do that so this is pretty exciting there's lots more there's other companies that are making uh code automation from an event model because nice thing about an event model is that it gives you information completeness in other words all the example code that i have in here has to make sense i can't have some data up here out of nowhere so this audit of information completeness is incredibly powerful in event modeling because before you start a project if you have some assumptions well it would be nice to have those answered so that your project doesn't blow up with some detail that was omitted now maybe it's on purpose maybe it's by accident but we that information completeness of knowing where things come from and where they're going and why things are displayed um that gives you an ability to have a very good estimate which has been really hard to do in software so for the first time we have estimates that are reliable because we have a good way of treat uh tracking velocity through a small set of patterns and also being able to show that we're information complete as we like to call it knowing where all the information is coming from and where it's going to a real good way of doing systems thinking that rectangle that you control and everything inside it understanding where there's inputs and outputs and be accountable for all of them so that's a really good tool to to use and i hope you will check it out and then our meetup happens twice a week generally unless i'm sick or just too much work but generally tuesdays and fridays i'm on the pacific west coast of north america so i do that in the morning so even if you're in europe you can stay up and join us online everything's virtual these days as is the conference so um it says vancouver bc but uh it is a virtual one that's all over the world now so i hope you uh i hope you join us that's where we uh do the event modeling for time tracking and do some cqrs and event sourcing implementations talk about domain driven design concepts microservices we argue about event sourcing and what that is and what it isn't why kafka's good in this case and why you want to use something else for another case so really exciting topics that we like to talk and discuss about and that we try to put those on youtube as well so [Music] as far as resources the eventmodeling.org resources the resources page will have slack groups some of the intro videos that you have some example code some laptop stickers i have some new ones actually that i should show but that's uh that's pretty much it so the new new event modeling stickers are kind of exciting because they're they're done in uh breaking bad style so if you look if you remember that show we have the secret sauce to making good information systems that's why we borrowed that concept of the chemistry from uh from from the breaking bad series for those in europe you should check it out if you haven't seen it yet um but i hope that uh you have had um some uh interesting uh insights into information systems and how you can talk about them more freely and more widely with with others in your organization and how you bring some of the technical concepts up and into general concepts that the whole uh that the whole organization can share responsibility for so um that i think is my best contribution to this entire event driven world and it's a fairly new concept the book is on its way and there's many other uh workshops and other things that we will be doing um it's the only way we do uh requirements with our clients for any project we simply don't want to start a project if we don't have a good idea of how it's going to treat information and if we don't have a good example of what success looks like that event model is the story of your complete system of running over a year or something like that and you can hold it up to the light against the actual solution you produced and see if you succeeded and that's a great advantage everyone knows what's going on the costs are fixed it's it's very transparent we always invite our clients to talk directly to our developers because they're they have a way to communicate without needing translation so we don't hide behind technical concepts we can talk about state in a way that's uh that's generally understood by everyone so um welcome to the conference and i hope that uh this gives you a little bit of an extra uh tool in your tool belt uh but the remaining um the remaining uh talks are going to be quite interesting because you're going to hear from a lot of people and their strategies of how they were able to succeed using event-driven microservices in organizations that were doing it for the first time gonna learn about all the uh troubles that can come up and how you're you can uh get around those through their experience so i hope you stick around and uh look at the uh the entire conference for uh for all that it has to offer and uh i'll be in the q a uh chat so i hope to see you there and um i'll answer anything else but uh from here welcome to the conference enjoy your enjoy yourself and interact with uh with all the speakers they'll be around during the presentations so thank you so much for having me [Music] [Applause] you

Channel: AxonIQ

Views: 2,299

Rating: 5 out of 5

Keywords: event modeling, microservices, eventdriven, conference, cqrs, Eventsourcing, UI/UX

Id: UYJ83me8O58

Length: 56min 53sec (3413 seconds)

Published: Thu Oct 15 2020