Greg Young — A Decade of DDD, CQRS, Event Sourcing

so what we're going to be talking about today is really more of a retrospective over the last ten years in dealing with event sourcing but we're not only going to be talking about event sourcing we're also going to talk a little bit about domain driven design so what we're going to be going through I want to start off talking about the history of event sourcing and then we're going to look at some of the good things that have happened over the last decade then we're going to talk about some of the bad things that have happened over the last decade and the last thing we're going to talk about is things for the future areas where people haven't done a lot of research and a lot of focus on events or systems yet that at least I think are interesting now one thing I promise is we will not have these slides I have used these slides literally for like nine years and explaining people event sourcing but if I go back and I look at the history of event sourcing it started off on clay tablets in Sumeria they use these clay tablets in order to track financials it's not a new concept after Sumeria some things happened and then we came to 2006 this is not from q con 2006 they apparently have every single cue con archived except for 2006 and I've told the story a couple times before but this was the second time I actually talked about event sourcing and CQRS and the main German design and this talk went really really well and that's really when event sourcing got picked up and people started talking about it and luckily there weren't that many people in the audience the year before I also talked about event sourcing and I was a developer who didn't really go to user groups didn't really talk and I went to cue con San Francisco to go present this stuff and my front row and you have to consider event sourcing CQRS it's kind of extending domain driven design and messaging systems adding some new patterns my front row was Eric Evans Martin Fowler Gregor hope eh I went through all of my slides in less than 20 minutes I had probably had about eight cups of coffee before I went on and for those of you who know Eric you know that there's never really a bad word to come out of his mouth at the end of the talk he came to me he said that was a very bad talk I think I understood about 15% of it which means everybody else probably understood a lot less but the year later I came back and I did this talk and Eric came to me afterwards and he said that was a very good talk and this is really where events sourcing started getting picked up shortly after Martin Fowler picked up and made the term event sourcing and put it onto his blinky referencing this talk actually and then it started getting picked up and we didn't originally have this thing called CQRS at that point we just said that we had cqs command and query separation from Bertrand Meyer and as Martin wrote on the bleakie he said you need to make up a new thing for this because this is not cqs this is doing something different so I came up with this new term called CQRS and we decide we will call it that unfortunately I was a and never looked at my keyboard because every time you put it into Google it would say do you mean cars luckily today if you actually go type CQRS into Google it will actually understand CQRS is a thing not a misspelling of cars oddly enough to make google searching even worse people like to put in drag young CQRS well there happens to be a Buick dealership Greg Young's car sales in the US so they got all these hits so suddenly and they must have been really confused with what was going on as things moved on we started getting a lot of traffic going on the main driven design list that was mostly about secure s an event sourcing and it became very very technical so Eric and I talked and we decided that it 2010 ish that we would break apart the two mailing lists so that way we didn't have all of this technical messaging talk going on in domain-driven design list and of course as we look to the future I've been told that this will be coming out in 2035 but event sourcing has had a fairly long history over the last ten years before we get into the kind of retrospective type stuff I want to talk a little bit about CQRS a lot of people go through and they start talking about how they want to learn CQRS based systems CQRS is more of a stepping stone and you have to take CQRS and put it in its historical context when you look at it how many of you remember back in 2007 to 2009 what kinds of systems you were building with DDD my guess is you were using an ORM all of your reads and writes were both coming off of your domain model and you spent almost all of your time working with mapping files getting somebody from that mindset to event sourcing where they use append only events is a huge jump you cannot get somebody to easily make from one to the other it's a lot like one of what people are experiencing today with functional programming they're they're coming from having worked with control with control structures their entire career and then train again into functional programming going ah it's scary and a lot of them leave CQRS made it a natural progression as you went through and CQRS was a natural consequence of what was going on in the DD community at the time as well historically if you go back and you read the early ddd list one of the most common things we would get on the list is so I built my beautiful domain model now my boss he wants this report with like a roll up inside of it based on which County the person's living in and I need to load up 500,000 aggregates and iterate over them in memory in order to do this this is really slow with my ORM so how do i improve performance on my domain model and the response was your data is in a sequel database do a query but this is one of the frequently asked question this on the DDD list where I talk about some more frequently asked questions on the DD list my personal favorite I think it makes up 80% to the traffic on the DDD list is can I inject a foo into a bar they have come up with at least 50,000 ways of asking this exact question but as we started realizing that we're telling people that reports you should bypass your domain model on what is a screen when you show screen to a user what what is that well it's a report that has some buttons you can click on it so why don't we just take that same advice and apply it to everything and that's how you got CQRS you need to look at CQRS not as being the main thing CQRS was a product of its time and meant to be a stepping stone towards the ideas of event sourcing and it was already there when it came out in terms of guidance that people were being given CQRS is not the major thing you're looking for it is a very helpful stepping stone to get you over to events or systems now I'm not saying that you should never ever apply just CQRS and separate reads from writes and go back to the same database that is actually a valuable pattern and I've seen lots of people build systems that way and they got value from it but remember it's not the end goal of what you're trying to get so now coming to retrospectives it's been many many years now and when I first was talking about this stuff I was only 27 now I look back at my 27 year old self and there's so many things I wish I could tell him but good things have happened so we mentioned the mailing list in 2010 roughly 2010 we broke it I don't have all the history of the mailing list and for some odd reason Google doesn't tell you when it was actually created and all their little charts they only go back one year and I remember thinking at the time we should set this up in Google Groups because Google groups are better than Yahoo groups but then I went and looked at domain driven design lists and yahoo groups you know what they have all that information but our mailing list has gotten up to two thousand seven hundred and fifty-four people as of this morning of course now I'm going to go and people are going to look and it's going to be like two thousand seven hundred and eighty because people just signed up now but the community has grown a lot that's not a small community when you're talking about almost three thousand people on a mailing list and because there have been so many people that have actually come in we've gotten to start applying event sourcing to a lot of new domains and new problems and this is really really important so when I was first talking about event sourcing I had used it primarily in heavy transactional domains finance gambling lotteries these are heavy transactional right domains and it's been common to use these kinds of systems events or systems in these types of domains for a long time where things started getting interesting was while I was working with all this financial stuff we got contracted to do like two or three other small projects for completely different domains and we just said well let's just build them this way and we did and we started seeing all kinds of other interesting bits of value even though they weren't typically built that way as people have been going off to new domains and new kinds of problem spaces they've also been finding new things about events or systems that are actually beneficial in varying domains but something else has happened that's been really cool once people have actually gotten in they've learned how events or systems kind of work they've gone through in many domains and they've actually had breakthroughs in their domains by introducing this mechanism of thinking into their domain model a perfect example of this happened with a project that was involved in so we were dealing with a warehouse system has anybody here ever worked in a warehouse and you have your little symbol devices and so you're going to take this box and you're gonna put it on the truck and you scan it and then the system goes no that box isn't here so then you have to go over the back-office and you have to go into the back office and try to get the system so that the system now believes the box is actually there so you can check it out and move it this is really really annoying we decided to try modeling a warehouse in an event sourced way where basically we decided that the system cannot say no the system will just receive events that are happening from all devices what was interesting in this is that it changed the role of the system from the domain experts perspective it was no longer the responsibility of the system to try to maintain consistency of the warehouse the role of the system was to generate an exception report for when things might be off it would never stop you if you scan something and put it on the truck you are actually there you are scanning that box and putting it on the truck if it doesn't know that that box is there an exception pops up on the exception report and this has been seen in many industries where when people started applying event sourcing on two systems they got a different perspective of how that system should be working and this changed how the domain experts actually viewed their own domain and I've seen this happen in many domains and this is a very very good thing that were we're coming up in new ways of looking at problems other good things that have come up in dealing with domain experts it's been noted that when you start forcing people to model events it forces you to think about behavior of the system as opposed to thinking about structure inside of the system and this is really really useful when dealing with domain experts who are coming from a legacy system because domain experts have a tendency of thinking in terms of their legacy system as opposed to thinking about their domain problem once you start modeling events it forces you to think about a behavioral version of that system as opposed to a structural version of that system and what the data that it stores this there's another thing that's come up from modeling events and I think it's actually more important than the behavioral focus once you start modeling events it absolutely forces you to have a temporal focus on what's happening inside of your system time becomes a crucial factor of your system how things correlate over time what happens if this happens before this and these start becoming real domain problems and more often than not once you start getting into temporality insides of systems this is where the really juicy domain knowledge actually is we're talk more about this later but very often we end up with very naive models as an example how many of you have seen shopping carts and then somebody will say hello and then we check whether or not we have the product and inventory how do I make that consistent now if I were to actually go talk to anybody who's ever worked selling products they don't give a crap if that's consistent why because even if that system says that you have one of those things in inventory that doesn't mean you have it in inventory at the end of the day that system isn't the book of record the warehouse is the book of record it if you don't believe me otherwise how do you get people to check things out appropriately when they're stealing them but this forces us to start thinking temporarily and very often when we start getting these problems we tend to have very naive viewpoints once you start modeling in events it forces you to actually start thinking temporarily now one thing that's come up and it's been a huge success is event storming and I saw people out here today going through events storming exercises trying to figure out a domain it's a very nice way of doing things what's interesting is there's actually more than one style of event storming so Alberto has been doing his style for quite some time now and it's very good I like it for trying to get in initial exploratory and figuring out what our problems are and what's going on I have a different version that I've done and the difference is we take a single process a single long-running business process and we focus only on that one process the idea is not to discover what's happening inside the process we already know that we're trying to go through and actually formalize what it actually is and then what you start finding is when I have all my events and my commands I can start looking at them and I just put them in piles and they represent service boundaries what I'm really trying to score is service boundaries and there's multiple ways of doing event storming that'll come up and they're all valuable and I'm really expecting the event storming process to actually become more and more formalized over time and it's a worthwhile exercise for people to go through other good things ideas have been spreading now as much as I would like to kick claim that you know I help the ideas spread and that's not really what happened so what happened was event sourcing came out at a time that was perfect for it and there were a lot of other things that were pushing in the same direction as it and it moved forward with a lot of other things as an example functional programming functional programming has actually come up at exhaust the exact same time as event sourcing and what's interesting is when you start getting into event sourcing event sourcing is naturally functional it's an append-only log of facts that have happened in the past you can say that any projection any state is a left fold over your previous history and if people have ever seen it before that little dragon on the get event store mascot that's actually Ouroboros it's a snake eating its own tail we did try to get him eating his own tail in the little picture but that didn't look very good he was doing something else and it wasn't very child friendly but event sourcing when you start working with event sourcing and functional code it's totally natural I did a talk over at NBC this year where we basically took some object-oriented code we refactored it to functional for event source code and what was interesting is at the end what we came out with was if we wanted to build a framework for event sourced code what we would need is a thing called functions we would need another thing which is called a pattern match and we would need left old and that was the entire framework that we had actually built most functional languages already have this built in but there are other things that were pushing in the same direction at the same time another one of those is cloud computing especially we start talking about getting into things like immutable infrastructure this push has also moved event sourcing forward a perfect example of this if you go look at the CQRS and event sourcing by Microsoft patterns and practices which is heavily focused on doing this inside of a zoo using their toolkits well these other things that have been coming that have been pushing along with event sourcing um my t-shirt and the popularity of actor models now I tried to find a picture for actor models let me just say that I would not recommend putting this into Google I was going to take one of these but it was better just take a screenshot of the results and it makes you wonder like like which actor model goes with which actor I think they need a bearded one for Earling but the rise of actor models has also happened around the same time as the rise of event sourcing which has also happen around the same time at the rise of functional programming all of these things are inherently related to each other and of course we have the new one micro services which well I guess that's the old one too but we're starting to see ideas spreading into many other places as well how many have heard of flux does it sound familiar it's event sourcing this isn't new ideas but you're starting to see more and more these ideas springing up everywhere other examples now on the JVM you have Kafka and we're getting more of a push on the JVM now towards events or systems which I've never understood why the JVM didn't pick it up nearly as much as mostly guys in like the akka community not ret guys writing normal Java code and for some reason it had been tied to dotnet which was really bizarre for me because there's nothing language specific at all about it so now we're going to come to the bad and well I guess we'll go back to dotnet for a second I wanted to add that all of these same movements that we've been discussing they're also really affecting dotnet how many people here are dotnet developers how many of you think that you'll be running I is on a Windows server in five years all of these same things are pushing really heavily on the CLR and the entire Microsoft developer space which is why you're seeing a lot of moves things like core CL are moving towards Linux it's the same things that are really pushing away dotnet so now let's go through and talk about some of the bad things that have happened and gasnet the single biggest bad thing that I've been that I've seen over the last 10 years is people and this is a very common anti pattern they will get into event sourcing and the first thing that they will do is they will say we built an event sourced system all of it that's a really big failure you they end up building a monolith and the monolith is event sourced internally and then they start realizing that this is actually really hard when you had a crud based system there were all kinds of crazy little use cases that you were hiding an example of this might be I put in some data I click Save but then I realized that I mistyped something do you have an event for me be able to correct that and you need to have an event for me to be able to correct it before in your crud based system people just go through and they just edit it again and it wouldn't be a problem but once you start dealing the mutable events you have to start thinking about things like Corrections the other thing they start noticing is when you start doing offense sourcing it it's different style of analysis and it can be more expensive and when you come in and you say we're going to eventsource this entire system the system of systems everything is event sourced this is a really really bad idea normally you want to apply it selectively only in a few places and there are times where it actually becomes easier to eventsource but as a rule you really don't want to eventsource everything event sourcing and secure RS are not top-level architectures when you start looking your top level architecture your top level architecture is something more like event-driven there's other things that are bad that have happened along the way for people that don't get the reference it's from the movie dogma this is Buddy Christ they're their new take on on Jesus to be more fashionable for a younger audience and there's a lot of dogma that goes on in the varying communities and this is part of the reason why my book won't be out till 2035 because I've watched what happened with Eric's writing and very small things inside of Eric's writing end up in 200 male threads on the domain-driven design list as an example of this and I'm sure Eric will remember this one value objects are mutable so what Eric wrote is that value objects are normally immutable and somebody read that and then went ah so there's valid cases when they would be mutable let's enumerate those I have yet to hear a valid use case for a mutable value object and I know Eric was just trying to temper his words to not say they're always immutable but it was like people were reading from the Holy Scriptures and looking for what the possible interpretations of this could be and how do we justify this what do we mean from it IIF they if they can be mutable I've never used a mutable one before I need to do that or else I don't understand DDD there's a lot of dogma that's come up another perfect example of this is the the word usage between process manager and saga and it's become very very difficult to to communicate along a lot of these things and you can watch if you don't know how many people here on the DDD CQRS list you can watch over time there are the same questions that come up when people are at the same levels and they always ask the same questions and you can basically see where somebody is as they're coming in based on the questions that they're asking an example of this can the right side query the read side and I've heard people say no you absolutely can't do that well believe it or not there's times that you have to you can't get around it there are times that you will have to have the right side query the read side an example of this would be when you have an invariant that crosses hundreds of millions of aggregates are you going to load up all those or do you want to do a query off to something else and you know you'll pick up that little bit of eventual consistency there but people get so caught up that the read and the write must be totally separated and there's a lot of questions just like this people will start saying that commands they must always return void well no returning a list of errors would also be perfectly acceptable as opposed to using exceptions depending on the language that you're using there are a lot of these little things that people take as you must do things this way and they're not true there's a lot of different ways of building events or systems we're gonna talk more about that in a little while what's interesting is currently on the JVM side everyone's been event sourcing one particular kind of problem and they haven't discovered on a lot of other kinds of problems things that can actually be beneficial inside of these kinds of systems like as an example the ability to get consistency when you're doing a write this is very very valuable in some circumstances but it's not needed for every circumstance other problems that people run into inputs equal outputs in other words if I have a place order command I should have an order placed event and that when I send a command one event should come out the other side this is not true the quintessential example of this is actually in the stock market there is no place trade command in the side the stock market you can place an order and if your order crosses with somebody then you will get a trade occurred out the other side too many systems I see they they haven't realized that there's two sets of use cases inside of the system and every system you look at it has two sets of use cases it has the use cases you can tell it to do and then it has the use cases that it says that it completed again there is no place trade inside the stock market but there is absolutely a trade occurred inside the stock market along with this it's not one-to-one in the stock mark I can say one place order and I can get three trade occurred trade occurred trade occurred order canceled coming back it is not one-to-one in any way and this is a big problem that people run into with modeling of events or systems remember that there's two sets of use cases when we start dealing with these next one-way commands and this one's been going on the DDD CQRS list for like four years now that you must use one-way commands your commands that you send to your system must be fire-and-forget how many people have done that before where you all your commands you must put them on a queue and they will be processed later I'm going to tell you a little secret there's no such thing as a one-way command they don't exist the whole point of a command is I have the ability to tell you know you tell me go to the store I tell you piss off the quintessential example for one-way commands it's used as an ATM where you they will send up to me deduct $50 from Greg's account and this will get queued and I will process it later the ATM gives you money once I say I've cued it in other words ACK starts to mean I have made this durable so now I take it out of the queue I start processing it and something goes wrong I throw a he's a terrorist exception so now what happens some exception handler gets this and sends a message down to the ATM the ATM has wheels spring out of it and it starts chasing you up the street to get the money back no this isn't how it works there is absolutely no such thing as a one-way command if we think about it for a minute a one-way command and when I want to give you an AK it means it's been made durable and will be processed in the future when I receive this one-way command I must accept it I must accept it as a fact and if I disagree with it I can raise another business fact about the fact that I disagree with it oh wait we know what this is called it's an event when we're dealing with this what's happening is not that we have a one-way command it's that we have a downstream event processor and I've seen so many people try to build out business systems like line-of-business systems where they're they're doing asynchronous commands with one-way commands all the way through and sorry for calling them asynchronous it's commonly used one way versus asynchronous and they don't work well on business systems on when we talk about a line of business system when somebody does something they want act to mean this has been done it is accepted everything is good when we start talking about places we want to use one-way commands but we're not going to use one-way commands we're going to change them into events and the system itself is a downstream event processor it receives events from things in the real world a place to know whether or not this kind of events or system is right for you if you can realize that your system is not the book of record this is likely an appropriate system for you likely and we mentioned earlier about domain modeling and how very often because we start looking at things from an event source perspective we end up a breakthroughs happening in our model at a domain level understanding that you are not the book of record is a big one of these like if I were to look at a bank the the bank it's the book of record right for managing ATM machines so if I were to drive a big f-350 at 60 km/h smash it into an ATM and then take all the money out does the bank know about that so the money's still there right now that the bank isn't the system of record the physical ATMs are the system of record and this is very common in systems where if you can recognize you're not the book of record it will actually change the way you start thinking about your problem and in this particular case going through and using client originated events and becoming a downstream event processor is oftentimes quite a good architecture the next bad thing I have told people over and over and over again don't write a CQRS framework there are certain people that must it's like you can tell them this is what's going to happen when you walk down this road I've walked down that road I know what's down there and they go no no no no I need to walk that road for myself and if you go write a secure ask framework an event sourcing framework I can basically guarantee you that it will be abandoned where within one year like every other one has become think about how many secure essent event sourcing frameworks have popped up everyone started using them and then later they realized it is more complicated than where they start and went it's not a framework it's a reference application and there have been about ten of these that have gone through the same process at some point I really hope that we will be able to realize that this is the process that's going to happen and stop upfront but in order to do that what we really need is to get all of the new users that are coming in to recognize the fact that they don't need frameworks for everything as we said before at a functional language the framework was matter of a function a pattern matching a left fold you really don't need a framework for this other ones that come up all the time all usernames must be unique for people on the DDD CQRS list I apologize that this comes up once a week but there's a bigger problem and when people come in and they use all usernames must be unique and this is one of the biggest problems on both the domain-driven design list and on the DDD CQRS list we use really really naive examples it's a shopping cart or it's all user names must be unique and people don't talk about what their real business problems are and what's funny is when you start getting into the real business problems this is where all the interesting stuff actually is it's inside of the specific business problem that the person is working on and you can't just take it down to a simple example and the best threads on the DDD CQRS list when you go through are the ones where people are talking about concrete business problems they normally start with so I've got a student enrolling in a class and then it starts pushing back on what is your real business problem and the problem is if we if we go through and we we don't start focusing on real business problems we end up with situations like one I found in the hotel yesterday that right there if you look closely there's an arrow with the handicapped toilet letting you know it's just up these stairs but this is what happens when we take very naive viewpoints on problems and the single biggest one that that's guilty of this is shopping cart system and I will take the blame for everyone talking about shopping carts because I use those same dance slides for like eight to nine years where I use chopping parts as an example when you really get into a domain of people ordering stuff online and we're going to deliver it to them it is nowhere near as trivial as the example that I made and when people start talking about shopping carts they are absolutely trivial representations of how these systems actually work like people say like we need to check to make sure the inventory is there no you don't if you ever go talk to anybody who has worked on an actual shopping cart the last thing they care about is whether or not there is inventory there you know it's far more important how long it takes to get that thing what is the lead time on it another question what's my margin on it how much money am I going to make out of this do you think we're going to have the same answer to this question with it's a million dollar sailboat versus it's a five dollar coffee cup there is a huge amount of logic that actually sits behind these kinds of systems and we we make trivial examples and we end up with trivial models and this is good for trying to show somebody a structure of something but it's really bad for front trying to show the bet overall process and overall we need to have better examples and I've talked with Eric about this in the past I've talked with Alberto about this in the past for it for both DDD and general domain modeling and event sourcing it's it's really really hard to give people real examples and the reason for this is because people have a very short attention span and if I give them here is a real example it's like now you have a 200 page book to go along with it that actually explains what that thing is and why things are the way they are along with that a big part of it is looking at how the thing changed over time so you probably need to actually give them here's a full github with all the change history with this is why these changes were being made over a period of time on a real business problem and I think the only way that we can get around this is to try to actually use a real business problem or two and go through and actually do real modeling on it based on what I'm seeing here I think a great example of this might be hey let's run a conference what is involved inside of building conference management software from a real deep perspective not from the the naive well we have an attendees table we have speakers we have sessions yes that's some of the data we show on the website but if you really get into the system there's a whole lot of other stuff that happens back office the last bad one I'm going to bring up before we start talking about future is a lack of process managers a lot of people are going through and they're building out lots of little services that are events going back and forth and what they do is they directly tie so each service is subscribing directly to events from other services and there's nothing in the middle and this leads to two big problems later where you try to figure out what my system actually does and I end up having to go through all these bits of code because each one is a piece of the puzzle and trying to figure out what the overall processes is very very difficult process managers are difficult I think the the best explanation of process managers is probably in Gregor hope A's patterns of enterprise integration and there's a footnote at the bottom of where he writes about process managers and he says well you know I've written seven pages about this pattern but you know an entire book could be written about this and it's true there's a lot of patterns you start getting into if process managers that you could literally write an entire book on and there's not that much literature out there in terms of how you should actually be correctly doing that now let's talk about the future by the way for people that didn't quite get it this was from the good the bad and the ugly what are we going to see in the future more functional programming you will see a lot more people doing functional programming along with events or systems for whatever reason people have tied event sourcing into object orientation it is not object-oriented whatsoever it is a purely functional model it is always intended to be functional and it fits really really well with functional code and you're going to start seeing more and more people going through doing functional code on top of events or systems there's probably going to be a lot more push on process managers but thankfully I'm thinking that we're going to get a pullback away from building process manager frameworks and hopefully more people will just use actors for this actors make perfect process managers your actor framework is a process manager framework at the same time I'm hoping we can finally all get over the problem that everyone seems to have with actor models and that how do you test actors well it's freaking trivial they have messages in messages out that's how you test them I don't know why this was ever a problem other things I think we're going to be seeing in areas for research most people building events or systems today are using a process known as linearization linearization is great it simplifies things in many ways because you can do things like you can assume a global ordering of messages which makes your life much much simpler but this doesn't work well on all systems probably 90 95 percent of systems out there you can linearize everything it's a reasonable thing to be doing but in those other five 10% there's a lot of interesting things going on in terms of events or systems right now where people are not linearizing and they're starting to use other forms of consistency they're using causal consistency they're using conflict detection all of these things are quite interesting what's funny for me is that for me one of the most important talks have ever done about event sourcing was actually at skills matter and it was a event sourcing not just for server systems it's currently on there what I was really talking about was building out occasionally connected clients what we're talking about here is occasionally connected servers it's the same idea and they work in the same way but I think we're going to see a lot more of a push towards building occasionally connected systems now when you start looking at this you need to remember 90% of systems you can probably linearize linearization is going to be cheaper for you there are two reasons that you would want to not linearize well three reasons one is occasional connectivity in particular if you have clients that are raising up events and they can lose connections and you want to still work do you want to favor availability there are many systems where availability is going to be preferred over consistency understand though that when you have favorite availability you can get consistency issues and you must deal with them in some way the third reason you might be favoring these kinds of systems is very very high throughput when you have very very high throughput a system built this way that it's occasionally connected will actually outperform especially for latency a system that's going to be fully consistent but I think we're going to start seeing more and more people dealing with these kinds of models for people that are following get events store it will internally support these models probably my guess is quarter two where basically the its servers itself will actually support availability as opposed to consistency with conflict detection but there's other things that we're going to start seeing more with event sourcing and one of the big ones is working client side and the reason we're going to start seeing a lot more of this stuff happening in the client side is because more and more applications need to support occasionally connected use cases where I am using something on my mobile phone and I go into a tunnel and I need to be able to work while I am in the tunnel and then have my work synchronized when I come out the other side there is a well known system that does this that you have probably all used before you may have heard of it it's called git and you're going to see more and more applications working like git event sourcing is a natural model for this and it will it just works it's very simple whether you're talking client-side or whether you're talking server-side replication models it's basically the exact same thing that you're doing well there's another area where I think we're going to start seeing a lot of focus over the next couple years and I've always said that if you want to know anything at all about event sourcing go talk to an accountant because they already know event sourcing they've been doing it for a long time they work in an already event source system and they can tell you how anything you want to do works in an event source system and it's funny for me that not very many people have gotten into this yet because we've always said that it comes from accounting and to talk with accountants what's interesting with accountants is that accountants don't always work with a fixed timeline and I think we're gonna start seeing more and more push towards dealing with n temporal models and eventsource n temporal models where there may be multiple timelines that we may be interested in if you go and talk with an accountant they do this all the time it's very common for instance for me today to call my accountant and say I need this transaction that I'm giving you right now I need to backdate it into last year it needs to go into 2015 even though I'm giving it to you in January at the same time how many of you remember those pieces of paper that used to give to people like you'd write their name on it and some money was kind of like having money when you brought to the bank I think they call them cheques or something they still use those in America what the hell is wrong with those people now literally like someone someone told me they were going to send me a check it's like cool so do you want to fax it to me or but when I write somebody a check I can post-date it so you can put the check into your account today but it doesn't actually go in for a week and then what's interesting with this is now we have two types of queries that we can do for everything we have as of versus as app so in other words we have two time lines on one time line I want to know what you knew as of this point in time on the other one I want to ask you what you knew of at that point in time including things that may have happened later but excluding things that happened before but hadn't been affected yet and these kinds of systems are very very interesting in terms of domain modeling and you'll find them a lot and finance in particular and I haven't really seen a lot of research going on into doing by temporal or n temporal modeling on top of events or systems and it's one of the most interesting areas of dealing with events or systems also in the future I've been told this will be coming out in 2035 no I I think I will I will try to work on it more this year to be fair over the last year year and a half as opposed to working on this I went through and I tried to get all of the same information into videos because I found that to be easier for me to get done and all those videos are now available actually online if you go to my blog and I want to remind everybody especially people have been working with event sourcing for a long time we're all going to be constantly learning new things about events or systems even Eric today learns new things about domain driven design there is no point where you know everything there is about a subject there will always be new things coming out there will always be things that you thought about one way and you've turned out wrong and it was actually something completely different I myself have changed my viewpoints on quite a few things associated with event sourcing over the years and I have no doubt I will change my viewpoints in the future as well you

Channel: Domain-Driven Design Europe

Views: 137,632

Rating: 4.8818474 out of 5

Keywords: domain-driven design, ddd, dddesign, event sourcing, cqrs, software, software design, software architecture, ddd europe, dddeu, domain-driven design europe, eventsourcing

Id: LDW0QWie21s

Length: 48min 3sec (2883 seconds)

Published: Mon Apr 11 2016