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

For almost my entire career I've heard people talk about

event

-

driven

architecture

s and

event

-

driven

systems and things like that and it's always been a little strange what people mean by that because when I dig a little deeper it seems like they're There are several different things happening, there is some kind of common theme: the events or something called an event is an important part of what is happening, but it really boils down to something more significant that is much more open-ended. ended and for a long time that's been hanging around in the background and at various points in my career I thought I really wanted to delve deeper into this and I never got around to it because I dug into other things. instead, but it really came to a head late last year at Fort Works, we've been doing quite a few event-based things and several people came to roughly the same conclusion as me saying we've been doing all of these things. called event driven, we're not quite sure it's the same thing and we're doing it in all these different project teams around the world because there are now several thousand people in Fort Works and

many

different projects that we need to meet and learn from. from each other, so we organized a workshop in Denver.

It was yeah, Denver, um, late last year and a bunch of people got together and very quickly it became clear that yeah, there were some very different things under the title of event driven and we need to try to figure it out a little better and, like As a result of that, I think we came to understand a little bit of some common patterns that help provide a little bit more precision about what we're talking about and so we think. Well it's important that we describe this and tell the rest of the world a little bit more about some of our thoughts and I really hope someone else writes it and no one ever did but one of us made a little video just for a video internal what is it and I thought oh I can't take it anymore so I wrote a little note and stuck it on my website not expecting it to get a lot of traffic and I saw it was downloaded with a lot of traffic so I thought well , this actually seems to be a common problem and that's what led me to decide to impose this talk on you this morning because it seems like people are concerned about this and it came down to us identifying four different things.

I would call them patterns which are often included under the term event driven system. Could it be that when people say they have an event driven system they usually mean they have at least one of these patterns in play and it could mean they have all four patterns in play and I will go through them one at a time gradually revealing which ones. are. To start with the first one, let's imagine some example system that an insurance company might have and in this insurance system we have our clients and our clients have the habit of moving and changing their direction, but the insurance imagines that it is something like this like car insurance or home insurance, where changing your address actually affects your insurance quote levels and the premiums you have to pay on everything, so if someone changes their address, it's not just about update the address field, but you also have to activate the insurance quote system to generate a new quote and then they will send you an email to say here is your new insurance contract and whatever, I don't know. details, it's been a long time since I've spent time with insurance people, but the point is kind of a simple call and response

architecture

, what that requires is whatever system you have that deals with customer management and needs to report to its quotation system. go and make a new quote and the problem with that is that it creates a dependency from the customer management system to the insurance quoting system, you need to know it's there, you need to know what API it has, etcetera, etcetera, etcetera, and that combine knowledge. of how insurance quotes work in something that is a much more generic customer management function and that is a type of coupling that a lot of people don't really like, so one way to avoid this coupling is to say instead do that, let's try to turn things around.

I don't mind that my insurance coding system knows my clients and that there is a client management system that seems like a more natural line of dependency to follow because generally it's something that is very, very generic, for managing clients . that's the kind of thing you want to depend on and make it depend on a lot of other things and one way to do that is by using an event, so what happens is that every time the client changes some client data, the management system of clients emits an event. object to some event queue from a known place or whatever and then the insurance quoting system can listen to that event and when the event occurs it can decide if I want to do something about it, if so what should I do and then that gives us That ability to reverse dependencies allows the insurance quoting system to now have to be aware of this event structure, but the customer management system can be independent of all of this and this is an approach that in our discussion we give you a slide in our discussion we refer to as event notification, we are using events as a notification system, uh, now there is no notification mechanism between multiple systems, of course, I have described it in terms of large scale systems, relatively independent systems for a large company, but we also use this same pattern in a very small layered system and of course it is a classic approach of how to manage the interactions between GUIs and the rest of your code, when someone You enter information into a text box, you don't want a very generic text box widget. to have to know everything about your code and what things to call, instead you say the event, the textbox will raise 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 that it's reversing dependencies and that's really, I think the essence of why you want to do this is you want to do that dependency reversal.

I've talked about this in terms of events and I've emphasized this dependency change, but it does, but also. it does something else, it bottles it, it sort of takes everything that has to do with the change that the event is talking about and bottles it into a thing, an object, a record or something like a certificate that you can reference and pass it on. , it makes the change kind of a first class thing now, when we do when we call a function that's a very transient thing, we call the function supply the arguments go away, we never know we've done it unless we have some record and follow up, but when doing something like this, what we're doing is actually making a record of it and then we have something real that we can talk about and refer to and spread and that has its own benefits if we can ever do that.

