Find Context Boundaries with Domain Storytelling - Stefan Hofer and Henning Schwenter - DDDEU 18

good afternoon I'm Stefan next to me is my good friend and colleague Henning we are both software developers consultants and trainers yeah that's right whole damn it off ah thank you thank you thank you that's a good afternoon for the international guests yeah okay so we both work at workplace solutions in Hamburg and our goal today is that we can bring across three main points the first is that we will introduce domain storytelling as an additional tool for a modeling tool box second the main stories show how people and software systems work together and if you see a business process as cooperative work that might change your view on context boundaries I think that we can all agree that it's crucial for the main driven design to tap into the knowledge of all domain experts and for some years now Henning and I have been using domain storytelling to do that and to talk with our domain experts that's the knowledge that we want to share with you today and what better way of sharing is there than by telling a story ok and I'm the one who is lucky to tell you this story and Stefan said it will come from Hamburg and so the story we will tell you it's a story about seafaring and how does seafaring today look like and seafaring is typically container shipping and this container and goes on a journey it is loaded onto this container ship can you hear me in the postman's yeah ok great on this container ship this is the samatha Jen McGarry on one of the biggest container ships we currently have and now my clicker is not working anymore okay I have to be near the laptop okay so the ship is going from Shanghai which we can see up there to Hamburg which we can see down there so for the Germans in the audience we do have an epsilon mone and we do have an airport okay so the ship goes without problem travels around half the world through the Indian Ocean through the Suez Canal and arise in the northern sea and there we have the problem Hamburg our city our pod is not situated at the sea it's not securely at the northern sea you have to say a upstream the river so Hamburg is situated near the river Ella 100 kilometers you have to go upstream and that can be a problem for these big ships because when you look at the port from above then you can see when you compare this river to the open sea it is not very deep it is shoal so and that's the problem because these big container ships they they are very deep 18 meters if they're fully loaded and the other thing is it's pretty crowded because the river is narrow compared to the open sea and there's a lot of traffic we have a lot of vessels traveling there so the question arises how can that work how can we bring these ship these ships into the power into the pot and this is only working because there's a special Authority and the Humber Port Authority which is working on this so before the maneuvers are actually brought out they are assimilated so we assure the ships that come into the pod won't run underground and this is done here in the not so called Nordic Center the Nordic Center is one of the department's of the Port Authority and the neurotic Center you can imagine a bit like the tower at the airport so the tower manages when can airplanes land and when can they start and where do they go all on the apron and the same thing is true for the Nordic Center so the Nordic Center talks on the radio to the ships and managers one can which ship come into the port and when does it have to go out ok and I told you they are simulating the maneuvers and how are they doing this yeah they have these big paper maps we can see here it's called a so-called depth map and as you can see that's a big piece of paper and there's something colorful on it and when we zoom in we can see the colorful things that are these small numbers so called depth numbers they show the depth and at that particular spot and so for example this is a depth number 11 meters point 6 and then there are also these lines those are contour lines or depth lines so they are for every full meter we have one of these lines and where do these numbers come from they don't fall from the sky obviously so we have a special infrastructure in the port to collect this data I could collect these depths no special ships like this one the datum Schriever the depth writer and those are special ships they are called sounding ships and these ships sail through the harbour and measure the depth with echo sounding and they do that every day and then after that they send the depth data into the spike Ashdod and there's another Department of the Port Authority the so called sounding department and they are working on this data refining it calculating the the contour lines and then they draw this depth map and then they send this depth map onto the other side of the river well the Nordic Center is located and in the Nordic Center the nautical officers or the navigating officers take these big paper depth maps and pull it onto their table and then they simulate the maneuvers with these small pieces of paper or cardboard and this seems funny but they are actually doing this or they were actually doing this and what's very important what we can see there is this scale on this silhouette and of course it's important that this is the same scale as the map underneath it okay so they now take this silhouette and move it over the paper and that works pretty good because you can see when you touch a value and when you touch a depth that is not deep enough so you can find your route through through the pod that's what we want to find okay and of course we are technical people the question that we should ask is is there a net for it yeah of course we do that and I was lucky to be a part of the team that developed the solution for this case with a small team of colleagues from the work relationship solutions the company we are working for and we built this the pilot ish as we say it in German it's something like sounding Taylor and as you can see there's a big touchscreen that's lying on a table so it's a touch table and when you look at lead ability at it more closely you can see that we have the steps map with the numbers and we have we also have this silhouette here for this hand where the 97 is that's also a silhouette and like the silhouette on the paper version you can touch it with two fingers and navigated through the harbor and can find your route with it okay so the reason why Henning was able to tell you that story is that a few years ago domain experts told us the same story but back then we didn't use pictures and slides and PowerPoint to record it we used two main storytelling and this is how we did it so imagine you are in the Nordic Center okay I'm a software developer from workplace solutions and I invited a couple of domain experts to learn about how these maneuvers for this large container ships executed so please welcome with me here today Henning the navigating officer or a little navigating officers used to be captains at sea that's why he's allowed to wear his hat and also here with us is Henning the cartographer with his map hair thank you and behind us is a large white port and while Henning and Henning tell me their story I will use these magnetic cards inviting them to visualize the story that you tell me okay so hanging and hitting how does maneuver planning for this large container ships work okay I will start as heading the navigating officer I do the maneuver planning the the maneuver simulation and I do this because a big ship has arrived in the mouth of the river Elbe and one of these ships when when the ships arrive and in the mouth of the river they call me and ask me for a route they can take to come into the port okay who exactly calls you well it's typically the captain of the ship okay so we have a captain here yeah yeah yeah so he calls you on the radio yeah that's right we called me on the radio okay so he calls you on the radio and asks for a route okay yeah and then when I was asked for this route then I'm going to simulate the maneuver and to find this route and this I do by taking out my depth map and putting a ship silhouette on it okay but what's a ship silhouette and what's the depth map and where does this stuff come from okay ship silhouette is a small piece of cardboard and that I cut out and the depth map there's a large piece of paper with a lot of depth values on it okay so where do you get a depth map from the depth map comes from my colleague handing the cartographer okay so you you're the one who creates this depth map yeah that's right I'm heading the cartographer and my job is to draw depth nets that's right but I cannot do this alone this is only working because there are ships sailing through the harbor and the the sounding ships and they measure the depth in the port okay so we have first make some space in white board so there's room for your story so you set this a sounding ship right yeah that's right so and they measure depth that's correct okay so they measure two steps and what's happening next after they measure the depth they send it to me and they sent me to be honest a lot of data a lot of depth values and they some kind of raw and I have to refine it afterwards so for example they sound every square meter in the port and I get one value for every square meter okay so you get a lot of raw depth data that's right okay so what do you do with that data yeah I refine this data so for example I calculate local minimums so I don't want to have every square meter one value I need less values so I look in areas and see what's what's the shallowest point in this area and this is the local minimum because if it's deeper snow problem then the ship won't run onto the ground but if it's shallow then I am okay and I also calculate the the control lines okay so you calculate the contours control lines and the minimum that's correct then you're done then I'm done calculating and then I'm doing my real work then I draw the depth map okay so you saw a purpose I use this contours this minimum depth onto the depth map okay and after that I sent this newly created map its newly drawn map to my colleague the navigating officer okay how do you send it to your colleague by mayor okay so you actually print it out and send it by Mia yeah okay that's right good and then the navigating officer is ready to receive a captain's request for route yeah that I have to give to my colleague the navigating officer and yeah that's right okay I now have this depth map and the ship silhouette and what we probably should tell you is that all of these creation of the off depth map happens on a daily basis so every day I get a new depth map from the okay so make a little note up there okay okay so then you have the depth map and you have to request for a route and then you put the ship's alert oh no that's not yeah right okay then I put the little ship flew it on the depth map and but first you told me you had to create this ship's silhouette that's right I cut it out of cardboard so it has the same shape as the ship out in the river but typically I don't have to create it newly because probably the ship has already been near to a Hamburg or there are other ships of the same class of the same ship class have been there okay so it's safe to assume here that a fitting silhouette is available yeah okay okay that's right so what's happening next so now I take the ship silhouette and move it on the depth map and I move wood and I turn it around because I want to find a route okay so move and turn this ship so where to find the roots here yeah that's right and then I call the captain on the radio and discuss this route with you okay so actually talking through in my mirror yes that's right I talked them through so you can then do the exact right maneuver safely into the harbor okay and that's maneuver planning did we miss something that is maneuver planning okay on a big picture good thank you so this of course is a little bit of a simplification but it does it's sufficient for us to explain what the main storytelling is about so what you've seen is that the main storytelling is not just story as text we use picture pictograms symbols to tell our story so we have a set of different symbols that are basic vocabulary so we have actors we have work objects and arrows our our activities and then we use textual annotations and to add concrete meaning to the symbols we add text to them to express what they represent when we look at the symbols a little bit closer or the different types of symbols we will see that there are actually different kinds of actors so typical variations are we have a person or group or Aniki system in our example the ship was an actor so it's very typical to customize the set of symbols you use so it fits through your domain and also there are different symbols available or we use different symbols for the work objects so in our example a root is maybe something that is represented via wire a call by radio or it could be something that is written down on a piece of paper still it's the same root it's the same thing it's the same counts that concept but depending on where we are in our story it's represented in a different way and that's what we want to express with the symbols so they are not just there because they look nice they are there because to convey some meaning so we can actually see information change its shape its representation its medium what you Dan is with these few basic symbols reformed sentences and the goal is to form sentences that read almost like natural language and to tell a story we need of course several sentences so what we do now is we append sentences and to show in which order the sentences should be read we add numbers to our sentences and what's typical for the main storytelling is that we don't use any symbols for ifs or gateways or decisions story is always one specific case one concrete example and to sum up this idea so our motto is kind of we would rather have three good examples then premature or a vague abstraction okay so what we saw now was big picture two main story telling there's a lot more to talk about the main storytelling you can use it for different parts of domain-driven design they're different ways that we use is to use it to talk about requirements or even to do technical design and if you want to learn more about that and practice two main storytelling with us you can come to our hands-on session tomorrow at 11:00 or of course if you see us at the conference just grab us and we will do a model English strangers session together with you okay and Stefan said we have done a big picture the main story and when we look at the big picture we look typically at the whole domain or large parts of the domain and what we are doing with the domain is we model it and of course as as we're told by a strategic design we don't want the whole domain especially such a big domain as this we don't want this to be modeled into one large and cluttered model but instead we want to have several smaller and better understandable models and when we built several models we introduced boundaries so so we have boundaries between these models and yeah then we have unbounded context because the models exists in context we all know that but we don't want to have boundaries that are like this we don't want to build a Berlin wall we want to build boundaries that separate models but do not separate people so we want that people are still able to work together we want different models so we can build a software that's easy to understand and that is less error-prone but it should also be a software system that can be can be easily used by different kinds of users so let's look at this story we have we have told and let's see if we can find some indicators where bounded contexts might be when we look at the layout of this domain story we can see there are at least two kinds of of work items work items that belong to one actor alone one actor is alone working on such an item and other items are used to work together so this depth map for example is given from the cartographer to the navigating officer and often this can be an indicator for for candidates that are bounded context let's look at these candidates we have a cartography candidate down here on the Left well we have the cartographer and the creation of the depth map the the calculating of the contours and the contour lines and the minimum values and up there we have the candidate maneuver planning there we also have a depth map but we have a different model of the depth map because here we don't calculate contour lines here we we use a shape silhouette on it we want to do a maneuver simulation so what we suggest is there's a boundary here through this depth map so the depth map is given over this boundary okay so our first indicator is a one-way information flow you saw that there's this one information one piece of paper one document the depth map that is each exchange in one direction but there's no no information flow back to the cartographer so such a one-way information flow that is something that is a typical indicator for context boundaries but there are more indicators in the story yes there are when we look at the story again we can see that the word ship appears a few times and when we remember the domain we can see there are different kinds of ships in different context we use different ships so we have this sounding ship down here and we have the container ship and we have the ship silhouette all of them are ships or models for ship my model for ship and all of them are called ship in their context but different things are meant with this so what is nice about the main storytelling is that it shows us graphically when we are making mistakes so if we would make the mistake and say okay all these ships are the same we always hear the word ship then we would probably have something like this so we would have one ship and a lot of arrows pointing to it and all domain expert would say no that's wrong that's different kinds of ships so that's good that we can use these T for that okay so here we have our second indicator often we see differences in languages they are made visible with two main stories and that's another good indicator for having two distinct separate bounded contexts can give us another indicator yeah one more indicator I've brought you and for that we have to look into the upper left corner there's this annotation that tells us that the steps 1 to 5 are done on a daily basis so this part down here the sounding and the creation of the depth map that is done every day so that's triggered by time and the manoeuvre simulation up there that is not triggered by time that's triggered sorry that is triggered on demand every time a captain asked the navigating officer for a new route so this is again one bounded context and these are these steps 1 to 5 where we have this timely aspect okay and now we have three different indicators so we have the 1 way information flow to differences in language and even different triggers triggers for parts of the story now with three indicators we are fairly confident that we indeed found a valid boundary between two distinct bounded contexts but as you probably know indicators are no definitive proof that is actually a context boundary there so what I want to do now is to give you a counter example I will show you another indicator which did not lead to a separate bounded context or we decided ok notice even though there's an indicator there we want to leave it inside the same context ok so if you look at the cartographer and the sounding ship we see a pattern that heading described before it's this one one-way information flow so we have this depth data the raw data that is sent from the sounding ship to the cartographer so one could assume maybe you know kataka fee and sounding those are two separate things now this one domain story doesn't tell us enough to make the decision if there's actually a context pounder here or not but if we were to look deeper into this part of the domain would actually found out that the cartographer and the sounding ship to work together quite closely they're not just there for measuring depth data they actually managing the depth of the river because it needs to be adapted from time to time so if we were to introduce two different bounded contexts here that would really shepardize the how the cartographer and the sounding ship could work together so that's not what we want to do so we decided that this should stay in the same bounded context even though we found this indicator okay so it's already time to wrap it up we hope that we could encourage you to try domain storytelling for yourself use it to learn about you to main use it to think about context boundaries sorry sorry okay experiment with it and experiment with it yeah and most important tell us about it so tell us your stories and that's it for today and as we said earlier we're happy to help you with your modeling programs the modeling for interest session or come to our hands-on session tomorrow we can fit 40 people into our workshop and now we are taking questions thank you [Applause] at least if there are questions yeah hello the question is how many times did you revisit the domain expert did you just visit them one time and then everything was discovered no no so this is just absolutely no this is just a start of a process so typically we would do like I don't know three to five two main stories with this group of experts like an a big picture level so we have a good idea what the most important cases are so maybe does container ship and a cruise ship maybe they are something is different maybe they are the same then we can do them in the same story that's fine so we have to take care of all the important cases and then the different ways where to go from there for example we can do the main storytelling on a more detailed level within one bounded context maybe with not just one cartographer but with several cartographers so we have different expertise different different laws and differences in how people handle for example the depth data so there's a lot more things that come afterwards and of course when we develop software we want to develop software with an agile approach so these are not like specifications or something is just a way to get started in a completely new domain or to rediscover things in a domain that you found is familiar but the funny thing is that if you bring together people that have been working side-by-side for years they can still discover new things they didn't need know about each other about their about their work and it's also typically it's also tippet kill I go back to the story and that you find persons when your your story is told to you and that are not in the meeting now and you want to know about so for example the captain here maybe somebody you want to talk to as well and to tell that let him tell you your story or the people on a sounding ship other people in this ownership can you pass the mic up there whoa yeah great thank you have you ever mixed dimension storytelling with other approach like even storming or something else and what worked and what didn't work okay okay I just turn off my clicker or now yes I have or we have and the approaches event storming and domain storytelling they developed independently from each other and there are a lot of cases where you can use both of them or one of them and there are educators where one or the other is better suited for example and the main storytelling is especially well suited when you have cooperative work that means where people work together so you can visualize that very good and you can use these T for different things that don't have to do anything with the manual design for example finding shadow IT is also in use case for it and mixing approaches what my experience is and that it's good to have more than one tool you can use and when you use one tool for example you start with event storming and then you recognize for whatever reason it doesn't work out it's the domain experts they don't do not come to the point then let's try just another tool and then event storming then to my storytelling it is another tool and the other way around so often is it it's a good thing to just do something new because then you change the viewpoint and you have another possibility to the kitchen and what's important is and all of these approaches are only tools nothing more they're not the real goal the goal lies behind it we want to help our users through their job better or more easy or more efficient the cool thing is that ever since we start to talk about the main storytelling in people start to adopt it and use it to come up with different different ideas what you do with it and how to combine it for example event storming so this is really a great learning experience for us to get the feedback and people say hey I did first an event storming and then I saw it as this one sequence of events but a lot of people have to work together and then I did a domain story for that so that's pretty cool for us as someone who spread Eddie and then Sally does feedback coming back from a community okay can you go back please to the example with the yeah so here in this case if the cartographer needed information from the navigation officer hmm what would you do in this case because this would violate the first indicator which is one-way information flow would the navigation officer sit with one foot in one bounded context and one foot in the other one or how how do you handle these cases I wouldn't say there's any violation there so if that's how they work then our model was wrong and we didn't have that piece of information so we have to adapt our model and our perception of how they actually work together so yeah maybe it would lead to the discovery that know a context boundary doesn't make sense here we have to get rid of it and everything is in one bounded context maybe we always cover something else so I don't think that in this case there was actually like information flow back so no I mean if I don't know maybe they need to ask the navigation officer if the weather is good or whatever it would mean arrow going to the officer and back so this mean I don't have the first indicator and then what do you do you put the navigation officer in the disbanded context not necessarily no so the other indicators may still be valid so so maybe it's still a good idea to have this separate bounded context there doesn't mean that you have to have all three indicators there of course more indicators - you're just like three common ones that we see over and over again it doesn't mean that you have to have exactly these three and if there's freed and it's separate upon the context and if it's only two there it's not so I guess the answer is it depends I love this answer yeah so we are sorry but we're consultants okay oh I'm sorry testing alright so when you do an event storming session you tell the participants a few of the rules what would you say the rules are for domain storytelling yeah it's a good one well there are rules and if you do it in a strict sense they are kind of embodied in the moderator so if we do it the first time if a group of people well the moderator kind of holds all the threats together if it's an experienced group then well we just kind of facilitators but not motivate us then they can do it on their own so one rule is that if the session is over we all have to agree on a story so if there any differences in perceptions we take notes week annotations try to us often later maybe say okay there's an important distinction between if it's a container ship and a cruise ship then we write it down and say okay let's talk about this later but you know we want to get to the end of the story it doesn't make sense - that's actually reason but there are no no cases no ifs in my experience I use vocationally you have to use something like PPN or you mail and activity diagrams and people get so stuck in this well this could happen this could happen this could happen this could happen and then you talk for an hour about I will think that could happen but you haven't really told one actual case of okay this happens so the most important rule is tell a coherent story from beginning to end so that everyone in the room says okay I can live with that maybe there's some details not there that's fine we cannot make a perfect model of everything but okay that there shouldn't be anyone that says okay no this doesn't work for me I'm also navigating officer and debts I don't find myself in there that's that's not how work so that's about the most important rule I think yeah and another rule is of course it's not about the story we can see it's about what that the story is the same and in the heads of the people that are in the workshop I think here was the next question do you is there any specific approach for countering the cases like strategy how you deal with them well there are two things that come to my mind the first one is that usually when our model I reserved some space for cases variations assumptions all that kind of stuff and when we are done we go through the list and say okay how is that a small variation then maybe an annotation is fine like okay we will do it with a container ship but it's the same for cruise ships just step I don't know there's a little difference in step 9 maybe okay I don't and if it's a big difference then we will do another 2 main story for that and that's one way and one thing that we didn't show you is of course before you start with something like that you have to have this idea that okay there is something like maneuver planning so there is this task so what we do usually first is we collect different use cases that's the first step and then we let the people decide okay which are the ones that are most relevant to us for the problem problem that we have to solve so that's another way of dealing with cases so it was on up yeah yes hi so this is a big picture model that you made so if you afterwards zoom in do you then still use this technique or do you make it more abstract not really more abstract you can use this technique domain storytelling also for small picture things and to go more deeply into it so these work items we have here see here or of course all candidates for becoming aggregates and all these actions we have our candidates to turn into methods if your object oriented or into commands and if you think about that so you can go there very deeply into into the details and then really see the main model that's emerging from from the main story huh so if we dive deeper into the context and maybe do another domain survey with let's say a couple of cartographers then we will reach a level where we can actually kind of see the entities aggregates commands and stuff in the model and then it's really easy for us to have like okay an idea I've have a good idea how I would implement that so that's the level of detail we go to sometimes example when we look at the at the ship silhouette and in the step eight we can see okay ship silhouette is the candidate for turning into an aggregate which may then have methods move and turn so there we are pretty much detailed so so I think there was one here what happens if the river ever Elbe is not deep enough for the ship what we didn't tell you is it's more complicated than in Scenario we show to you there's at least one more context we need here and I told you that hammer is not really a seaport it's a it's a river port but to be to be honest it is a seaport lying on a river so we have this shallow and narrow port but and we have high tide and low tide so although it's a river the river is not flowing downstream all the day but when we high tide and the Nalan sea comes back into the pot so then we have more water under the keel so that for the ships with a great depth and we also looked at they come into the port when we have flood so that's another part of this maneuver simulation that we have a prediction of the of the tidal flow for the next 24 hours and the short answer is it costs a lot of money make it possible for tearing down bridges or making the the riverbed deeper enough like that yeah okay maybe one last question would you apply domain-driven storytelling for cases where you don't know where the bottleneck is because yes sometimes in most cases where I worked for it's not very clear what a bottleneck is and it's a whole process to explore it's the domain experts what's the real bottleneck is so I don't know for storytelling if that's a bit that sounds to me like this is a good case to try a big picture to main storytelling to get a big picture what's happening in my domain and then maybe from there dig deeper and see where are my bottlenecks because they're where the politic is you would probably want to dig deeper having no more details story telling something that humans do very well it comes to us naturally and what I experience over and over again is that no after couple of minutes people start to open up and tell you two things that they always found bad that never worked stuff like that that's again when the motivator comes into play so that would be another rule like you know you have to keep balance of the of the whole process so no one takes up all the time or makes it like a personal therapy session but these pain points they usually can be made visible rather quickly yeah thank you very much [Music] you [Music]

Channel: Domain-Driven Design Europe

Views: 9,763

Rating: 4.8873239 out of 5

Keywords: ddd, dddeu, dddeurope, domain-driven design, software, software architecture

Id: Y1ykXnl6r7s

Length: 45min 56sec (2756 seconds)

Published: Thu Sep 27 2018