Accelerating Event-driven Architecture with Domain-driven Design • Brian Zambrano • GOTO 2023

all right welcome everyone um couple things Eric had to step out for something so I'm gonna introduce myself I'll just I'll just jump I'll just do it during during the presentation um the other thing is I know this is the end of the day and I know that gen is going on over there so for all of you thank thank you very much for showing up I I very much appreciate it I was thinking there was going to be maybe six people here just with those two things going on but anyway I'm glad you're here I'm also going to try to channel my inner uh Eric Johnson and try to keep this fun and Lively I will fail because Erica is really awesome but I'm going to do my best okay this is a topic which I think is going to be a lot of fun for all of us here um please ask I'm sure you're going to have questions along the way so please ask questions in the app and I hope we have enough time at the I think we will have enough time at the end for for some discussion so um this is uh accelerating event driven architectures using domain driven design um so introduction Who Am I who is this guy barking at you up here my name is Brian Z bro I am a specialist Solutions architect at AWS um just some quick background on me I originally came from the San Francisco Bay Area I'm one one of those weird people who grew up in the in the area uh the Silicon Valley and uh I now live in Fort Collins Colorado about an hour north of Denver um I came make probably many of you I came to to it or computers um through a different route I originally started engineering uh at calply in St Louis abiso which which is the Central Coast of California and then later on I went back and did another degree in computer science from San Francisco State um and so I really identify as a developer so I wrote code for a long time mostly at startups in the in the Bay Area um and a few years ago I thought I love AWS I've been an AWS customer for a long time um and I applied and I got hired in I started off as a software engineer so I was doing Development building internal tools at AWS and then I moved over to this dark side of solutions architecture which is now really really fun and I love it and I've been a a specialist essay for a little over a uh actually for about a year and a half now specialist essay so that's where I come from that's me so I like to ask this question question when I talk about event driven architectures um it's just an honest question I get feedback from the audience and I won't do it here so don't worry um but I like to kind of level set so what is event driven architecture we're all here I think you probably all have an idea in your own heads of what this means here's the definition that I like to use and that is uh event driven architecture is an architectural style of building Loosely coupled systems that communicate by emitting and responding to events so that's the one I came up with after some iteration it's pretty succinct the thing i' like to focus in on here is this loose coupling okay and I know this is not new for you so loose coupling this is there's going to be a lot of generalizations in this talk okay so just go with me with the generalizations save your questions we'll we will get there eventually so loose coupling we've got a message broker in the middle we've got these different systems they're sending messages in and messages are coming out cool so with loose coupling when one of these systems fails all these other systems can continue operating and yes there's probably going to be some degraded State something might not be working quite right maybe something's Miss Missing on a UI but overall what we're doing is avoiding this cascading failure effect okay so this is this is loose coupling this is good we like this in event driven systems so distributed systems when you are building an event driven architecture you are building a distributed system there's this paper called uh a note on distributed computing uh this was from some folks at Sun can anyone guess what year this paper came out 93 very very good close 94 so this is uh nearly 30 years old now and if you read it there's a lot of stuff that now makes complete sense but back then they were you know we were moving from the Cal uze single address space applications to distributed computing and so they were you know talking about the things that we need to do and consider when we're moving to this distributed system distributed systems um so I've got really bad news distributed systems are hard they're really hard um it's an active area of of research so these again this is you know sometimes like we we we want things to just work and we're battling just fundamental computer science problems so this is just the the fact of the matter distributed systems are hard so if event driven architectures are distributed systems and distributive systems are hard it stands a reason that advent driven architecture is hard right um this we're going to go down a bit and we're going to come back up so don't worry okay we're going to get get to a happy place on top of that in event driven architectures there are a lot of ideas and Concepts that we have that you all have to consider okay there distributed systems Parts but then there's also all these patterns that you might have heard of you might be thinking about like CQ ORS and The Saga pattern there's different failure scenarios right what do you do when you have a degraded system how do you choose the right event broker how do you find your domains uh scheme of validation Sam dangler was talking about that there's a lot of work around there so there's a lot of stuff going on in here that you all have to to worry about and think about and get right before you know being successful with eventer systems so you might after all this be like whoa I I I maybe I went to the wrong conference maybe I I'm to go back and just build a monolith and it it'll be it'll be way better so you know you probably look like this cat just completely freaked out um I have some good news for you okay here's now we're going to come up we hit we hit the trough now we're going to come back up there's a lot of things that you can there's a lot of ways to work around these complexities okay we've been doing this for you know for a long time now and we have ways of working around the complexities like we can use Tech different Technologies there are well-known patterns uh and you can work around a lot of these again these these complicated topics and ideas uh except for one there's one on this list that you can't work around just magically or look it up in a book or in a blog can anyone guess what that one thing is all right the title of the talk gave it away right finding your domain boundaries so there is no single way to just go and magically again read someone's blog and then get this right it's not that easy the other ones might not be easy but there you can do this so this one takes a little bit more work and that's going to be the topic of what I'm going talking about right now is how do you find these domain boundaries and then really more importantly why are these even important so definition a problem domain is the area that you are all working in within your your organization right so let's just take you know amazon.com an example I mean it's a huge domain but e-commerce that makes sense maybe I'm I don't know I'm selling dog food okay so like the the thing that you are the the business problem that you are trying to solve is your problem domain and presumably you are doing this so that you can make your customers happy make money or just really just like maybe you're a nonprofit you just want to exist as a business business entity okay but that is your problem domain so you you are all working in a problem domain I'm guessing there's they're probably different uh but you know this is the the main concept here you are working within a problem domain so if we draw this out we've got a box that's your problem domain and within there you are going to have subdomain so these are areas of uh you know business functionality or things that you can break up how you can break up a a big problem domain so if you map that to again this is a a overly simplistic diagram if you were to map these problem domains to systems what would it look like when with an event driven archit architecture so again overly simplistic but in an Eda you would have these different areas of responsibility and there's bounded context and subdomains which we can you know there's subtleties in there but the the long and the short of it is these different systems that now serve one particular purpose are going to communicate with a message broker ER okay so now you can break these up in in these different systems into teams different typologies Etc but you know very coly this is how you can map you know subdomains and bounded context to an event driven architecture so the question is how do you find these how do you find these subdomains or these boundaries within your specific uh problem domain how do you do that um who here has seen this book or who who here owns this book a few who knows it who has heard about domain driven design before few who could explain it kind of one person okay don't feel bad the funny thing I have a funny anecdote about this book I own I bought this book probably 15 years ago this is from 2003 um so I probably bought it in 2008 something like that um I actually gave this book Away about a year ago I put on CRA Craigslist I was like I'm never going to read this thing so most I would say probably most people who own this don't understand it they probably started it five different times and never finished it uh it is not a page Turner I can tell you that it is a dry read um it's very dense and complicated um personally I feel like I've just been on this journey of you know trying to find something that can help me and help me help my customers break down a big problem and you know over probably the last year or so maybe like even nine months I feel like I've had some breakthroughs with domain D design finally so if you're one of those people who have been interested in this and have never it's never really sunken do not feel bad you are in good company I think pretty pretty much everyone goes through that so what is for the people who don't know what is domain driven design U this is the a quote from from the author um Eric Evans and so the quote is domain driven design is both a way of thinking and a set of priorities aimed at at accelerating software projects that have to deal with complicated domains so that's pretty good it's a little little bit ambiguous and we're going to go deeper into really figuring out what this is and how to use it effectively um just like Eda domain driven design like I mentioned earlier is complicated so if you just go out and you know type it into your favorite search engine you're going to get a lot of stuff so I just typed it in randomly found a bunch of different things slapped them on here it's confusing it's complicated we get that um I think this is one of the key points here is that demand driven design focuses on understanding your domains your subdomains your your problem domains not necessarily how to implement those you can get to that level and I think that's where a lot of us developers go wrong is we look at this big book and we read it and we try to immediately start applying it to code that's where I think this thing goes completely off the off the rails so if we think about this and level set this is about understanding it's not necessarily about building and applying and turning that into into code artifacts so that's really really key so if again if you've been confused or you're not even familiar with domain driven design don't worry just think about this is a tool to help me and my team teams understand what we're doing so that theme is going to carry through here so it helps you and and your teams find this shared language that you can use when you're talking to when Engineers are talking to business or when business are talking to engineers and really I would extend that to you know anyone in the company like once you have the shared language you can speak the same language and those miscommunications the idea is those are drastically reduced or or or go away in an Ideal World um this I think this is a great quote that I like to use often so this is from Alberto brandolini who created something called event storming which I'm going to go into shortly and the quote is it's developers misunderstanding not domain experts knowledge that gets released into production so you know think about how many times you've seen or heard the product people are saying why is this working this way that is it's not because the engineers are stupid it's because they didn't understand what we they needed to implement they implement we Implement what we understand the problem to be or the solution to the problem and so this happens all the time when you know companies organizations are not building the right thing I would argue a lot of it comes back to miscommunication between product the company and the engineers who are building it so this is really key um I see this all the time and I've you feel like I'm like this all you know very often where um you know if I'm if I'm talking to customers the engineers are dogs on a leash and they are just ready to get to be be let loose like they want to go and write code and if you let them off the leash they will go they they said what can I do give me some technology I want to go do this I'm so excited to do this and you know if you do that oftentimes you end up with this where they can go and attack a problem and they think they're doing a great job because they're slinging code around they're you know integrating all these different ad services and it's awesome and it's fun but then at the end of all this it's like did you build the right thing or hey like we ended up somewhere and now I've got this other problem because I didn't think through where these boundaries exist within my application or within my my my my problem domain so to to prevent this we need some way to get people thinking the right way um so how do we bring order to other order to an otherwise complex uh or I call it non-trivial system or domain how do you do that so if you go back to that misunderstanding quote if developers misunderstand the domain and make a mess turn your developers into domain experts that's the really the key thing here is coming to that shared understanding and making your engineers understand and really be the experts of the domain and I'd say even turn your teams turn as many people as you can within your organization into domain experts and so event storming is a tool that I found a while ago which I think I haven't found anything that is better than than than this um so event storming is a is a process to it's a workshop based approach to find your domains to figure out your boundaries uh to explore and learn together so I'm going to walk through how this works now in more detail so like I said it's a workshop based approach to to to break down a non-trivial domain into its constituent Parts uh the main goal of this again is to come to a shared understanding the main output is not to go and have a code artifact that you can deploy to production that is not it the main idea of this and the main goal is to come to a shared understanding so this is a diagram that uh the person that I was trained by came up with and I like I like this a lot so there are different versions or different flavors of event storming uh the first one is this thing at the top called a big picture event storming and what this is is you know if on the left on the Y AIS this is really like the the level of detail so this is like really high 30,000 foot overview you know like big picture the name hopefully you know makes sense but what you're doing is maybe you're a startup or maybe you're taking a monolithic application and you want to modernize or you're doing some big project and you need to figure out out what does this thing do like do we even understand this end to end again whether it's an existing process or something completely new like you know do we know how this works or how it should work so the big picture of event storming session is pretty high level um down on the left if you're look this is more around looking at current state so what is the current state of this thing um also in terms of people like who's going to you know participate in this the big thing here again is you know for a shared understanding you've got to share so you have to have a cross-section of your organization there in a big picture of vent storming it's going to lean a little bit more towards the business folks to the people who who who are you know uh domain experts already or who have an idea of what this thing should be and of course like we want to have Engineers but we also want to have product people we might have uh you know leaders within the organization so anyone with a vested interest in this thing that you're building should be here and I say that because you know it's a spectrum so it should not be a room full of 12 Engineers that's not going to go well generally um for especially for you know for a big picture one once you zoom in a little bit more you can get to a little bit more detail um so that is a process level event storming session so it's this now spans like you know current state and the future state so you might get into solutioning a little bit in terms of hey we've got an opportunity here to improve this this thing slow um and you get into again a little bit more little more more detail from on the engineering side so this this now that I think the Spectrum widens on who you're who you're bringing in in and also what you're doing now you're talking about both you know the current state and the future States uh and then in here you're probably also going to be you know talking across teams if you've got something fairly complex you might it's not going to be just one team it's going to be multiple teams uh and talking about this together again a little bit more detail and the last one is this design level event storing session so now this one now we're shifting more towards the future so this is what we want to do uh and really also a little bit closer to how we're going to do it so whereas the big picture one favors uh The Business Leaders and business owners product owners a little bit um this design one is going to focus a little bit more on the engineering side so you'll still have product owners uh but you're going to have more Engineers here and talk about a little bit more uh you talk closer to the implementation details so for this talk what I wanted to do was talk through what a big picture event storming session would look like um there's a lot of detail in this so we don't have a lot of time uh so I did want to focus on this one and just talk about if you were want to do this yourself or have someone at ABS come and help you with this what would that look like how what what does the process look like what are the steps involved so I'm going to focus on big picture so first off of course there's this you know we have to Define what an event is um so an event is something that a domain expert cares about okay and we know that events are immutable facts that have occurred in the past so once an event has happened it's done like you can't take that back it's it's already been triggered um so step one step one is inviting the right people and I alluded to this at the beginning it's just a little bit but you have to have the right people in the in the audience in the room so you know for a physical you know physical there's different versions of this in terms of doing this physically on paper with stickies or doing it virtually but no matter what you do you have to have the right people in the room so for a big picture event storming session like I said product owners uh business folks if you can get some leaders or people who really care about this thing or have some idea of what what it should be doing you're probably going to want some people who've implemented it you the if you're working especially on an existing solution so people who have you know have an idea of how it works today so bring those people in into the room again the sharing of knowledge is the key part with all of this so you have to have the Right audience in order for this uh to to work so step so I've kind of enumerated this step one step two it's it's not really this linear I mean there's a lot of you know this goes all over the place but just for the sake of uh of of clarity I'm trying to sequence in a little bit so once you have your audience the next thing is you know running your session and what you do is start with crowdsourcing all of the events that you can think about that make up a particular business process and so how this looks is everyone writes events individually and don't worry about the details at all like you know this is a brainstorming session and it's a way to come to to again that shared understanding and so like there's really no wrong answer here this is an exploratory part of the process is everyone's just just dumping out as many events as they can think of in order to make this this business process work so what it looks like is this so people are are writing sticky notes we have orange sticky notes if this is in in person these are literally you know the little you know Post-it notes orange is representative of events usually it doesn't matter what color as long as you're using the same color um and so here you know what this is showing is um if you look at the the names of the events this actually ties back to serous espresso uh and so we did this internally there's spelling mistakes in here and so I I literally copied a subset of what we did and put it into here and so as people are creating these events just carve out a part of the either physical board physical paper or uh virtual board carve out a space and start putting them in different locations once everyone does that your next exercise as a group is to sequence these things uh and this is very rough right again there's you're not going to get this right the first time at all this is exploration and so if you think about you know time is on the x- axis participants will take all their sticky notes again either virtual or physical and put them in a rough sequence of how this business process this this thing flows from left to right so if you'll notice here there a there's a lot of duplicates like there are many dup every single one of you know every single event in here has a duplicate and duplication is good duplication very good because it means that people think are thinking about something and it's something that's probably pretty important so it's it's top of mind for a lot of people and inevitably you're going to create you're going to have a whole bunch of crazy things out there um so this is again this is a very simplistic overview but duplication is something that you would expect that you would hope for and you would want to drill into to and as this Workshop continues these things start gaining more and more importance so as you're going through this you know more events are showing up um we use something called hotspots to really represent anything that is a question um so if you go and read you know the event storming any handbooks or whatever hotpots is a term that uh that that is used again these can be questions they can be problems they can anything that you're uncertain of so you know in this case we could say hey um this step like it's it's happening it's important but we're asking the Barista to go and push this button does that slow the Barista down or someone might say like this is is a really bad area of our application today like we know this is a problem or we had a question when we were doing this a while ago when is the receipt actually printed we don't know is it before this event or after this event so that's fine grab a a a pink sticky put it on the board it's like we have to answer this um I did this with a uh an Enterprise customer last week and uh it was very it was a complex domain so as we were doing this and exploring um over and over again you know we they they would come up with something like oh what about this other thing that we were integrating with and so they grab a pink sticky put it over and at the end at the end of this whole session they said there's a lot of stuff that we don't know in here and that's part of this process that's part of exploration so that is a good outcome from this because unless you can go and answer those things any implementation you have is probably not going to be quite right and you'd have to figure that out as you were building which arguably is a little bit less efficient way of of doing this or building okay so the next step is you have some events you have a general sequence of your events of your of your business process you have some questions in hotpots so the next thing in here would be to add in people um you might hear or see this referred to as actors I do like the term people because this uh it's just more tangible it's like it just makes more sense to people um so it's not personas is literally like what you know what person is doing this thing or here it's you know I think about it is what what person is served by this events so here at the beginning you know when the uh the the Bree is receiving an order it's really the the Barista who is the recipient of that event that's the person who is served by that event over on the right we have now the customer we've moved over to this customer area where once an order has been sheded out even though the bar is performing the action it's the customer who is the recipient of that action so you can add people along this timeline too to figure out what's happening in this process like who who are the the individuals U or groups of people who who are U benefiting or interacting with these events okay so now we get to uh an important part which are called pivotal events pivotal events key events I mentioned earlier that this duplication is good duplication of events is good because multiple people have thought about this it's an important thing so when you see a lot of stickies or a lot of you know virtual cards that are lining up and are all kind of the same thing they don't have to be written the same way but they're going to represent the same idea and there's going to be discussion around this so when you see that that's a clue that there's something going on here this is the emergent structure of of of boundaries right this is not necessarily like a a bounded context or a subdomain between these two uh blue blue U markers but I think it's the emergence of something it's a it's a clue so when you start seeing these pivotal events I think a few things happen one it starts to add a little bit of order to the board and people can start seeing like oh there's some there's some shape taking place here um and then the other thing is just that like you know it just visually helps you uh organize but then also again you start seeing Clues into how you might be able to break this thing apart uh next is identifying external systems so you are all presumably building software um there are things that you're going to own systems and there are things that you were not going to own so for example in servess espresso there is a printer the printer is attached to the network we don't really control that right so that's an external system that we need to interface with that we have almost no control over I mean you know you can argue a little bit there but the network might go out something might happen so any system that you interface with that you don't own or that you can you know in in the in the literature in the books uh one of the the the way it's described is any system that you can where you can blame someone else that's the system okay so you can add systems throughout here to figure out again what you're interfacing with okay when you zoom out I mean I was giving you a very simple you know kind of linear flow but what happens when there are things that are happening in parallel or or asynchronously right so you might have a single process like inevitably like most domains are not really linear um you know one thing I do with and I've done myself is event storming a movie and that's really nice because it gets you warmed up and it's pretty easy to understand but a movie is inherently linear right I mean you start at the beginning and you go to the end but software in the real world isn't that simple so what happens when there are systems or processes that happen at the same time in parallel for that you can use these things called Swim lanes and there are different ways to break this up but swim Lanes I think is a really nice one again and Visually if you look at this you can you don't even have to know what the what these are I mean there there's there's no detail on these cards but you can see that there's a main process up top that has some pivotal events so there's some things going on there with some again the indication of boundaries down below we have another area that is independent so it's we're we're working within the same domain but we have these two different processes going on that probably are going to be working together but may not line up up kind of end to end in the linear process okay so as you start going through this things are going to start taking shape slowly so this is an emergent structure the structure does not just appear out of you know right away it emerges eventually slowly as you are moving cards around having discussions talking about this and so here you know the first front part of this might be coffee ordering and now the middle is coffee fulfillment now we're actually the Bree is making the coffee and at the end finally it's delivery but you know down below what might be happening in parallel with that well maybe we have something where we're keeping track of the number of Cups and the number of Lids the number of coffee beans and we have someone going and fetching more stuff as the orders are coming in well that's really important but we can do that in parallel with the the main coffee ordering so these are we're again here we're now with this example we're in the same domain of the Serv espresso thing but we have different processes happening in parallel and now we can start seeing like there's there's there's some subdomains in here right cashier Ops versus coffee ordering okay so once you get to this place where you have these you know a general flow one trick or one tool in here is to have someone walk through the entire story so literally get up to the board and start the the very beginning so a person want to show up and say okay I'm going to read these cards and say a user scans the QR code on their phone then they go the next step the customer then browses the menu and places an order and they're literally walking through this and reading each thing and there might be discussion along the way get a get a get a red sticky or a pink sticky for questions if there if any come up there might be some reordering or some sequencing the Breer receives the order the Barista prepares a drink and then finally the Barista calls out the customer's name and they pick it up so you're tying what you've just discovered to a a business process and having someone talk through it in just plain words uh is is really interesting and fascinating because it has to make sense right you're discovering this together um another trick here that you can use is doing this backwards so going the other way so at the end you know like if you're doing a movie they lived happily ever after before that happened this happened and what that forces sometimes is uh asking a question wait does this event does this event really happen after this thing like that doesn't really make sense to me and so you can go both ways here go forward to backwards and backwards to forwards if again Force those conversations and see if this makes sense you're discovering together you're learning this all together okay as you go what's going to happen is that there will be areas of the board that still don't feel quite right right like over here this area on the right might not be quite quite what you're you might not be quite happy with that it might need a little bit more refinement that's okay other areas are feeling good like we've done okay I we're very confident about that this is an iterative process right like those areas that need refinement you will go back and talk about them and refine them that's okay you're again it's iterative you're learning about this um eventually what you'll see is that this whole thing is going to start to make sense uh the customer I worked with last week um I was a little bit I wasn't quite sure I thought there we still needed a little bit more refinement but I had them walk through the whole thing and this was an all day workshop that we did um and everyone was engaged and so they read through the entire thing and they're like yeah they said this is this is good like we're we're happy with this they had a bunch of questions they did not know answers to those questions but overall the entire flow just made sense to them like there was tons of detail buried in there but we were at the point where again we were doing this big picture session and so the end to end flow they were feeling really positive about and so this flow and this this this you know this whole front to back again it's an emergent structure that will start to to show as you're working through this process okay uh another thing that you can do in here is something called um adding you know business value so what you can do is have uh a different sticky where give people a couple of votes and say like where is uh an area where we can either raise our value or lower our value in here and value is arbitrary it can be time saved it can be dollars uh it can be your reputation so no matter what your value is where does that actually you know go up or go down um and so as people start adding this you might see like H hey this one area we've got a bunch of question people calling this out with hot spots like this is bad this is slow and people are saying our value is going down here whatever that is right again whether it's time or developer re it it doesn't really matter this would be an area to focus in on right this is an area for improvement because your value is going down and people are calling it out as you know obviously with the with the hot spots they've already called it out uh as something to to improve uh and then on the flip side when your value is going up if the value is going up for a certain area maybe that's an area where you're underst staffed and you don't have enough engineering resources to go and focus in on that would be another again area to focus in on because that's how you're either making money or doing something to to improve the system okay uh I'm going to declare that I think getting your boundaries right is the the biggest design decision that you will make when you're building software you have to get these right you know all the technology in the world is not going to help you unless you can get these correct and this is tricky it's definitely tricky um this is the the definition of what a bounded context is from from Alberto uh so ideally a bounded context should contain a model tailed around a specific purpose the perfectly shaped tool for one specific for one specific job no trade-offs so sort of like the Unix philosophy do it do one thing and do it well so you know if you've heard of bounded context uh it's kind of squishy to kind of Define what that is but this is his definition which I like a lot so it's one it's something that does one thing and it does it does it very well so how do you find you know we've done this awesome storming session we've got these stickies all over we've got some swim lanes and and boundaries how do you identify the bounded contexts within within here and you might think oh that's easy because it's just we have these the swim Lanes in the in the pivotal event so it's just the things in between there and that's not quite right so these are indications but this is it's not a onetoone mapping it's not quite that simple um and so you know unfortunately you have to do a little bit more work here so there are ways to identify based on what you have there are ways and tricks to identify where your bounded contexts are uh and these are just some of them so I mean I say these are probably the the main ones so obviously look at the pivotal events I think those are very good clues about where your your contexts may may lie you can also look at the people on the board so when there's a handoff you know in our example from the Barista to the customer that's another clue that there's something going on there that there's a boundary because the the people are changing you know in this so there's maybe there's some exchange going on um and you can also look at as you're doing this with your team what is the language that people are using are people saying the same things within a particular area probably if there's a grouping of the same language again that's another very good clue that you've got a boundary there and then you know if you're working with your team you can look at the interaction there might be a group of people who are often a you know in one area talking about something so that's just a a a physical clue that there's something going on in a particular part of the board so in reality um you know your boundaries might look more like this where you've got these again these are all within a you know within the pivotal events and In The Swim Lanes so it's not a onetoone mapping but it again it might look something similar to this okay and you know this is a simple drawing so it's probably not this this obvious in the real world but this gives you an idea that it is um it's a little bit more complex than just the the pivotal events so if you look at those how would you break this up so the first you know again this is made up but those first three bounded contexts might be one particular subdomain so you might be those those three bounded contexts might be solving a similar problem but there there are boundaries between those so you might give that to team one and then team three might have their own and you can see how this how expands out so again this depends on your own you know organizational structure but you can see how now you can start taking these bounded contexts and start Distributing the workouts and now there's purpose and there's structure between how you organize yourselves and your software so with event driven systems how would you tie these together well you already have the events you've done the events and of course you're going to refine those but you you have a very good starting point and you have your boundaries so now you you know you have your your you know close to getting your microservices down your systems down and so now it should be fairly easy and I'm not gonna say it's it is easy but it should be easier to figure out how to map this to an event driven architecture uh and people always ask well how many services do I need to know which is it a onetoone mapping I don't know I mean I don't really worry about that too much um but for this you know for this bounded context maybe there's two services in there uh maybe that one down on the bottom right maybe it's just a single Lambda function I really don't know but the big thing here is figuring out again where those boundaries exist how you implement those is going to be up to you um again this is a slippery slope because you can get into all sorts of stuff to figure out what this should be and how big they should be and I don't really know the answer honestly I think it's going to be up to you um but again just the one thing I want to drive home here is that it's not a onetoone mapping okay one bounded context could be one microservice or it could be n and I don't know what n is it's probably not a thousand but it's probably you know very often more than one um so if you start seeing this showing up like hey I'm going to build a vent driven architecture with this and you start seeing these gigantic leaps between systems from front to back I would say that's a smell so it's probably a sign that something's not quite right so are there going to be leaps kind of in different parts and sure I I can imagine that but if you see something like this you know the the start of the movie and going to happily ever after does not make sense right and it's the same thing with your software there are going to be uh you know again like I said leaps and maybe some Loops but if you see they see these gigantic movements across the timeline a sign that something's probably not quite right okay at the end here I want to go over um finding the right scope so when you're using language like earlier I was saying you know coffee fulfillment coffee ordering so I see this a lot also and I I again I am I struggle with this myself so what is the right scope of of a of a subdomain or even just of an idea so like order delivery who thinks that's a good one it's a trick question right so order delivery well what are you what are you ordering or what are you delivering um so here's a picture from my house just a little while ago you can see the pumpkins that's just recent right it's Halloween so here's an Amazon delivery so this is a delivery order delivery so's that I just ordered some f35s right that's the Joint Strike Fighter who's the customer of this well you've got this fool on the left versus the Department of Defense so delivery and customers those are very different things and so this is where again think about the the the domain that you're operating in who is your customer even the F35 there are three different versions of it and who do you want to well there's the Department of Defense but there's also all these countries and I couldn't even fit all the flags on here so ordering something and delivering something are not specific enough at all and so this happens a lot and I think it t takes time you when you're doing this you are probably going to need to break down your naming conventions your do remains a lot further than you think even with my S example of Serv serverless espresso so coffee ordered that's a terrible one is it an online order is it in person was it from the mobile app was it from somebody else who's picking it up for their manager I don't know so you need to get a lot more specific generally uh when you're coming up with your domains and and bounded context so that's another really key Point here iterate on this if you get it wrong you'll probably know um but you'll have to come back I mean getting these things right is really key so as you keep going and going it get the you know event storming does have many more things uh I'll just call them things um available so you'll see this there's this this picture in the upper left um there are things called read models and we've got Aggregates and there are other things start small that's my advice to you if you go out and read all the the event storming literature or the books you'll read this it's like okay I've I'm not getting it quite right I did that so my advice is start with just the basics like like I said at the beginning start with events you can go a long way with just events just events and and and pivotal events that right there will get things moving along pretty quickly so don't over complicate it the picture down the right uh is it's pulled that off of you know PowerPoint so apparently that is a real World session uh and if you I don't know if you can see it on the screen but if you look closely you can see some white lines and so there they're starting to carve out their boundaries okay this will happen like you will be able to do this again don't overthink this and don't over complicated I assert that even a very poorly run event storing session is better than nothing at all like you can go a long way even if you're a novice so practice and try it these feel free to scam these These are two um two books the first one they're both on lean Pub they both say that they're not complete but they're still worth buying uh but the first one's from again the the Creator Alberto brandolini uh and the second one is by another trainer called Paul rer uh he is very good I was fortunate enough to get training but from him um just a little while ago and he has an event storming handbook which is a little bit more practical advice a little bit less on the theory and more on how to facilitate your own event storming session so again both of these on lean Pub both very worthwhile and that is the end so thank you very [Applause] much

Channel: GOTO Conferences

Views: 4,404

Keywords: GOTO, GOTOcon, GOTO Conference, GOTO (Software Conference), Videos for Developers, Computer Science, Programming, Software Engineering, GOTOpia, Tech, Software Development, Tech Channel, Tech Conference, GOTOeda, GOTO EDA Day, GOTO EDA Day Nashville, EDA, DDD, Event-driven Architecture, Serverless, Software Architecture, Microservices, Asynchronous Events, AWS, Domain-Driven Design, Event Storming

Id: FG4UOoEJvBc

Length: 46min 55sec (2815 seconds)

Published: Thu Jan 11 2024