So we're actually getting a second benefit here, which is to bottle it into a thing, into an object or I don't have to hesitate to use objects, it doesn't have to be an object in a 0 sense, I think. of this as some kind of first-class thing that needs to be a new technical term first-class thing God, I'm not even laughing about that, it's a shame, now that's not the only way to think about these first-class things. In images we also often think in terms of commands and that leads to an interesting question: when do we have events and when do we have commands?

What is the difference between an event and a command? And I think they're actually both very subtle. Actually, nothing you can say is a strict definition and yet at the same time it is very important because it is about our language and our communication and how we talk about our intentions about things that we could describe that situation that I just described. describe as the customer management system saying re-quote insurance for this customer, that's the customer management system saying it knows what needs to be done and it's telling some remote system this is what to do when I express it in terms of events.

I'm saying that the customer's address changed. I don't expect any particular response from anyone. I'm just indicating a change. Both can have this kind of stifle it and turn it into a first class weird effect, but the way the communication patterns differ is strongly implied to be different if you use event names or command name styles, so it really comes down to Because this is one of the two difficult problems in software. This is naming things and so when you think about the difference between events and commands, this is really how I want to do it. describe how the system works more accurately to the people who are reading about the system if I'm trying to say that 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 side I'm particular about I want something to happen so I want to name it in terms of a command now I mean you can get to the other side now you could have your insurance quoting system insist on sending a communication, an email to the customer and a form natural to do so, of course, will be a command, send an email, but of course, if you go too far down the event path, you'll get this passive-aggressive, right or passive events effect. aggressive commands where you say the customer needs to get a message about their new quote suggestion and you know you don't really want to go down that route if you're trying to read how the system works, that's going to be confusing when those types of events happen, either that uses events or commands under the covers, they are basically the same, they are often messages in signals, they look exactly the same, the difference is in the names, but that difference is really important because Let's face it, names in software systems They are one of the most important things we have to deal with, so going back to our system, one of the big benefits of using events is that it allows

many

other systems to connect to the event stream very easily without having to tell you. to the customer management system what is happening and this is a very good property.

A nice result of using events for notifications here. I need to connect a new system that takes advantage of the changes. I need to know if clients change their addresses. Don't know. I don't have to go talk to the customer management team and ask them to add a new no to no call in their interfaces and go to endless meetings with the customer management group and two months later I might get them to do something, No. if they produce their events, I simply tap the event stream. I'm fine, this is a very cool skill and it allows you to easily do all sorts of interesting things without changing what's happening, but when something sounds really nice, there's always a but isn't that?

And in the case of event notification, you are now in a situation where you no longer have a way to find out what the heck is going on on your system because there is no program to look at. There is no statement that says these are all the things that happen when a client changes her address. What you have to do. The only way to know what's going on is that you actually have to watch how you approach the various events and see what happens. the flow of messages through your system to try to figure out what the heck is going on and this is true in the case of gui, if you have ever tried to debug a heavily event driven gui system your Only chance is to bring it into the debugger and try to trace the various events that flow through.

I remember doing this once to try to figure out how the original small talk 76 worked because I was writing some stuff about the model view controller and quickly discovered that it couldn't be done. I didn't trust any of the documents that had been written on it because I often didn't have access to the source code, so I was able to get a copy of the original mvc 76 small talk, mentioned it, and was able to actually figure it out. how it worked, but I couldn't understand how it worked by looking at the code. I had to go through the debugger and 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 cool. By decoupling, you get this great flexibility of being able to add new consumers and you get the inability to see what's going on in the entire system as a whole, there's no code anymore that you can just look at and it's a trade-off like so many other things. offs, so that's the first event notification and I would probably say that's the most common thing people say when they're event driven, it's using an event notification mechanism somewhere, which is a little strange in a way because almost every system I've ever looked at uses event notification to some extent.

