The Many Meanings of Event-Driven Architecture • Martin Fowler • GOTO 2017

[Music] almost my entire career i've heard people talking about event-driven architectures and event-driven systems and things of that kind and it's always been a little bit odd as to what what actually do people mean by that because when i dig a bit further it seems that there are various different things going on there is some kind of common theme events are or something called an event is an important part of what's going on but actually what it boils down to in terms of something more meaningful that's much more open-ended and for a long time that's just been ticking around in the background and i have at various points in my career sort of thought i want to really dig further into this and i kind of never really got around to it because i dug into other things instead but it really kind of came to a head late last year at fort works we've been doing quite a lot of event-driven stuff and various people came to roughly the same conclusion as me saying we've been doing all of this stuff called event driven we're not really quite sure it's the same and we're doing it at all these different project teams around the world because there's a several thousand people now at fort works and lots of different projects we need to get together and learn from each other so we organized a workshop in denver it was yes denver um late last year and a whole bunch of people got together and very quickly it became apparent that yes there were some very distinctly different things going in under the title of event driven and we need to try and figure that out a little bit better and as a result of that i think we came to a bit of an understanding of some common patterns that help provide a bit more precision into what we're talking about and so we thought well it's important that we describe this and say a bit more to the rest of the world about some of our thoughts and i hope really hard that somebody else would write it up and nobody ever did but one of us did a little video thing just for an internal video what's it and i thought oh i can't stand it anymore so i wrote a little note and stuck it up on my website not really expecting it to get much traffic and i saw it got downloaded with a huge amount of traffic so i thought well actually this seems to be a common problem and that's what led me to decide to inflict this talk on you this morning is because it seems to be that people are concerned about this and what it boiled down to is we identified four different things i would call them patterns that often come under the term event driven an event-driven system might you when people say they have an event-driven system they usually mean they've got at least one of these patterns in play and could mean they have all four patterns in play and i will go through them one at a time gradually revealing what they are so to begin the first one let's imagine some example system that might be had by an insurance company and in this insurance system we have our customers and our customers have a habit of moving around and changing their address but the insurance imagine it's something like car insurance or house insurance where changing your address actually affects your insurance quote levels and your premiums that you have to pay in everything so if somebody changes their address it's not just a case of updating the address field you actually have to trigger the insurance quoting system to come up with a new quote and they then got to send you some mail to say here's your new insurance agreement and whatever whatever i don't know the details it's a long time since i spent any time with insurance people but the point is in a kind of simple call and response kind of architecture what that requires is whatever system you've got that's looking after customer management needs to tell your quoting system hey go and do a re-quote and the problem of that is that creates a dependency from the customer management system into the insurance quoting system it needs to know that it's there it needs to know what apis it has etcetera etcetera etcetera and that couples the knowledge of what how insurance quoting works into something that's a much more generic customer management kind of feature and that's a kind of coupling that a lot of people don't really like very much so one way we can get around this coupling is we can say instead of doing that let's try and reverse things around i don't mind my insurance coding system knowing about my customers and that there is a customer management system there that seems a more natural dependency line to follow because uh something that's very very generic managing customers generally that's the kind of thing you want to depend on and have it depend on lots of other things and a way we can do this is we can use an event so what happens is whenever the customer some customer data changes the customer management system emits an event object to some well-known place event queue or whatever and then the insurance quoting system can listen for that event and when the event occurs it can decide do i want to do something about it if so what do i do and then that nicely gives us that ability to reverse the dependencies allows the insurance quoting system now has to know about this event structure but the customer management system can be independent of all of this and this is an approach that we in our discussion whoops giving you a slide away there in our discussion we referred to as event notification we're using events as a notification system uh no notification mechanism between multiple systems now of course i've described that in terms of large-scale systems independent relatively independent systems for a big company but we also use this same pattern in a very small layer system and it's a classic of course approach of how to manage interactions between graphical user interfaces and the rest of your code when somebody enters information into a text box you don't want some very generic text box widget to have to know all about your code and which things to call instead you say the event the text box will generate an event when you change it and then your code listens to the event it's the same idea and again the same trick is you are reversing dependencies and that's really i think the essence of why you want to do this is that you want to do that reversal of dependencies now i've talked about this in terms of events and i've stressed this dependency switch but it does but it also does something else it bottles it sort of takes everything to do with the change that the event talks about and bottles it into a thing an object a record or something of a cert that you can refer to and pass around it makes the change a kind of first class thingamajig now when we do when we call a function that's just a very transient thing we call the function supply the arguments goes away we never know that we've done it unless we've got some logging and tracing going on but when we do something like this what we're doing is we're actually making a record of it and then we have a real thing that we can talk about and refer to and pass around and that has its own benefits if we once we can do that so we're actually getting a second benefit here which is this bottling it up into a into a thing into an object or i don't have to hesitate about using objects it doesn't have to be an object in a 0 sense i think of it as a just some kind of first class thingamajig that needs to be a new technical term first class thingamajig god i don't even get a giggle for that that's a shame now that's not the only way of thinking about these first-class thing imagings often we think of them in terms of commands as well and that leads to an interesting question well when do we have events and when do we have commands what's the difference between an event and a command and i think it's actually it is both very subtle not really anything that you can say is a strict definition and yet at the same time very important because it's about our language and our communication and how we talk about our intentions about things we could describe that situation i just described as the customer management system saying re-quote insurance for this customer that's the customer management system saying it knows what ought to be done and it's telling some remote system here's what you should do when i phrase it in terms of events i'm saying the customer's address changed i'm not expecting any particular response from that from anybody i'm just indicating a change both can be have this kind of bottling it up and making it a first-class thingamajig effect but the way the communication patterns differ is in strongly implied as different whether you use event naming or command naming style naming so really it boils down to this is one of the two hard problems in software right this is naming things and therefore when you're thinking about the difference between events and commands it's really how do i want to describe how the system works most accurately to the people who are reading about the system if i'm trying to say i don't really care what happens as a result of this event i don't want to care then yes i want to use the word event if on the other hand i am particular about i want something to happen then i want to name it in terms of a command now i mean you can get all the other way now you could have your insurance quoting system might insist on sending a communication an email to the uh to the customer and natural way to do that of course will be a command send an email but of course if you go too far down the event route you you then get this effect of passive aggressive events right or passive aggressive commands where you're saying the customer needs to be sent a message about their new quote hint and you know you don't really want to go down that path if you're trying to read how the system works that's going to be confusing when you get those kinds of events occurring so whether you use events or commands under the covers they're basically the same thing they're often messages on cues they look exactly the same the difference is all about naming but that difference is really important because let's face it names in software systems are one of the most important things we have to deal with so going back to our system again one of the nice benefits of using events is it allows many other systems to hook up to the event stream very easily without us having to tell the customer management system what's going on and this is a very nice property a nice result of using events for notification here i need to hook up a new system that takes advantage of change needs to know about customers changing their addresses i don't have to go and talk to the customer management team and get them to add a new no to no call into their interfaces and go to endless meetings with the customer management group and two months later maybe i will get them to do something no i have they produce their events i just tap onto the event stream i'm cool this is a very attractive ability and it easily allows you to do all sorts of interesting things without changing what's going on but when anything sounds like it's really nice there's always a but isn't that and in the case of event notification that but is now you're in a situation where you've got no way you can figure out what the hell is going on in your system anymore because there's no program to look at there's no statement of says these are all the things that happens when a customer changes their address what you have to do the only way you can figure out what's going on is you actually have to watch you address the various events and see what happens looking at the flow of messages through your system to try and figure out what the hell's going on and this is true in the gui case if you've ever tried to debug a heavily event-driven gui kind of system pretty much your only chance is to bring it up in the debugger and try and trace the various events that are flowing around i remember doing this once to try and figure out how the original small talk 76 worked because i was writing some stuff about model view controller and i rapidly discovered you couldn't trust any of the papers that had been written on it because i often didn't have access to the source code so i was able to get hold of a copy of the original mvc small talk 76 bring it up and i could actually figure out how it worked but i couldn't figure out how it worked by looking at the code i had to step through the debugger do things and see what happened because again it was all events and that's the dark side of using event notification you get this great decoupling you get this great flexibility being able to add new consumers and you get a inability to see what's going on across the system as a whole there's no code anymore that you can just look at and it's a trade-off like so many things trade-offs so that's the first thing event notification and that i would probably say is the most common thing that people say when they're event driven they're using an event notification mechanism somewhere which is kind of odd in a way because just about every system i've ever looked at uses event notification to some extent i guess when you call it event driven it means the event notification system is seen by at least the the senior people on the project as a particularly important part of the architecture so the second one is a minor variation on this case so let's go back to our little example of the insurance company again in an event notification system all you really need to know is that the event occurred and that could really be very very generic it could just be saying hey something changed somewhere you probably want to give a little bit more information on the event about that so you might say ah the event thing for linda changed something's changed about linda's account and then all the other systems go what's happened the way they find out what's happened is they have to talk to the customer management system and even if you got more precise about this you might say linda's address changed they've still typically the insurance code system has okay so what's the new one what was the old one you know has it changed in the way that's important to me event notification often involves additional traffic because the the systems that are the consumer system still have to go back to the original source to get more information and of course we reduce that burden by putting more information into the event if i just say something about linda changed then every time you have to pile in on and it's probably half the time it's not worth it doesn't actually mean anything so it was kind of a waste of time if i'm saying here's the address change then there's less traffic required because i only need to go in if i care about an address change and then i can take this to the logical final conclusion and say can i put so much data in the events that i don't actually need to go back to the host system so not just do i say linda's address changed i say what her old address was what her new address is at that point maybe i don't have to go back or maybe i do i know the address changed i know i need to do something but now i need to go back to all of other attributes all the other things i know about linda rising her browser history how often she stands up every day all of these things we know and we can find out by asking the customer management system but now i've got a customer management system that's got all of these queries every time something happens every other system is bombarding me with stuff can i reduce that can i eliminate that load well i could and this is a pattern that we tentatively named event carried state transfer which is a bit of a long-winded name but i like it because it's a play on rest right which is resource what's it state transfer this is event carried state trend this is about using events that carry stanford of state what happens when you use this pattern is you say i want to completely forbid any contact to the customer management system from the insurance quoting system which means the insurance coding system will keep a copy of all the data that it's ever going to need now that means of course the customer management system has to broadcast in its events all the data that those downstream systems are going to want to have and the downstream systems have to keep copies of everything that they are going to use i don't have to keep a copy of the entire customer record i only have to copy the stuff that i care about so it's not as bad as one might think but it's still obviously a lot of copying of data but the benefit is i now no longer need to call the customer management system at all i have all the data at hand so that might improve my performance because you know i no longer got remote network calls to the customer management system it reduces the load on the customer management system because it's not responding to all those calls it also may improve availability because if the customer management system goes down or it's intolerably slow i don't care i keep chugging along because i have all the data for myself so we can immediately see with some really nice benefits to do with that now it doesn't mean i have to do all the necessary stuff to make sure that i'm up to date i keep copies of the data it means of course i have to copy all the data but we're not talking about that much data these days storage is cheap and what's more i have my insurance quoting system my availability no longer depends on the customer management system so that's a good thing now hopefully you're well enough versed in software development that you know when people say i have greater availability because i'm not dependent on something else you know what the price is what's the price of high availability lack of consistency exactly so now i've got to replicate the data i have eventual consistency i have to deal with that issue so i've got a consistency problem so again event carriage state transfer has this um trade-off i get even more decoupling even more availability but i lose complexity of keeping the duplicated data and inevitable eventual consistency so this is a less common pattern i don't know what the proportions are i would say a lot of the time that i see event notification i don't see event state transfer state transfer but you and you do have to have event no event notification to do this but it is a technique to bear in mind i would say this is one that you keep deeper down in your toolbox but it's many circumstances it can be a good one to play so sometimes that's what we see when we talk about event driven systems this notification of duplicating the data to avoid calling back so the third item so far what i've been doing is i've been telling you the concept and then telling you its name because i kind of think it's more exciting that way you're kind of a bit more of course if you read the talk beforehand you already know what the four things are so i'm not really quite sure why i'm doing it but for this one i'm going to tell you what it is right away event sourcing which is a technique that is long been one that's fascinated me um and it's interesting to see how it's being how people are using it but let's begin by explaining what it is what do i mean by event sourcing by the way how many people have come across the term event sourcing stick your hands up to some curious okay smattering of people how many people understand it well enough they think they could explain it to somebody else a few okay i'm not going to ask you to come up on stage and do it don't worry okay here's how i explain event sourcing and surprise surprise is the change of addressing example again because i'm kind of boring so let's imagine i've got some kind of customer management system and i've got somebody with an address and they want to change their address in a typical system how do you change address you just say okay let's blow away the old address create the new address right that's how it works right nice and simple what event sourcing does is it creates this subtle change to the picture so now what we have is we still have this representation of the current state of the world but we've also got a second little area as well and when i say change my address the first thing that happens is we create an event object so this is this first class thingamajig that captures the details of the change and we pop that first class thingamajig the event into some kind of separate storage area then we process that event and we process the event to do exactly the thing that we expected to do earlier we change the thing over the consequence of this is that we've kind of now got two sort of representations of our world we have the what i refer to as the application state which is the current state that we're thinking of of the world and then we have a log of all the events that ever change that world and this is the crucial test for event sourcing the sort of the definitional test is that at any time we can blow away that application state and confidently rebuild it from the log that's the test i mean lots of people log changes and things like that it's the ability to replay the log and confidently rebuild your state so that basically you don't care about your application state and trying to preserve it anymore because the vital thing is preserve the log if that's the situation then you've got an event source system so how many people here have built a system using event sourcing this approach smattering of hands few hands how many people here have used the system using event sourcing a few hands not very many how many people here are software developers put your hands up okay i'm going to assume you didn't quite understand what i've been talking about for the last few minutes because otherwise we are really screwed all those people who haven't used an event source based system and our software developers if that were true i would be really really worried in 2010 let alone 2017 because every software developer should be intimately familiar with one particular form of event source system which is version control if you use git use subversion mercurial even if you use cvs and i have it was a long time ago but i used it you've used an event source system hell i use sccts you know it shows how old i am and this is i think a very good point event sourcing is basically providing to your users a system that works on their data the way version control works on your code that i find a very good way of explaining at least the software developers what event sourcing is about and a lot of things about event sourcing you can reason through by thinking well what happens in my version control system what does git do what does subversion do and then applying that same question to the application state that you're in in your version control system your application state is your tree of files your working copy um your work tree and the log is of course all the commits that have occurred through now of course the system internally doesn't necessarily store it as all events but it stores it effectively as it were all events there are snapshots that are contained at various points to speed up performance which is basically a copy of the entire application state as at some commit but by moving back and forth between snapshots and using commits and being clever about how that all into plays it gives you the sense that i've got every single commit which is kind of the same thing of saying i've got every single snapshot but it's slightly more powerful to think of it in terms of every commit now that's a good metaphor for us geeks it's not a terribly good metaphor for business people but fortunately there is another really good example of event sourcing in the business world that any business person will be familiar with accounting ledgers right if you're honest my current application state is however much money i've got in my checking account but of course behind that is every single credit and debit to that account and of course ledgers and accounting systems are used by all sorts of people and that is very much an example of this event sourcing approach and again notice the fact that it's a combinat in reality it's often a combination of every single change and certain snapshots a common thing in accounting is to say at the end of a year or something we would say we're going to close out the year we calculate all the balances for the end of the year and then we kind of ignore everything that happened before then and we build our events on point since then that's a snapshot effect where effectively you're throwing away history behind a point in that case um but it can also be you don't throw away the history you just use it to make it easier to calculate what's going on for this year's money and if you really need to you can dig and go further back so again the storage is usually some mix of events and snapshots done in some way that is efficient for your capability but you want to always be able to synthesize that recreation of the events so the question with event sourcing is how can we use this more widely because there are many interesting benefits but also costs with this pattern um immediately off the top of the head you can say well it's obviously a great audit system if i want to figure out what the hell happened or how how on earth did this person get sent this quote that was completely ridiculous i can look back through the events and figure it out and that's why anybody who's involved in audit really loves having an event source system that's why of course we have ledgers because that's one of the main reasons because of the audit it's also a fantastic debugging tool if you're trying to figure out why your application state got screwed up at some particular point in time you can actually take a copy of the system feed it the same events and watch what happened going back in time and of course the time travel going back and seeing what was the application state a month ago two months ago we're familiar from doing that from version control right and it's really useful to be able to go back and forth across time um the alternative state is also effectively branching and that can be very useful in certain circumstances um i've worked on a few systems where we might have notification events and we deal with them the example i always use is payroll somebody worked for 35 hours in a week we record that we send them a check we update their sick pay benefits the pension benefits all sorts of downstream stuff happens and then six months later somebody says oh actually it wasn't 35 hours it was 40. that's a really complicated exercise to go and then undo well not you can't undo because you can't change it but then to recalculate what the adjustments should be for all of that but if you've got an event source system you say okay i'll tweak that i'll copy it to a different system tweak the event calculate what the current state is look at the two application states diff them and do an adjustment i mean it obviously is a bit more complicated than my casually saying why do we just diff the application state but you get the picture right you actually get you can actually do it and it can be a long computation it can take oh a couple of minutes but that's way faster than doing it manually and that can be a really powerful thing last item on that on the list of good things is actually one of the most intriguing the idea of using a memory image this basically says if our long-term record of what's the state of a system is a log of events actually i should walk over here and give you this end of the room a treat force the cameraman to wake up if i do give that long-term view then actually i don't need to store the application state in any kind of persistent form why do i need to store my application state in a relational database if i've got a log of all my changes i can have a purely in-memory system and that has some interesting benefits a great example of this is a trading system called lmax it's a retail trading system and it was built a few years ago and it has to be very high performance very low latency and they looked at various ways to try and achieve this and they ended up with saying we're going to run the entire system on a single thread and java and their their headline was we can do six million transactions per second on this single thread really really blazing fast and one of the keys to doing this was all of their data was in memory now they have complicated transactions they have lots and lots of things to look at at once they didn't want to be going to a database they have it all in memory and they were able to process really really fast and if anything happened and the system went down they could very quickly rebuild the state from their application logs they would snapshot overnight so basically you run all the events from the beginning of today and work that way and in fact again one of the advantages events is you can have multiple systems running off the same event stream so they had a very good way of having hot backups they basically ran two systems all the time with one of them being the lead one and if it went down the second one would instantly take over very very nice system very very performant one of the interesting things i was talking with one of the lead developers and he said actually i mean the performance was fantastic and really got people's attention but one of the things that i really miss about programming in a different system is that is the nicest system i've ever programmed in because there was no database to ever deal with everything was in memory all the time and as a result we could have a really good rich model it was particularly good for complex logic represented in a domain model and it was a real pleasure to work in compared to many other systems um i'm surprised in many ways more people haven't taken that kind of approach it's a bit unusual and you have to set up the infrastructure to make sure that you're able to do the events with that but it is actually quite a powerful model and it may be getting more interesting as we get more towards systems that have large amounts of non-volatile main memory um because so much of us of our systems have been built under this assumption that we've only got so much memory we have to park everything else on disk and now we got tons of memory it all fits in ram for so many applications so maybe we should take advantage of that memory image is a way to do it but you still have to have some kind of persistent store and communication mechanism and the event log provides that so event sourcing can be very useful in that situation so those are some of the upsides but as implied there are downsides okay i'll go back i hope you enjoyed that not having to crane your neck for a while so it's an unfamiliar system that's bad because things are unfamiliar are harder to work with talking to external systems gets a bit more complicated because if i want to be able to rebuild my application state i can't just say oh i called this external system two weeks ago what was the result because i can't call it again two weeks ago i have to make sure i save basically every response from an external system as an event and make a partner replay mechanism i have to think about how do i store my events in a way that i can confidently replay them even as i'm changing the code that processes them so event schema starts becoming interesting to be able to do that also a little little thing but awkward when i generate identifiers for things i have to be careful that i can do that in a way that i can replay this rule that says i must always be able to replay the events build the application state there are these little tricks little traps for you early on that you have to deal with and you have to think through how to get through those so those definitely do add complexity and you get other complexity that typically comes along for the ride one of the triggers for doing this talk and the workshop was when i ran into people that were running into difficulties with event-driven systems but it wasn't clear what the source of difficulty was so i remember chatting to somebody on a project that was in difficulties and they were saying oh i will never ever use cqrs again i said oh okay you had a hard time with that oh so rewind got that wrong he said i will never ever again use event sourcing and i asked him why and he said well because every time i want to do everything i have this read model to build and the right model to build i have to do twice as much work and i thought well hang on that's nothing to do with event sourcing that's something to do with something else and you often find that people will mischaracterize where the problems are with event sourcing i've often heard this because the problem and the problem on that project according to the lead architect was asynchrony they processed all their events in an asynchronous manner and asynchronous processing got difficult for people because asynchrony tends to be hard to work with hard to reason about now there's no reason why you have to have asynchrony with an event source system when i just make a local commit in git that's not an asynchronous operation now okay when i when people are pushing up to shared repositories then asynchrony comes into play um but there's none of that it's all synchronous operations that i'm doing a local commit but often people take advantage of the event sourcing to introduce asynchrony into the system which can be a good thing because it improves can improve responsiveness but asynchrony then adds complexity and so the reason i put that as a kind of question mark there is asynchrony often comes along for the ride with event sourcing systems and it does add a lot of complexity but it doesn't have to be used you don't have to use asynchronous event sourced approach even though it seems common that people confuse that another issue is versioning versioning can get quite complicated in an event source system because of this ability to replay and particularly when you think well the code of course is also changing in this system over time if i change the structure of my application state and the schema that i'm using for my application state can i still process that event that was created a year ago what does it mean to create to do that do i need to change my event schemas and version them versioning can get messy again it doesn't have to be the lmax example i mentioned earlier on they didn't run into that problem very much because they only operated on a one-day snapshot and events from that snapshot so they didn't have to worry so much about the versioning aspects but it can be a killer for other systems um and i'll mention that there is a book in progress or close to some degree of completion by a guy called greg young if you look on lean pub about versioning for event sourcing systems where he goes into a lot of detail about the various options you have for handling event sourcing so handling versioning and event sourcing greg young is the creator of event store which is a storage system specifically designed for events he's been working in the event space for quite a while you can find a bunch of his lectures and things on video i've been trying to get him to write a book about event sourcing for years so far without success so if you ever do see him tell him to write that book so event sourcing is like most things a trade-off there are pros and cons there are some really nice advantages there are complexities involved i do find it surprising that more people haven't made use of it approach however one more thing to mention about event sourcing though and that is exactly what we record as our events in the event source think about the code example for a moment i go into my code i see some function with a name that i don't like anymore and i want to change it so i go and change it fairly straightforward refactoring operation how do i represent that change in terms of event sourcing there's two events going on here one is my intention change the name of this function and the second is all the actual edits that i actually have to do in my source code which is not of course just in one place it's the declaration of the function and everywhere that calls it now as far as any version control system i've ever used is concerned it only sees the latter it sees a series of textual diffs that have absolutely no way that you can tell the intention from that except by looking at the divs and maybe the commit message to say that's what i've done and we've talked in times of how it'd be nice to have automated refactorings that were storable that were first-class thingamajigs that you could apply across your project but in practice it's very difficult to do that because of course a rename function method uh function capability for that would work with javascript is not going to work with java he's not going to work with python so i have to language specific changes in my version control system that starts getting very hairy while text works with everything we know how to diff and merge and deal with text changes so we rely on text but then we lose the intention we lose what's the reason why same thing basically happens with business stuff as well we say i've got some intention of something i want to do and i might want to capture that and as an event and i think of that as a kind of an input event and then i have how does this affect my internal knowledge of the world which is a lot more detailed but also often loses important context and then there might be another kind of event which is an output event that says here's what changed over the rest of the world knows about it it's important to realize these are separate things and to think about which ones you want to capture which ones you want to store because you might want to store more than one of these if you look carefully at the slide you might notice we have a slight problem the code isn't quite right the total is wrong what happens to me fixing this bug i've got to be able to replay if i quoted that as the order price i can't just change it because i quoted it and announced it to the world but on the other hand i've still got to fix the berg but i've got to also be able to replay things start getting tangled again it's this versioning issue greg young's advice is quite firm he says don't have any business logic in between your event and its storage because if you do you run into this tangled versioning mess but on the other hand if i don't have the input event stored i lose the driving intention of what i'm doing because that that internal event can be pretty complicated and messy one solution of course is to store both and in fact i've seen that done with some of the events or systems i've worked in um the the canonical style that i that i saw back in the 90s when doing this was we would store the external event and then actually all the changes to the application state would be accounting entries so they were naturally event sourced because they're all accounting entries and so we'd store both and you might have a whole pipeline of changes the payroll example i said every little change change to your sick pay allocation change to your vacation stuff every one of those changes was a accounting entry and so everything was stored as events flowing all the way through and you have a pipeline of processes producing events producing triggering other processes producing events through the system and that was very useful and that worked quite well and i suspect that's where we have to go par good part of a discussion we had at this workshop was this question of what's more important the internal or the input event and as i said i do think it's it's certainly important to be clear of what you're storing and to understand the ramifications of what means across them and i suspect most of the time you need to store both okay so that's three of them so what's the fourth one well i kind of already hinted on that and that is this thing called cqrs command query responsibility segregation a term um coined by greg young whose name i've called out a couple of times already and he's talked about it i remember in fact the first time he talked about it was at a go-to conference or this is the first time i saw him talk about it was at a go-to conference many years ago the basic idea with cqrs is that you separate the components that read and write to your store permanent store so you have effectively two separate models one for dealing with updates and one for dealing with reads so and then the crucial thing here is that they are separate pieces of software separate components and that you really only ever use the command component the command model when you're making an update you always read using something else i mean you might do some reading in the middle of processing the command we'll do some reads but basically anything that reads a system is completely separate and the example i remember that he gave of this that was quite nice was a system that had to do a lot of complicated business logic for all the updates and they didn't want to have to be but they updated much less frequently than they read so it made sense to effectively calculate a lot of derived data and store it in the read model so that the read model could basically go direct to the ui and the command model then had to do all the complicated calculate calculations this is a model that i am this is an approach that i would say you've got to be wary of i think it's an appropriate pattern for a number of situations but it is one that seems to correlate a lot with people getting into trouble um and so you've got to really kind of be careful and make sure you really understand how it works and what its benefits are and if you really need it when you're using it my sense is it's got to be pretty deep down in the tool bag to pull this one out it's a good pattern when used appropriately which is of course true with almost any pattern but you really have to pay attention to when to use this i also find it gets a bit confused because i've heard people say well i we think cqrs should be used everywhere because it's really useful to have different models for reading things and populating different models but to me that's stuff we've been doing ages i mean for ages been talking about the idea of reporting databases where you have your online transaction processing system and then you take a input out of it put it into a completely separate database for generating reports people have been doing this for years you might do it every night from a extract transfer load you might do it in more real time using event updates these days but that idea of having different read pictures that's uh to my to my mind if cqrs is this then cqrs is every system that was ever built um i think what's important about the cqrs model is the notion that the that command model the thing that's used for updating isn't used by anything for reading it's only used in the process and you've got a distinctly different model that's only used in the update area and that i feel is a relatively rarish thing to do is appropriate when you want to use it but be pay a lot of attention to where it's appropriate on the other hand using report deficit different reporting views i mean do that all the time i mean i will always i've always been a big fan of transform the data into a shape that makes sense for looking at it and then look at it and multiple transformation steps compose very nicely so pipelines of transformations i mean that's that should be something that's familiar to pretty much everybody so four patterns all coming under the term event driven i found this useful and we found it useful in terms of our workshop because now we feel that when we hear somebody say event driven we've got an idea of where to go next now we say okay we think one at least one of these four patterns is in play let's ask questions about that and understanding these patterns then can ask more questions about okay why are you doing this are you doing this appropriately what are the common traps i mean the value of a pattern is saying here's a particular technique some ideas about when when it's applicable or not and enough knowledge about the pattern for you to know are these are the things i should watch out for these are some of the things that i would expect to see as consequences of that that gives you a bit more leverage but something as vague as event driven to me doesn't give you that because it it's too imprecise it's actually a similar problem that i just i found with service-oriented architecture service-oriented architecture means so many different things the fact that somebody said they were using it didn't really tell me anything you always had to dig deeper and so a more precise term like microservices is better because it just carves out a small amount of that space and you've got a better idea what's going on of course when a term like microservices gets super over hyped then that tends to lead to confusion because people aren't using the term properly so you know again it's not perfect but again with but with events i think we gain a lot by being a bit more precise and what i hope you've got out of my talk is some sense of what that precision looks like and what these patterns are and so that you can have a bit of better idea when you're talking about event driven systems what they mean the original article and there's the url for it you can see i've stuck the date at the front of the url i only do that for things that i think oh that's not going to be relevant i'll probably delete it in six months i got that wrong but anyway do go and take a look at that it's a very brief summary but there's links from there to lots of other things things like the article on lmac some of the stuff i wrote 10 years ago on event sourcing that's still fairly relevant and stuff of that kind and i hope you found that useful and i hope the talks that you will see later on in this conference will be better than this one thank you [Applause]

Channel: GOTO Conferences

Views: 375,074

Rating: 4.9245172 out of 5

Keywords: GOTO, GOTOcon, GOTO Conference, GOTO (Software Conference), Videos for Developers, Computer Science, GOTOchgo, GOTO Chicago, Martin Fowler, Keynote

Id: STKCRSUsyP0

Length: 50min 6sec (3006 seconds)

Published: Thu May 11 2017