Justin Holmes - Talk Session: Visualizing Your Event Storm in New Ways

[Music] all right well thanks everyone for joining it's here the last session of the day so I'm really excited to give this talk I think for many of us we've realized that events storming has really changed the way this community has worked and that's really exciting I think the fact that we're in 2018 really talking about collaborative practices for putting domain-driven design into practice instead of just talking about the abstract concepts and what's an aggregate and what's an event that's really exciting and so the hope of this talk is that we can build on that a bit so my name is Justin Holmes I work at Red Hat's open innovation labs and I'm fortunate enough to spend most of my time doing DD exploration so very thankful for that since we started at the Innovation Lab we've been using an event storming extensively actually this was the first lab we did in Ireland and that was the first event storm I did so that was early 2017 so since late 2016 been working with the approach and we've loved it and been using it ever since and what I want to do first is caution everyone that this is part of the explore and explore DDD so I don't want anyone to walk away from this saying hey Justin Holmes said he's doing this thing in production and it's rock-solid and it's totally figured out that it's not today's talk today this talk is about an idea that I think's interesting I'm going to present to you the value hypothesis that I see with this idea and then I'm gonna invite you for feedback so I'd really like to hear more about your thoughts and whether you see this working in your domain okay so woods the thesis so up on the board here up over there and up over on that wall you've got an event storm and so most folks should be kind of familiar with that this event storm models out a ride hailing service so the process of requesting a ride and then a driver come in to pick you up and all the event storms are the same and I see what's really exciting about 20:18 is there's a lot of teams that are doing this now and there's a lot of groups that are getting together they're having conversations between domain experts they're bringing software folks into the room maybe even their leaders their managers their executives and they've got this great format for having a conversation and at times though we struggle to keep going what comes after this and so what I'd like to present today is a thought around how we might do that so the thesis I'm going to present today is that there are certain domains there are certain teams that have a need to widely share their domain understanding not every projects like this but there are some projects that are and I'm going to give a few examples in a moment but in those contexts when we have teams working together and they've got a wide array of people that might be geographically distributed they might be distributed by role and that that wide circle of humans needs to share that domain model that domain understanding that there's a benefit that this those sorts of teams might have from using a reactive BPM approach a business process monitoring or modeling approach we'll talk about what that means in a sec that these teams would benefit from using reactive BPM to take an event storm and turn it into an executable specification so an executable specification is a term that came out of the specification by example or behavior driven development community and it's got some really interesting properties on how it works in an agile delivery process and how it works in a documentation fashion so that's that's the thesis that's what were going to focus on today and I've sort of put up a picture here of when an event storm might look like this is the same event storm you see up on the walls and the BPM representation of it at runtime underneath so we're gonna take five steps today and these five steps I hope are gonna make this idea clearer the first thing I want to do is clearly establish the value hypothesis because again this is an exploration phase and so maybe there's some assumptions that are off here and we need some help clarifying those once I've done that I want to be a little bit more specific and clear about what I mean by reactive bpm how they might be different than what we traditionally think about as BPM I have a suspicion that this community is a little averse the tools like business rules and business process management so I'm hoping to dissuade you of some of that aversion and then I want to take a small digression given the context here and provide a theoretical foundation in particular I think there's some really interesting conceptual similarities that led to the BPM community forming and how that relates to principles and practices that we cherish here within the domain-driven design community and I think it helps to take a step back and understand those principles before we really look deeply at the practices themselves because if the practices don't put the principles into play there's no point doing them so we want to take a small digression and make sure that we understand the principles and the values first before we get really deep into how this works then we're going to take a look at working software which demo gods willing will will play nicely and then potentially the end here might not be we might do in the hallways and might do it here I want to ask for feedback and see what you think okay so let's jump into the value hypothesis to do this I'm going to use a technique called impact mapping show of hands who's used or heard of impact mapping all right so we got like fifteen to twenty percent of the room I'm gonna use impact mapping to describe my value hypothesis here and so when you work with impact mapping the first thing you do is you establish why you establish a goal and so in my case as I mentioned I think the goal here is broadening the circle of shared understanding when that's an important requirement of the domain you're working in now that's not going to be every domain it's not going to be every team and that's important so any practice has a good context in which it works this one is is towards this broad circle type scenario and so let's look at some examples because the examples are clarifying so a good example is for any of these cases and I'll talk about the role in a minute it's it's any sort of organization has a large business operations component so I'm not talking about IT ops I'm not talking about servers I'm talking about people who work in call centers people that are answering customer questions maybe directly over the phone over email anytime there's a large business operations group that's ultimately taking the results or the status of a piece of software and then communicating that to a customer so some examples travel booking is a great example we call in and we make changes to our travel all the time and so there's a piece of software that a travel agent is using or a support agent is using and they need to understand how that software is working so that you can understand what's going on insurance claims credit applications those are similar scenarios where there's a large group of business operations staff that's ultimately supporting you as a customer in the end so that's the primary the primary user driving this business operations teams I think can benefit quite a bit by increasing their use of domain language we've found a lot of value in ubiquitous language within product development it makes sense that when we ultimately have our user community to sort of understand that domain language because they're not the end user they have to communicate one step further out to the customer and that's represented here so we've got the goal that's the why we've got actors that's the who who can help us achieve the goal and then impacts which are changes in behavior so I've denoted that with an up arrow or a down arrow it's an easy way to think about how we change our behavior there's a delta here so the second behavior that I'm interested in changing is improving system level understanding to make sure that business operations teams have a more systemic view of what's happening and how that leads from Step a to step B to step C and what might go wrong between B and C so the big picture what does that look like I'm also interested in how product owners fit into an iterative development process and one thing that's interesting I think is incredibly exciting about the event storming community and I think for what it's worth the domain storytelling community which I found out about today and I think it's working towards similar goals is it's a very inviting way for domain experts to come into the software delivery process it doesn't start with with reading a textbook and textbooks are great and they're the foundation of why we're here but they're not always the most inviting and so I think we've had great success with event storming and domain storytelling bringing a broader group of people into the software delivery process however I've had some challenges with maintaining that enthusiasm maintaining that confidence as time goes on because as we all know software delivery is hard it's great when we get sticky notes up there and that's exciting it feels like we've made great progress and then you hit your first nasty defect and then the database has an issue and maybe your product owner isn't quite as convinced as they were in week one when you started with your event storm as they are in week 10 that we're really moving forward that that shared understanding is really there and and we've continued forward so I'm interested increasing that confidence and sustaining that confidence throughout a software delivery process and what I'm going to argue here is that there's some scope that can help us achieve those behavioral changes that weren't what that were after these impacts and that's translating an event storm into a reactive business process model and again I'm going to clarify with specificity what I mean by reactive BPM next so that's half of the equation we also have software experts who are building products and I'm interested in modifying their behavior a bit to ultimately to get to this goal of widened shared understanding I've labeled a group here founding developers and if anyone's got a better name I'm interested in hearing it but I'm referring to folks who are starting projects who are early phases who are making key design decisions that they're that folks who come after them gonna live with for a very long time and I'm really interested in getting these founding developers to increase their use of event modeling and event logging I think event logging is one of this like incredibly cool software delivery practices that not a lot of teams do but has so many downstream implications that it's amazing particularly when we're thinking about business operations business operations teams need to know what happened when because they're not the end user they need to tell the customer oh we've we've moved you from seed A to C B and here's why and they need to know the order in which those things happened and so I really want to encourage these founding developers to increase their use of event modeling and an event logging and then after that I'm interested in again not the the group that starts but the group that comes after because there's an evolution to software delivery teams and software projects so not everyone who's in the room on day one is going to be there a month three months six so how do we make it easier for those people and I'm not just talking about developers and a lot of organizations this means testers it might be analysts of some store of some sort your product owner might change so how do we get those people up to speed how do we reduce the time it takes for them to onboard and finally I'm interested particularly interested in remote team members and this might be the nature of my customers but I work in a lot of environments that have geo distributed teams so they might have a team in North America they might have one somewhere in Asia they might have someone somewhere in Europe and I think we've all experienced that's a challenge and yes there's ways to help manage that with bounded context and context Maps and kind of keeping teams in different parts but at the end of the day we have long-running business processes that are going to cross bounded context and there's a need for system level view across geo distributed teams this gets particularly hard to not just because of the time are the the spatial difference but time difference there's not always a lot of time to have real live real time conversation so it's hard for a team in New York to do an event storm with the team it's just a physical challenge so what I'm interested in here is how we can use an event storm to become an executable specification a lot of the ways I view event storms right now are similar to if you're using a behavior driven development approach and you're creating a set of scenarios to clarify your domain a lot of teams get a lot of value out of that by never doing anything more than just specifying the scenarios they get together they talk through the scenarios they write them down in English they walk out of the room and they never touch it again there's a lot of value there I think event storming for a lot of teams looks the same way but in the behavior driven development world a lot of teams then take their scenarios they turn them into unit tests or integration tests and they run them in a CI system and they turn to turn out to be documentation that evolves with the system and because their tests and because they're going through a CI system they've got to be up to date otherwise the build breaks and so we have this wonderful artifact this specification of how the system should work and in the BDD world you write this in human readable language these scenarios and then you map that to test case so it's an English or whatever language you're working in and there's a lot of value in this executable specification because I don't have the separate documentation tasks I've built in self documenting approach into the way I'm working and so I'm wondering is there a way for us to do that with event storming and I'm going to argue here that an executable specification can be created from an event storm using a rack reactive BPM approach okay so that takes us out of the first part and into the second part so what's BPM traditional business process management world has looked has two kind of two flavors flavor one is a big process engine that sits on top it might live in a central ESB and it's an Orchestrator it tells service one what to do takes the result does a translation between its domain language then it tells service to what to so forth and so on and so as your business process grows the amount of translation overhead and orchestration overhead inside this central bit process engine gross and that creates challenges right we're a community trained to look at this picture this context map and go huh there's a lot of dependencies on that process engine isn't there that's the whole point of context mapping is it's supposed to visually tell us there might be an issue here and a lot of organizations have experienced this because release one might only have three contexts released five might have 20 how do we manage that problem most people don't they fail that's been the experience the industry's had the other option is you build a big old monolith and you put everything in the BPM engine and nothing leaves and all the data is there and this it might be great from a vendor's perspective but if you're really trying to improve over time and an iteratively release new valuable software you're probably going to have an issue with this I think reactive BPM looks different and that's my hope an important property of this is that our process engine has to be one way it has to be conformist to use context mapping language so it's not going to try and understand the different languages it's going to create a really simple simple language that just understands domain events and translates them to something called a signal and a signal is basically the way that you event in a BPM language so how do I pass in these signals or these events to the the process engine and that's all its gonna do it's just going to map an event name to a map of data so doesn't matter what day it comes and it doesn't matter what name I just need to know that a domain event occurred that's it and once I create that mapping it works for every context that will ever live because all domain events look the same they've got a timestamp I occurred on at this time they might have an index they've got a name and then they've got a map of data the other thing is it's again the nature of one way is it's read-only so there's not going to be this software delivery effort inside the process engine to understand one language translated to another one and then send something back you're never going to see an event come back out so it's kind of like a CQRS projection if you're familiar with command query responsibility it's just listening to data and it's creating a process-oriented projection of the data and I've just summed up those points again so in a traditional world you're dealing with orchestration reactive BPM world we're looking for a stream of devayne events in traditional world you're gonna do a lot of heavy coding there's no way around it because you've got all this mapping to do and and everyone who's worked in software knows it's one thing to say the translation is easy and oh my graphical interface is going to be able to do it and then you get into the details and we all know it's a lot harder than that the main translation is a challenge and so and I again I work for a vendor there's no way around it there's going to be a lot of code if you're doing that translation in a reactive world we're just listening so we're just read-only we're not going to do the translation and so you can get to a point where you just set up the initial infrastructure so maybe you've decided to adopt Kafka or you're gonna use a MQ AMQP world it doesn't really matter once you've decided how you're going to be sending these messages maybe you use rest it doesn't really matter once you've decided on the protocol and you've decided on the shape of a domain event just it's gonna have a name it's gonna have a timestamp then every context will look the same you don't really need to code anymore it's going to be distributed and in a reactive world versus a more traditional centralized world and in a sense in a traditional world we need to be centralized because the same runtime has to have access to all the other processes because he needs to call them and orchestrate the downstream process and in a traditional world you're gonna need to know a lot about BPMN too because you're gonna have to do all of this coding and have timeouts and all this other stuff because it's not a general-purpose programming language you need to learn the language of the process engine in a reactive world I just kind of want in a flowchart sequence of events that we can talk about alright I'm gonna take a small digression here and I'll try and keep this one short but I want to establish a theoretical foundation here again because I'm a little afraid of of an aversion within our community to these kinds of tools and so I want to take a step back and I want folks to understand where these tools are coming from and hopefully convince you that they're marching towards the same end so to do that I want to introduce this guy anybody in the room know who this is raise your hand who is this yeah this is Willie will ya Williams ever Deming and there was a great talk I've got it linked in this that Martin Fowler just did about the state of a j'l in 2018 and in that talk he argues that Frederick Frederick Taylor is probably someone you might not know but did more harm in the 9th or 20th century than anyone else and I'm gonna argue that William Deming might have they might be one of these guys you don't know that did more good and change the daily life for the average person and then perhaps anyone else in the 20th century Deming comes from the statistical process control community which was a place that was started by Walter Shore in the early 1900's and that community thought if if you can't describe what you're doing in a process you don't really know what you're doing now statistical process control was really really really important it was a field largely driven by mathematicians and mechanical engineers who were interested in building better factories how did we increase output you got to remember sort of early 19th century industrial revolution and and cars and manufacturing lines and assembly lines and really changing the way we think about manufacturing and we're doing it at large scales and therefore starting to look about how we do manufacturing from a statistical perspective understanding things like variation that became really important and this is where this community started somewhere around 1945 it became really really important to rebuild a lot of the world and what Deming did is he went to Japan and he in many ways shared ideas that became the foundation of lean manufacturing so when we think about the Toyota Production system today William Deming was responsible for sharing a lot of those ideas and bringing them to Japan and obviously the Japanese did incredible work with that so it's not exclusively responsible by any means but he was an ambassador that shared a lot of these ideas now those ideas came back to a lot of the West in the form of total quality management which led to things like Six Sigma that you might be more familiar with and that's how most folks get familiar with these ideas it is out of total quality management that a traditional BPM view is created this idea that we want to understand how our organization operates we want to create an automated view of it we want to inspect and we want to adapt and we want to get better this is the short cycle you know plan do forget it on stage plant do check study acts right there we go if there's that's the short cycle and then yeah thank you so anyway the idea at a late and in the 80s and 90s was well we can't really do that in our big distributed world without having some software to help us do that so wouldn't it be great if we had some sort of software that tracked our processes and then we could do some iterative improvement with that it seems like a good goal now without getting too much further in into that there's a paper that Deming wrote that established the system of profound knowledge and the system of profound knowledge kind of focused in four areas it was articulated in 14 points so you might hear demyans 14 points but there was sort of four principles of it and what I've done is I've taken the four principles that Eric used in last year's keynote here as the principles of domain driven design reordered these and I've lined them up so the top one in the system of profound knowledge was the focus or of appreciation of a system the understanding of the big picture so that when we optimize in part of the system we don't do local optimization that actually hurts the whole this was really important we talked about this in ddd all the time we context maps we try to find we try to distill the most important part of the business focus in on the core domain but we don't want to lose sight of all the other parts of the business it seems to me to be a common value I wanted to do some systems thinking here now there was different objectives behind those principles in those statements these people are operating in different context Damian was more interested in sort of traditional management consulting and helping executives understand how to think about their organization we have a little bit different focus with building software products but from both sides we're placing a value on systems thinking and understanding the big picture once we've got that in place and this is really where I think Deming had a lot of that positive impact on the day-to-day life of the average worker Deming talked about the knowledge of psychology and in particular incentives what makes people work well that means one of the people who really established this idea of potential for self-organizing teams that management by numbers management by objective maybe not the best approach maybe we need to let those who are closer to the work figure out what they're doing and we love that idea in our community right we love self-organizing teams cross-functional teams brought together can figure out how to solve their business problems the best that idea was not always the case Taylorism was very much a a hierarchical structure where you had someone at the top figure out what work needs to be done and then distribute it to the workers to do so Deming really helped change that and I think our community shares an appreciation for that value of how humans think about incentives and how they do work the Third Point from the system of profound knowledge is the theory of knowledge and in particular the notion of operational context so if you'll recall in a in the early part of this I talked about statistical process control and that's sort of the origin of these guys well in statistics there's a lot of numbers and so I think anyone has probably seen a statistic put forward on a slide deck and say that's out of context doesn't make any sense you can't say this about that and in this body of work Deming talks about the importance of operational context when you were looking at processes who woulda thunk a community that cares about context and the fact that when I say a word or I give you a number it's got context it has to live around other things so for a community that really cares about bounded context there's a lot of similarity there the last ones are where we kind of diverge the system of profound knowledge is interested in variation particularly what that means from a manufacturing perspective we're more interested in building software models so this is our context showing the principles are different but I think there's a lot of similarity and the first three and and because of that I think the practices that come out of these principles are worth exploring maybe they always haven't given us the right results but I'm going back to those practices and those tools because I think the principles are sound so maybe if we change the practices about a bit we'll get a little bit closer so that's the hope so thanks for your listening there all right so enough of me pandering on let's take a look at some hopefully working software before I do that actually I need to turn your attention to the sticky notes so I'm gonna take a look over I'm gonna try not to cover it too much here because we're gonna try and make this work with the camera I've got one stage here as well as once are on the window over there and the window over there I've got an example of what would come out of an event storm and if you recall earlier I was discussing that we're working in a ride-hailing situation so I want to create a company called Cabot we're gonna compete with the lubbers and lifts of the world and I want to describe here the ride hailing process so I started off kind of in an event storm with my team and this might be the output of that event storm so we had a conversation about really where to focus first and so one of the things that that came up is well there's a whole process around driver signing up and riders signing up well those are important they're identified here in the purple that's kind of the notation to indicate a process they're not our focus so they're up on the screen but we're not going to focus on them here same thing with selecting a destination and the type of ride that I want it's important it starts this process off but it's not the focus so we really want to focus in on the actual process which is going to begin here when a passenger of requests a ride and so that's the notation we've got the the yellow sticky here that indicates a passenger the blue sticky is indicating the command so a decision that the the passenger is made they want to request the ride they've hit in the big request ride button and they're hoping that the system is going to request a ride on their behalf so we make a vent once the system's receive that rides been requested by this passenger at this time and the yellow sticky or the sorry the green sticky here is just indicating that we've got a screen to help us do that I haven't sketched out the screen but this is where one would go now once the rides been requested that rides got to be dispatched and this I think I'm supposed to say purple right purple for policy here is is an important part of the business matching rides with drivers that's hard there could be a lot of drivers they might not be going all in the same direction some might have different statuses maybe some got more rides than others so there's a lot of work here now we're not going to represent it more than that other than to say this is an important business policy we need to look at it more deeply once the ride has been dispatched we've got to send that dispatch to a driver and the driver is going to have an option to make a decision here so the driver can either accept or reject the dispatch and they're gonna have a screen to do that I've just duplicated that so these are sort of the two outcomes that the driver could make from from this screen here though gets though either accept or reject the dispatch now in the case where they reject the dispatch process is just going to come back and redo the dispatch policy because now I've rejected it so we need to find another driver so that our passenger can ultimately get a ride in the event that in the event that well let's go back so we'll do that our system will send the dispatch again we'll get a new driver and this time the driver is going to accept the dispatch and now I can begin the ride he's going to navigate hopefully to go pick me up now navigation is complex and I'm not gonna focus on it here but again I've indicated that it's here so it's inside this process but we're gonna skip over the details of that sub process for now in the last two steps hopefully there's no issue with navigation the driver heads towards my passenger they pick up the passenger and then ultimately they're go to where they need to go and then they'll drop off the passenger now once I've dropped off the passenger that's going to start the payment process again payment process is important it's not the focus of what we're gonna do here so you can imagine if you were working on a project to deliver this this might be the kind of artifact that you finish with and this is great now usually event storms a lot more messy than this so this one's nice and cleaned and pretty and demo ready but you might leave the room hopefully with the kind of shared understanding that I was hopefully able to impart about what we're able to do so the rest of this conversation we've got another 10 minutes here so the rest of this conversation is going to take a look at how we can turn this into a piece of software and I'm gonna hope the network is going to help me here and the demo gods are gonna be kind I've got some software running in the cloud right now and it's actually running in North Carolina so hopefully the hurricane doesn't get in the way here and what I've done is I've gone and I've drawn out the same process inside a process modeling tool I'm using jbpm here which is a community process modeling tool but nothing I'm going to show here today is specific like technology specific like any community that builds software like this is going to have basically all these concepts how to model a workflow how to execute it how to look at it at runtime so there's nothing unique about jbpm here so you can see I've got the same steps right we've got a start the rides been requested I dispatched the ride drivers gonna figure out what to do they might accept it they might reject it now in the event of a rejection I got to come back now you'll notice there's no policy here and that's one of the areas for further expert exploration I want to talk about at the end but we'll go back through we've got the dispatch sent the driver will decide to accept it I've got the navigation process here and I've just kind of made him him a pass through so I'm not gonna focus in he's represented but it's just gonna print out hello world and then the passenger is picked up and the passenger is dropped off so because I have disconnected here let's make sure he's back okay so let's take a look at how this guy's implemented so I've created a reusable sub process that's a very common approach in this world and all that sub process does I'm not going to pull it up here but all that process does is it takes a piece of data which I'm going to show you in a moment and then it sets basically the signal that is being waited for so that signal is going to be our mapping to a domain event once it's got that signal set the process will sit and wait on it so it'll wait until it receives the signal once it receives the signal it'll take all the data inside the event and it'll map it out into the process just as a just as a hashmap so it'll go through the key set take all the data put it on the process nothing more than that and you can see every every one of the steps here has the same sub process so they're all reusing the exact same sub process the only difference between them is this assignment here so it might be a bit challenging to see so I'm gonna make that bigger this assignment is just going to take a piece of data called a name and it's gonna set it as a variable in the sub process and what I've done here is I've just set the name of the event I'm waiting for so in this case the ride requested event is what I'm listening or listening for and that's going to tell the sub process hey sit on a signal and wait until the ride requested event comes that's all it's going to do and if I take a look at each one of these the dispatch one here you can see that it's got the same thing so it's got it's dispatch accepted here and they're all gonna do the exact same thing the only difference here is that because there's a fork in the road I've represented one of the commands one of the decisions as a fork in the road here and that's why the human task is there it gives us a chance to pass in the data that will decide to go left or right there's a small piece of configuration there and I'll talk about that later as a place for further investigation so what I've done is I have built this process model and alright and it is hopefully oh gosh well there's the demo gods let's make sure that we're up okay well it should show me that it's - here we go sorry I just network fee so well this piece is here and this is actually deployed out so it's running this version 1 0 to 8 these other guys are artifacts that are just sitting around because I've been testing this today so don't worry too much about them so again version 1 0 to 8 this is just the system telling me it's deployed out and it's ready to be run and then what I'm going to do here is just quickly show you the instances that are active so right now there's no nothing active in the system and if I actually do that you can see all the processes that have run before so let me quickly now turn to how I exercise this so writing this code the thing that was actually most interesting to me I'll comment this first if you recall back to the impacts that I was after one of the things I wanted developers to do is to model events and start logging them from the beginning to do that you got to create some classes that have your events in them and I actually a happy side-effect of doing this work was in my my app I had to go and model the event because I had to send them over the wire so the first thing that I did to write the code here was model my domain events and so you can see I've just got a J unit test class here and this J unit test class is going to create events and then I've got a client side you're here that's using the jbpm REST API in the future I'd like to actually push that the domain translation into a messaging system and push it into the server because there is a stateful mapping between each aggregate and it's specific process ID haven't finished that code yet so further exploration there so right now that mapping is being done service or client side and it's what this adapter is doing so if we look at each of these lines I created the main event I published the domain event and that's that so happy side-effect I had to go in and do things like just define of ride requested and what it looks like and what pieces are data there and that was surprisingly clarifying because it's one thing at a white board to say I've got a ride requested but what data is on it and what other aggregates doesn't need to map to and how might that work and so actually just starting by writing the classes out and thinking about what those classes were even before writing the aggregate classes was instructive I found that really interesting it kind of gave me clarity that hey I actually need a dispatch aggregate the dispatch is going to be separate than a ride because they're gonna kind of work at different times so once that's there what I'm going to do here is I'm just going to run part of the process so you can see what this looks like so this is going to run and what I should be able to do now is hit refresh and I've got two processes running so the one that's blank is that sub process and the one here that says ride is the right process and so what's nice about this I'll make a full screen is we can now see and I've scrolled down here it's kind of big I'm gonna zoom out a little bit so what we can now see is the same diagram that I showed you before running and we can see that a ride was requested like you saw in the j-unit ride was requested the dispatch was sent and then the driver decide to accept it now all of the grayed out boxes are the parts of the process that have been executed the one that's highlighted here in red is the currently running ones so this is waiting for a domain event to come in it's sitting here waiting on the process anything that's in white hasn't been run so it's an unexcused now one of the coolest parts about this is all of these process engines have a way for you to see the running variables so if imagine I'm at a call center right now and someone calls calls in they want to know what's going on with their credit application or what's going on at the booking it'd be nice to see where I am in the process and also what data is relevant to me and so these are just the values that were on my domain event and again there's no translation here other than just hash map so just push the map over so you can see the destination I was interested in was the location of the conference and this was my pickup location which is at Union Station here in Denver and you can see the ride ID and what you can also see is just a history of the events that have happened in the time sequence and when they happen so first a ride was requested then a dispatch was sent and then a dispatch was accepted quite useful if I've got to communicate that maybe to a customer over the phone or something like that so that's the first test case just to kind of show you that running now if you remember I said one of the areas for further enhancement was to push the state of the mapping onto the server well since I just ran the test case I've lost the state so I'm going to just run the same test all the way through and this time we're going to pick up the passenger and we're going to drop off the passenger and I'm just going to push this over and that test case is finished so we should only see two active processes because the process finished so what I'm going to do this time is just pull up the same process model it's a it's a new instance here and we can see now that I've run through the whole process this time because everything's gone through in the interest of time I won't show you the variables but what I will show you is the sad path so let's take this scenario here where I request a ride dispatch is sent it's rejected and then I want to send the dispatch another dispatch a new driver accepts the dispatch pick up the passenger and then I drop off the passenger so I'm gonna run that and we'll take a look and see what it looks like in the run time pop this over pop this over and I'll just update here and you can see more steps have happened this time and I'll take a look at the diagram and you can see now all of the steps are highlighted and this makes sense because I've gone through all of the steps at one point or time now that might be visually confusing I might want to know the order of those events and so if you recall again I can come back to the process variables and this time I can see again the history of the events so I can start at the the end or the beginning ride requested dispatch sent dispatch rejected dispatch sent was accepted and then passenger picked up passenger dropped off last thing I'll show you here and then I'll wrap up is business data actually changed throughout that right I got a new driver ID I might want to know which drivers IDs I had so what I've done because I've gotten the same event I've updated that variable over time so I can now see the first driver who dropped me off was who hid a ad and then the second one was 0 for 4 now of course this is a demo and there's simple examples here and the data itself is an interesting but hopefully the foundations that are at least presented here you can see how those things might be useful in your projects so that covers the working soft we're the last thing I want to do and I'll end here is it just want to just mention kind of a highlight of areas for further exploration so I think visualizing policies could be really interesting I'm not sure how to map that to BPMN so I'm curious what this community would have to say about that I'm not sure if it's valuable to clearly delineate bounded contexts and if so do you do that in work or swimlanes do you do that with colors I'm not sure curious for your feedback right now this business process is mapped to a single aggregate so oftentimes we talk about aggregates as a state machine this is essentially the state machine for a ride but what if we needed to span a process that was many aggregates is that a good idea events that coops events that could happen at anytime so I didn't model anything that comes out of band here like canceling a ride there's ways to do that in BPMN I just haven't represented them here and then some technical stuff so finishing the Kafka integration and then also looking at things like change data capture so that delivery teams don't actually have to see the event logging mechanism they just have to write their event logs to a data store and then we can use things like change data capture to actually stream out those events so it's more seamless for delivery teams so that's the the focus of the talk I thank you for your attention and I'm really interested to hear your feedback in the hallway you

Channel: Explore DDD

Views: 5,363

Rating: 4.875 out of 5

Keywords: ddd, domain-driven design, software design, technology

Id: MHLFW0VAaS0

Length: 45min 30sec (2730 seconds)

Published: Wed Oct 17 2018