I assume that when you call it event-driven it means that the event notification system is seen by at least the high-level people in the project as a partparticularly important of the architecture, so the second one is a minor variation on this case, so let's go back to our little insurance company example again in an event notification system. All you really need to know is that the event occurred and that could be very generic, it could be just saying "hey". something changed somewhere, you probably want to give a little more information about the event, so you could say ah, the event for linda changed, something changed in linda's account and then all the other systems find out what happened and They find out what happened.

Do they have to talk to the customer management system and even if I were more precise about this, I could say that Linda's address changed. Usually still the insurance code system is fine, so what's the new one? What was the previous one? Knows? Has it changed the way it is? For me, event notification is important often involves additional traffic because the systems that are the consuming system still have to go back to the original source for more information and of course we reduce that burden by including more information in the event if I'm just saying something. about linda changed then every time you have to accumulate and probably half the time it's not worth it it doesn't really mean anything so it was kind of a waste of time if I say here's the change of direction then there's less trafic. required because I only need to enter if I care about an address change and then I can take this to the final logical conclusion and say: can I put so much data into the events that I don't actually need to go back to the host? system, so I don't just say linda's address changed, I say what was her old address, what is her new address at that time, maybe she doesn't have to come back or maybe she does, I know the address changed, I know I need do something. but now I need to go back to all the other attributes all the other things I know about linda increasing her browsing history how often she gets up every day all these things we know and can find out by asking the customer management system but now I have a system customer management who has all these queries every time something happens.

All the other systems bombard me with things. Can I reduce that? Can I remove that burden? Well, it could and this is a pattern that we tentatively call led event state. transfer, which is a bit of a long name, but I like it because it is a game with the rest, which is a resource, what is it, state transfer, this is an event carried out, state trend, it is about using events that they lead to Stanford from the state, what happens when using this pattern is what you say: I want to completely prohibit any contact with the client management system from the insurance quoting system, which means that the insurance coding system will keep a copy of all the data you will ever need - that means, of course, customer management.

The system has to transmit in its events all the data that later systems will want to have, and later systems must keep copies of everything they will use. I do not have to keep a copy of the entire client record. I only have to copy the things that matter to me, so it's not as bad as one might think, but it's obviously still a big copy of data, but the benefit is that now I no longer need to call the customer management system. I have everything. available data, that could improve my performance because I no longer receive remote network calls to the client management system, it reduces the load on the client management system because it does not answer all those calls, it can also improve availability because if the The customer management system crashes or is intolerably slow.

I don't care, I keep moving forward because I have all the data for me, so we can immediately see some really interesting benefits that have to do with that. Now doesn't mean I have to. All I need to do to make sure I'm up to date is keep copies of the data, which means of course I have to copy all the data, but we're not talking about that much data these days, storage is cheap, plus I have my insurance quoting system, my availability is no longer dependent on the client management system, so that's good now, I hope you are well versed enough in software development to know when people say I have higher availability because I don't I depend on something else.

Do you know what the price is? What is the price of high availability? Lack of coherence exactly. Now I have to replicate the data. I have eventual coherence. I have to deal with that problem. I have a coherence problem. Again, transport status of the event. The transfer has this compensation. I get even more decoupling, even more availability, but I lose the complexity of maintaining duplicate data and the inevitable eventual consistency, so this is a less common pattern. I don't know what the proportions are. I would say that a lot. the moment I see the event notification I don't see the event state transfer state transfer but you and you must have an event without event notification to do this, but it is a technique to keep in mind.

I would say this is one you should keep. Deeper into your toolbox, but in many circumstances it can be good to play with, so sometimes that's what we see when we talk about event-driven systems, this data duplication notification to avoid callbacks, so the Third element so far is what I've been doing is I've been telling you the concept and then telling you its name because I think it's more exciting that way. Of course, if you read the talk beforehand, you already know what the four things are. are so I'm not really sure why I'm doing it, but for this one I'll tell you right away what event sourcing is, which is a technique that has long fascinated me and it's interesting to see how it's being used by people. people, but let's start by explaining what it is, what I mean by event sourcing, by the way, how many people have come across the term event sourcing, raise your hand to a handful of curious people, how many? people understand it pretty well and think they could explain it to someone else.

Okay, I'm not going to ask you to go up on stage and do it, don't worry, okay, that's how I explain event sourcing and surprise, surprise is change. To address the example again because I'm a bit boring, so let's imagine I have some kind of customer management system and I have someone with an address and they want to change their address in a typical system, how do you change the address? just say "okay", let's delete the old address, create the new address, that's how it works, nice and simple, what event sourcing does is create this subtle change in the image, so now what we have is that we still have this representation of the current state. of the world, but we also have a second little area and when I say change my address, the first thing that happens is we create an event object, so this is a first-class thing that captures the details of the change and we pop it. that first class thing puts the event in some kind of separate storage area, then we process that event and we process the event to do exactly what we expected to do before, we change the thing and the consequence of this is that we have a sort of Now we have two types of representations of our world: we have what I call the application state, which is the current state that we are thinking about of the world and then we have a record of all the events that ever change that world and This is the Crucial test for event sourcing.

The proof type of definition is that at any time we can delete the state of the application and confidently rebuild it from the registry. That's the test. I mean, a lot of people log changes and stuff like that. Is the capacity. to replay the log and confidently rebuild its state so that you basically don't care about the state of your application and don't try to persist it anymore because the vital thing is to preserve the log, if that is the situation then you have an event source system then , as? many people here have built a system using event sourcing with this approach a handful of hands few hands how many people here have used the system using event sourcing a few hands not many how many people here are software developers raise your hands okay , I'm leaving I guess you don't quite understand what I've been talking about for the last few minutes because otherwise we're really screwed with all those people who haven't used an event source based system and with our software developers.

If that were true I would be really very worried in 2010 let alone

2017

because every software developer should be intimately familiar with a particular form of event sourcing system which is version control if you use git use subversion mercurial even if you use cvs and I did it a long time ago, but I used it, you used an event sourcing system, heck, 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 your users a system that works with their data in the same way.

The control works in your code and I find a very good way to explain at least to software developers what event sourcing is about and many things about event sourcing that can be reasoned by thinking well what happens in my control system. versions, what does git do. What does Subversion do and then apply that same question to the application state it's in in its version control system? The state of your application is your file tree, your working copy, your working tree and the log are of course all the commits they have. happened so far, of course, the system internally doesn't necessarily store it as all events, but it effectively stores it as if it were all events.

There are snapshots contained at various points to speed up performance, which is basically a copy of the entire state of the application. like in some commit, but by going back and forth between snapshots and using commits and being smart about how everything is played, it gives you the feeling that I have each and every commit, which is pretty much the same as saying that I have each snapshot, but it's a little more powerful to think about it in terms of each commitment. That's a good metaphor for us geeks, not a terribly good metaphor for business people, but luckily there's another really good example of event sourcing in the business world that any business person will be familiar with from the books. accounting, right?

If you're honest, my current application status is the amount of money I have in my checking account, but of course behind that is every credit and debit of that account and of course the accounting books and systems. accounting are used by all kinds of people and that's very much an example of this event sourcing approach and again look at the fact that it's a combination, actually it's often a combination of each change and certain snapshots, something common in accounting is let's say at the end of a year or something, we'd say we're going to close the year, calculate all the balances for the end of the year and then ignore everything that happened before and build our events at the point since then, that it's an instantaneous effect where you are effectively discarding the history behind a point in that case, but it may also be that you don't discard the history, you just use it to make it easier to calculate what is happening for this year. money and if you really need it you can dig in and go further back, so again storage is usually a combination of events and snapshots taken in some way that is efficient for your capacity, but you always want to 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 a lot of interesting benefits but also costs with this pattern. Right away, you can tell that it's obviously a great auditing system if I want to figure it out. What the hell happened or how the hell did they send this person this quote that was completely ridiculous? I can look back through the events and figure it out and that's why anyone who's involved in audit really loves having an event sourcing system, that's why of course. We have accounting books because that is one of the main reasons due to audit.

It's also a fantastic debugging tool. If you are trying to find out why your application state got messed up at some point in time, you can take a copy of the system. feed it the same events and look at what happened by going back in time and of course time travel by going back and seeing what the state of the application was a month ago, two months ago, we're familiar with doing it from the controlversions correct and is really useful. being able to come and go through time. The alternate state is also branching effectively and that can be very useful in certain circumstances.

I've worked on some systems where we might have notification events and we treat them as usual. the use is payroll, someone worked 35 hours in a week, we record that we sent them a check, we update their sick benefits, pension benefits, all kinds of subsequent things happen and then six months later someone says, oh, in Actually, it wasn't 35 hours. was 40. That's a really complicated exercise and then undoing it well, you can't undo it because you can't change it, but then recalculating what the settings should be for all of that, but if you have an event sourcing system. you say okay, I'll modify that and copy it to a different system modify the event calculate what the current state is look at the two states of the application differentiate them and make an adjustment I mean, obviously it's a little more complicated than my casual saying why we just differentiate the state of the application but you get the right picture, you really understand it, you can do it and it can be a long calculation, it can take a couple of minutes, but that's a lot faster than doing it manually and that can be a really powerful thing.

The last item on the list of good things is actually one of the most intriguing. The idea of ​​​​using a memory image. This basically says whether our long-term record of what the state of a system is is actually an event record. I should walk over here and give this end of the room a treat, force the cameraman to wake up. If I give it that long-term view, I don't actually need to store the application state in any kind of persistent way, why do that? I need to store the state of my application in a relational database if I have a record 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 is a retail trading system and was built a few years ago. it has to be very high performance, very low latency and they looked at various ways to try to achieve this and they ended up saying we're going to run the entire system in a single thread and Java and their headline was "We can do it." six million transactions per second on this single thread really incredibly fast and one of the keys to doing this was all their data was in memory now they have complicated transactions, they have a ton of things to look at at once, they didn't want to go to a database, they have everything in memory and they were able to process very, very fast and if something happened and the system crashed, they could very quickly reconstruct the state from the logs of their application, they would take a snapshot overnight, so that you basically run all the events from the beginning today work that way and in fact, again, one of the advantages of events is that you can have multiple systems running in the same event stream, so they had a very good way to have hot backups, they basically ran two systems all. the time when one of them was the leader and if he failed, the second would instantly take over for a very, very nice, very, very effective system.

One of the interesting things I was talking to one of the lead developers and he said that I actually mean The performance was fantastic and really caught people's attention, but one of the things I really miss about programming on a different system It is the most beautiful system I have programmed in because there was no database to manage everything, everything was in memory. time and as a result we were able to have a really good rich model, it was particularly good for complex logic represented in a domain model and was a real pleasure to work with compared to many other systems.

It surprises me that in many ways there are more people. That kind of approach hasn't been taken, it's a bit unusual and you have to set up the infrastructure to make sure you can run events with that, but it's actually a pretty powerful model and may become more interesting as we go. opt more for systems that have large amounts of non-volatile main memory, because many of us, our systems, have been built under this assumption that we only have a limited amount of memory, we have to park everything else on disk and now we have Tons of memory, everything fits in RAM for so many applications, so maybe we should leverage that memory image as a way to do it, but you still need to have some kind of communication mechanism and persistent storage and event logging. provides. sourcing can be very helpful in that situation so those are some of the pros but as implied there are cons ok I'll be back I hope you enjoyed not having to crane your neck for a while so it's an unknown system which is bad because things are unfamiliar, it's harder to work with, talking to external systems becomes a little more complicated because if I want to be able to rebuild the state of my application, 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 create a playback mechanism associated with it. I have to think about how I store my events so that I can replay them with confidence. them even when I'm changing the code that processes them so that the event schema starts to get interesting so I can do that, it's also a small but awkward thing when I generate identifiers for things. I have to be careful to be able to do it somehow. that I can reproduce this rule that says I should always be able to replay the events, create the state of the application, there are these little tricks, little traps for you early on that you have to deal with and you have to think about how to overcome them.

Those definitely add complexity and you get other complexity that usually comes along the way. One of the triggers for doing this talk and workshop was when I ran into people who were struggling with event-driven systems, but it wasn't clear. what was the source of the difficulty, so I remember having a conversation with someone about a project that was in difficulty and they were saying, oh, I'll never use cqrs again. I said, oh, okay, you had a hard time with that, so rewind was wrong, she said. I will never use event sourcing again and I asked him why and he said okay, 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 okay.

Wait, that has nothing to do with event sourcing, that has to do with something else and you often find that people mischaracterize where the problems are with event sourcing. I have often heard this because the problem and the problem in that project according to the leader The architect was asynchronous, he processed all his events asynchronously and asynchronous processing became difficult for people because it tends to be difficult to work with asynchronously, it is difficult reason now there is no reason you have to have async with an event source system when just doing a local commit in git that is not an asynchronous operation is now fine when people are pushing to shared repositories and then it comes into play the asynchrony, um, but there's nothing like that, it's all synchronous operations that I'm doing a local commit, but often people take The advantage of event sourcing is to introduce asynchrony into the system, which can be a good thing because it improves responsiveness, but asynchrony then adds complexity, so the reason I pose it as a bit of a question mark is that asynchrony often gets in the way. with event sourcing systems and adds a lot of complexity, but you don't need to use it, you don't need to use an asynchronous event sourcing approach, although it seems common for people to confuse that another problem is version control, version control can become quite complicated. in an event source system because of this replayability and particularly when you think about it, the code of course also changes in this system over time if I change the state structure of my application and the schema I'm using for the status of my application.

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? Version control can get complicated again. It doesn't have to be the lmax example I mentioned above. They didn't run into that problem much because they only operated with a one-day snapshot and the events from that snapshot, so they didn't have to worry as much about the versioning aspects, but it can be a problem for other systems. and i will mention that there is a book in progress or close to completion by a guy named greg young if you search lean pub on versions for event catering systems where he goes into a lot of detail about the various options you have. has to handle event sourcing, so it handles version control and event sourcing.

Greg Young is the creator of Event Store, which is a storage system designed specifically for events. He has been working in the events space for quite some time. You can find a lot of his lectures and stuff on video I've been trying to get him to write a book on event sourcing for years so far with no success so if you ever see him tell him to write that book so event sourcing It is, like most things, a trade-off, there are pros and cons, there are some really nice advantages, there are complexities involved, I'm surprised more people haven't made use of this approach, however, one more thing to mention about the event sourcing and that's exactly what we record as our events in the event. source I think about the code example for a moment.

I go into my code. I see a function with a name I don't like anymore and I want to change it, so I go and change it. Pretty simple refactoring operation. How do I represent that change? In terms of event source, there are two events happening here, one is my intention to rename this function and the second is all the actual edits I actually have to make to my source code, which of course isn't just in one First, it's the declaration of the function and everywhere that calls it now, as far as any version control system you've ever used, you only see this last one, you see a bunch of textual differences that have absolutely no shape of knowing the intent of that, except by looking at the divs and maybe the commit message to say that's what I did and we've talked on occasion about how nice it would be to have automated refactorings that were storable and were first-class things that your project could apply, but in practice it's very difficult to do it because of course a rename function method, uh, function capability for that would work with javascript, won't work with java, won't work with Python, so that I have to make language specific changes to my version control system which is starting to get very complicated while text works with everything we know, how to diff, merge and handle text changes, so we trust text, but then we lose the intention, we lose what is the reason why basically the same thing happens with commercial things. well, we say I have some intention of something I want to do and maybe I want to capture that and as an event and I think of that as a kind of input event and then I have how does this affect my internal knowledge of the world, which is a lot more detailed but often also misses important context and then there may be another type of event which is an output event that says this is what changed in the rest of the world you know, it's important to realize that they are separate things and think about which You want to capture which ones you want to store because you may want to store more than one of these.

If you look closely at the slide, you can notice that we have a small problem: the code is not quite correct. the total is wrong, what's wrong with me fixing this error? I have to be able to reproduce it 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 still have to fix the iceberg but I also have to be able to reproduce things and things start to get tangled again. It's this version problem. Greg Young's advice is pretty firm and he says there is no business logic between event and storage. because if you do, you run into this tangled mess of versions, but on the other hand, if I don't have the input event stored, I lose the intent of what I'm doing because that internal event can be a pretty complicated and messy solution. of course, it is to store both and, in fact,I have seen it done with some of the events or systems I have worked on.

The canonical style I saw in the '90s when I was doing this was that we would store the external. event and then actually all changes to the state of the application would be journal entries so naturally they would originate from events because they are all journal entries so we would store both and you might have a whole series of changes in the payroll example I said every little changes to your sick pay allocation, changes to your vacation, each of those changes was an accounting entry, so everything was stored as events that flowed through and you have a pipeline of event-producing processes that trigger other event-producing processes throughout the system and that was very useful and worked quite well and I suspect that's where we need to go.

A lot of a discussion we had in this workshop was this question about what is more important, the internal event or the input event, and as I said, I think it's certainly important to be clear about what you're storing and understand the ramifications of what they mean. between them and I suspect that most of the time you need to store both, so that's three, so what's the fourth? I've already hinted at that and it's something called the cqrs command, consultation, accountability, segregation, a term coined by Greg Young, whose name I've mentioned a couple of times already and who's talked about it.

In fact, I remember the first time he spoke. about this was at a conference or this is the first time I saw him talk about this it was at a conference many years ago the basic idea with cqrs is that you separate the components that read and write in your store permanently so that it effectively has two separate models, one to handle updates and one to handle reads, and then the crucial thing here is that they are separate pieces of software, separate components, and you actually only use the command component, the command model when you're doing an update, you always read using something else, I mean, you can read a little bit in the middle of the command processing, we'll do some readings, but basically anything that a system reads is completely separate and I remember the example you gave.

What was pretty cool was a system that had to implement a lot of complicated business logic for all the updates and they didn't want to have to do that, but they updated much less frequently than they read, so it made sense to effectively compute a lot of derived data. and store them in the read model so that the read model could basically go directly to the UI and the command model then had to do all the complicated calculations. This is a model that I am. This is an approach I would use. Let's say you have to be careful, I think it's an appropriate pattern for a number of situations, but it seems to correlate a lot with people getting into trouble, so you have to be very careful and do I'm sure you really understand how it works. and what its benefits are, and if you really need it when you're using it, my feeling is that it has to be pretty deep in the tool bag to pull this one out, it's a good pattern when used appropriately, which of course is true with almost any pattern, but you really have to pay attention to when to use it.

I also find it gets a little confusing because I've listened. people say, well, we think cqrs should be used everywhere because it's really useful to have different models to read things and populate different models, but to me that's something we've been doing for a long time, I mean, for a long time we've We've been talking about the idea of ​​reporting databases where you have your online transaction processing system and then you take an entry and put it into a completely separate database for reporting. People have been doing this for years. You can do this every night from a statement transfer upload.

You can do it in more. in real time using event updates these days, but that idea of ​​having different reading images is, in my opinion, if cqrs is this, then cqrs is every system ever built. I think the important thing about the cqrs model is the notion that that command model, what is used for updating is not used by anything for reading, it is only used in the process and you have a clearly different model that is only used in the area update and I think it's a relatively rare thing to do. appropriate when you want to use it, but pay close attention to where it is appropriate, on the other hand, use report deficit different report views, I mean, do it all the time, I mean, I always will.

I've always been a big fan of transform. the data in a form that makes sense to look at it and then look at it and the multiple transformation steps are composed very well, so the pipelines of transformations, I mean, that should be something that is familiar to almost everyone, so four patterns are included under the term event. driven, I found this useful and we found it useful in terms of our workshop because now we feel like when we hear someone say event driven, we have an idea of ​​where to go next, now we say okay, we think of at least one of these There are four patterns at play, let's ask questions about that and understand these patterns, then we can ask more questions about okay, why are you doing this?

Are you doing this properly? What are common pitfalls? I mean, the value of a pattern is to say here's a particular technique. ideas about when it's applicable or not and enough knowledge about the pattern for you to know, these are the things I need to pay attention to, these are some of the things I would expect to see as consequences of that that give you a little more leverage , but something as vague as event-driven to me doesn't give you that because it's too vague, actually a similar problem I just ran into with service-oriented architecture. Service Oriented Architecture means so many different things that the fact that someone said they were using it didn't really tell me anything, you always had to dig deeper, so a more precise term like microservices is better because it just takes up a small amount. of that space and you have a better idea of ​​what's going on.

Of course, when a term like microservices is overhyped, that tends to lead to confusion because people don't use the term correctly, so you know again it's not perfect, but again with events, I think we gain a lot by being a little bit more . precise and what I hope you learned from my talk is an idea of ​​what that precision looks like and what these patterns are, so you can have a little better idea of ​​what they mean when you talk about event-driven systems. the original article and there is the URL, you can see. I have put the date in front of the URL.

I only do that for things that I think aren't going to be relevant. I'll probably delete it in six months. I was wrong, but anyway go check it out. It's a very brief summary, but there are links from there to a lot of other things, like the article on lmac, some of the things I wrote 10 years ago about event sourcing that are still quite relevant. and things like that and I hope you found it useful and I hope that the talks you will see later in this conference are better than this one, thank you