The Art of Discovering Bounded Contexts by Nick Tune

where again you make it do it makes it who wants to go on an adventure today to learn the ancient art of discovering bounded context which we all seem to have forgot no one well you can all go and I can go home and that was a good talk thank you very much a machine we just don't like playing your hands up so I'm going to take you on this adventure but are we going to find the bounded context treasurer or are we going to run into danger so it's a very it's not a safe journey I'm going to take you on so I had to do lots of research about these bounded context things and work out we've been using them in DVD for like 10 years and now suddenly all you lot of searching for them so why why did you start searching for them over the past few years why did you suddenly start caring about them we've loved them for years and now you like come along and I'm going to take these bounded context things why anyone why did you start liking boundary contexts anyone it's okay I know the answer you don't need to tell me I did some research I was checking out the news from April 2013 with Justin Bieber Justin Bieber's new haircut sent people bounded context crazy it's the only answer I can possibly find to explain this place or maybe it wasn't maybe we need to have a chat with uncle Adrian uncle Adrian Cockcroft telling us we must be creating these fine fine grained micro services that implement bounded context maybe it was experts like him and Sam Newman good old Sam Newman aligning bounded context and micro services so bounded context has become very popular we're all searching for them but as it's a problem you don't know what they are you don't you can't agree amongst yourself what these bounded context things are if you've seen this conversation before bounded context exist in the real world know that sub domains know yes you're an idiot I'm taking my toys back well how about this one there should be a one-to-one mapping between micro-services and bounded contexts why is everyone so obsessed with this one-to-one mapping between micro-services and bounded context no one can agree on anything how about this one bounded context don't only you I yes they do whatever so I wonder have these bounded context things just become a bit of a buzzword and people like to use them to make themselves feel clever oh yes we're using bounded context and that bvv stuff we're doing it all right I think they have become a bit of a buzzword but there is some useful stuff in there but before we get to the useful stuff I need to warn you you can't just go around calling anything about in context is he going to have problems last year I was at a user group in London giving a talk about digital transformation one of the things I was talking about was yeah gently small things nice and independent bounded context blah blah blah it's quite good talk actually got the end of the talk everyone was asking me loads of questions the pizza had gone cold I was quite happy with my night's work people normally don't put their hands up like today they don't ask me questions or anything like today but this was a good talk and after the talk this guy comes up to me he say hey Nick I'm a deaf manager for company bla bla we were having that kind of problem he talked about the bounded contacts he said six months ago it was so long taking so long to implement even the most basic feature in our code base so my developers they asked for six months to take that big monolith and break it down into these small bounded context things I said to him okay that's a lot of companies going through that nowadays do you break it all down in one big rewrite or smaller pieces that's the kind of tough question and he was like no no no you don't understand I let them do it and now the work is taking three times longer the developers are always fighting and the execs are going nuts at me I've got three months to save my job what should I do enjoy the free pizza didn't have an answer for hit I didn't have an answer for him so you can get in trouble if you go around using bounded context and micro-services and you don't really understand what they are I'm not saying you'll lose your job like he probably did only if he's here that'll be quite embarrassing wouldn't it now he's not here I don't think so yeah there's a lot of lot of you can go wrong with these things so I want to show you how to find bounded context and it doesn't start with code or anything like that it starts by understanding the business problem so before we can whoops yeah imagine I just read that out to you it starts by understanding the business problem so a couple of things I teach on my workshop are the business model canvas understand your organization's business model the value propositions customer segments the key activities and the key resources and those things will tell you what's important and then when you're looking for bounded contact you have an anchor point we're creating bounded context to satisfy this goal but it's not just enough to understand the fuzzy business stuff you also need to understand which the core use case is in your system that your users care about who here is doing user research in their organization shame on the rest of you if you don't understand what your users are saying you cannot possibly create software that is satisfying their needs you can't possibly prioritize your time and energy creating bounded context to satisfy their needs because you don't even know what they're asking for but I won't hold it against you and I won't hold it against you like didn't put your hands up earlier we're going to move on to the next part so we've started understanding business we've started understanding our users and we begin by looking at those core use cases we find where value is and we start there so you can create user stories you can start the whiteboard by talking about things like about finding the core use case so I'm going to talk to you about this domain I worked in when I worked in the government I had to rename a few of the words so I don't get sued but it's basically as a business you can log into this system and you can move you information held about your properties and how that's used to work out how much tax you pay if you're not happy you can amend details and you can resubmit details and if you can renegotiate how much tax you pay so in this system we've identified the core use case customers care about renegotiating their tax because everyone wants to pay less tax let me tell you so we think of the system as a black box we think about it from the perspective of our users and that's when the interesting stuff happens but then we can start doing DBB you don't know this stuff and you're doing vvv yeah you're doing it wrong sorry so we start thinking about the system from the inside now and how the domain actually works but again we start with our user what are they trying to achieve in this core use case in this case I'm an overpaying rate payer the first thing I want to do is review the information held about my businesses so I can check if it's correct or not and this is where we get to the interesting part of modeling now you want to work out okay well which bounded context is responsible for enabling this this action to happen where does this responsibility live so you'll be at the whiteboard with your domain expert so waving your arms and playing post-it notes everywhere are you putting all that stuff we kind of work out which context does this belong to you and in this domain the obvious the obvious solution we enter is okay well we'll name it after the business process step so we're like okay this is handled by the assessment review context but you can't say context to like at the main expert it means nothing to them you're kind of talking about these things and they yeah it's difficult so what you can do is just start with a bubble or just put the name of the step so here we're calling it the assessment review step not calling it a context calling it step then you say okay well we've got this assessment review step how do the assessments get in there and then the main experts start going off into all their lovely speaking they're like yeah yeah we we contact the survey we send them out to the property they assess the property the supplies all the information fantastic what happens next well I'm a rate payer I see the informations incorrect my resubmit it I don't have two hundred car parking spaces I don't you have any car parking spaces great so which context owns this and again you can't say to the domain expert or which contacts don't exist because there is no context so okay what shall we call this step let's call it the attribute V submit and the domain experts like none and I we don't we don't call it attribute resubmit us too many words we just call it V submits so in this domain the word V submit means to resubmit some property attributes that you think are incorrect and then we're like fantastic what happens next let's have a coffee come back to it you have a coffee you come back what happens next a case is created hmm tell me more about this case well it's sent to the case management team I'm like okay well we'll create this context and we'll call it case management for now at this point it's just a hypothesis you're not committing to any context yet and then you're like okay well what happens next well the caseworker comes along they've got 14 days to process it how do they process the case they send them surveyor back to the property to check the details bla bla bla so I'm going to stop here because that's not the full use case but I think you get the idea right you're trying to guess at these bounded contexts and you might name them after you might name enough to step to the assessment review step or you might name them after a team the case management team then you go through more of these use cases you create different use case diagrams or you sketch different news cases on the wall and you look at all these different use cases and you try and work out the context you'll need and I'll talk about that in a sec but then you'll come back to a context map you're going to take all those different use cases you're going to abstract them away into a context map which is still just a guess at this point you're not committing to any context and during that process you can use clues to find bounded contexts so the first one is language if you've read the big blue book by Eric he's absolutely obsessed by language and precision and using words and it's a very good thing to help us find these contexts so what this means is in your domain you look for words and phrases that are used together or you look for the same word which has different meanings in different places so in this example when we're in the V submit context we're talking about property attributes floor space air conditioning car parks physical attributes but when we're in the renegotiate context now we're talking about I want to pay less tax and this tax band and that tax pan and this rating and stuff the language is completely different so those boundaries look quite clean and separated but then we get to the case management and it's a bit awkward because we're reusing language from the other contexts when you create a resubmit case it contains language about these submits when you create a renegotiate case it contains language about renegotiates so that context doesn't it's not obvious me yeah you're not quite sure so you think okay let's look at the other clues another queries data I've got data in this context and I want to make a change to it but have to change some date in another context that dependencies are warning that got a dependency coupling might not be good might not be good boundaries maybe we can turn those things into one context another is the main expert boundaries what does this mean it means that in a large complicated problem domain you might have different domain experts and they will care about different things and what they care about can give you clues about good clean boundaries so for example in this domain when I'm in resubmits the main expert here is a surveyor goes down to properties collects all the attributes drink lots of coffee and stretches the day out but one you get to renegotiate with the main expert now someone who deals with tax bans and finance and politics different domain expert so it's telling us those boundaries that the resubmitting renegotiate they look quite clean and they satisfy these clues but then one gets a case management and it's like well yeah those both of those domain experts have to have an impact in case management they both have to provide input so maybe case management isn't a good boundary we talked about existing organizational boundaries can be useful can be a bit of a red herring and we've also got business process steps in some of the names to find your contact you just take your business process step chop it up into it and take your business process you chop it up into steps and each step is a context it really is that easy sometimes so we've got here review resubmit renegotiate and case management only the problem with this is you think it's a business process step when you start modeling it and when you start implementing it in software it's a bit more than just a business process step you crack it open and you see multiple different responsibilities and that's where this organization kind of went wrong they create Aviv context in a high-level strategy document by some senior executives who get nowhere near the code but when they went to implement it they found that yeah a case management is two things it's processing the V submit case and it's processing the renegotiate case so it's not really satisfying any of these clues so what we get to now is the tricky part and this is why it's an art and not a science because these clues are telling us case management is it's not a clean boundary do we need it or don't we need it and this is what DVD helps us to do DVD helps us to create these different models encourages us to look for different models of the same domain but then we have to choose which is the right model for us to choose and this is where a lot of people go wrong with vvv they can't justify why they're using it why are you collecting value context while you're creating creating models I read it in a book soin told me a conference I need to create bound good context that's not not really going to make much difference to your manager or someone who's not into code I'm sure I clicked that so how do we justify these founded contexts and how do we know which model to choose it's probably not something your customers care about so they're not going to say oh yeah we're going to take this organization kiss those developers either they got I've read their blog and I got these amazing valued contacts feel free to prove me wrong on that you can call me out any time but what we need to think about is at a higher level so let's think about the organizational factor so we've got this context map now let's think about the teams that are in the context so here you've got one team that owns each context that's a good thing because they own specific parts of the domain they have knowledge and expertise and ownership but this organization has a few problems we've got a lot of friction here so the case management team they're going crazy the V submit team on the renegotiate team keep five changed out them when one of those teams adds a new form to their field it has to be updated on the case management system that the case management team they have their own properties they can't keep up and so the V submit team renegotiate they're now being blocked by the case management team we have an organizational problem here and this is where we look at our different models the model with the case management and the model without it and we use organizational factors like this to justify which is the best model so in this case we can fix that problem by choosing contacts that look like this and actually these context suits are clues much better so think about language here when I'm talking about V submits and not sharing that language with case management it's all nicely encapsulated in resubmits same for renegotiate how about when I want to add a text box on to a web page while I can update the front-end and the same team owns the full slice so they can update the backend no dependency on other teams now the approach we're using here is composite applications and what this means is are you so we don't want to compromise the user experience that we still have to focus on this but what a complication means is I'm a user I'm looking at one web page I click on a link I go to another page the first web page you served up by one context but the second web page you served up by another a lot of people think we have all of these domains of and design api's but monolithic web front-ends it's really not true you're bounded contexts can contain the UI and in most cases they probably should where was I ah so that leads me to why do we why do we not have one big piece of software why do we not have one team all working in the same code base which is it just doesn't scale you'd have everyone flipping over each other blocking each other getting in each other's way no work would get done and that's why to why we create boundaries in the first place we create these boundaries so people can have isolation and the ability to get always lighting stuff without being dependent so when we start talking about bounded context and micro-services and people start throwing all of these different rules and patterns at us there's only one thing we have to really care about and that's delivering software faster so when you're finding boundaries that's the only thing I think you should care about everything else he's just trying to help you achieve this and so what we get to now is we start tripping into the world of Theory of Constraints has anyone heard of this so Theory of Constraints is said principles that kind of manufacturing in the 1980s and it basically says in any organization the limiting factor on delivering faster there will be bottlenecks if your organization has a bottleneck the way to be more productive is to fix the bottleneck if you stick something else but the bottleneck still there you're not going to improve anything and so that's what we're doing with DVD we're using might with using bounded contexts to fix the bottlenecks and that's what we did here we saw problems in the organization they were bottlenecks and we use bounded context to remove those bottlenecks and so this is this is my workflow this is how I do some SLA microservices bounded context whatever we call it I use DVD I use those clues about language and data and domain experts I use those clues to get all these different ideas for models by use Theory of Constraints to look the bottlenecks to choose the best model and that's how I advise you to think about things don't just think about TDD and bounded context as these low-level coding patterns it goes much higher all the way through your organization bounded context should allow you to deliver software more frequently and this is where people start getting clever and they say to me yeah this is great we have all of these nicely independent bounded contacts and all these teams that are nice and all time and less blah blah blah but that won't work kiss what you get you're bound to respond how you're going to fix it and if you have all these teams who aren't talking to each other I never said I never said any of that stuff your balance we do have to change your boundaries will always change you'll be working on some code and you'll work out hmm yeah this this doesn't fit into our model online doesn't really fit these concepts don't seem to work together it's not it's not clean fit and you'll realize that another team you need to combine your model back with their model and then break it up in a separate way once you've added the new concepts or you'll find out that you'll see bottlenecks forming in your organization you might think you've got these beautiful clean bounded context you spent hours crafting them and going through all these different use cases you're convinced that these are the best bounded contexts in the world and you can't do any better but if there's a bottleneck in your organization maybe the answer is to reshape your bounded context to eliminate the bottleneck so you can't just look at the code and most clues you have to align it with bottlenecks and I was at a talk the other day by Matt Skelton he saying this kind of thing so as teams going through different stages sometimes you want teams who do have autonomy but sometimes you need teams working closely together when you're exploring new parts of the domain and so this has an impact on your bounded contexts so let me give you an example so one one of these examples is your bounded context can grow and multiplies I was going to say like a baby but babies don't multiply do they would that be a weird analogy can I say that can you edit that bit out please so anyway this is it the main I once worked in is about music streaming and downloading works in this organization yet got a web store you can buy news you can download the etc now let us start when the company was quite small we have this discovery context we had a couple of responsibilities it allows you to search for music so you can find artists and tracks and albums that you want to buy and download but then when you found the one you like you can look it up so this context enable you to search and look things up as the business started to grow search became a bit more important search became more important that part of the system started to grow so it split out into a search context and a catalog context and then later the business changed its priorities like oh no a competitor's all have amazing recommendations if we don't implement recommendations and beat the other companies will be nowhere so we had to spit out a new context useful recommendations so the business could iterate on recommendations very quickly without being slowed down by teams working on other pieces like search and catalogue that weren't so important so again if something's cool to the business it's fit if there's a specific piece where you need to iterate quickly that's another reason you can have bounded contexts and team sizes then you get to this stage where you've got different bounded contexts different teams own them and it can get a bit complicated so I work at Salesforce please don't hate me I work at Salesforce we've got like twenty five thousand employees not hundreds maybe thousands of developers quite a few salespeople as well but they're all nice so we have this big system we can't it's not it's not possible for every team to know about every single other team it just doesn't scale so you have to find cohesion and you have to find out which of these contexts and which of these teams need to work together and you have to make easy for them to collaborate so in this example recommendations and search they were involved quite closely in different use cases but in the organization those things didn't really interact with payments a lot so even when you find these bounded context and you've got great boundaries you still need to work out where the cohesion is to enable collaboration between those teams think about it like countries you've got towns counties countries galaxies different levels of abstraction you need to find at each level the things that need to work together so here's one for you I'm going to talk about Salesforce now so I work in the marketing cloud at Salesforce I help people to put adverts on the internet which is something else you might want to hate before please don't not the horrible ads that start playing noise at you even ice ads anyway we have these two contexts one is called the management context enables you to create advertising campaign set up a/b tests et cetera place bid change how much you're on a bit etc but we also have the optimization context this context goes out collects lots of start there's artificial intelligence all that fancy stuff and it tells you yeah this ads performing really well spend more money here this one year it's not doing too well forget about that kill it save your money put the money over here we have these two separate contexts and these two teams who are Knight and independent and innovating very quickly and then one day the business came along with a great idea we've been looking at the numbers and we can see this market they're spending X billion pounds a year we think we can build an exciting product in this area and no one else can build these products because we're Salesforce we have special ways to do it we need you to build an MVP over the next three months we're going to test out this idea get some feedback and if it's good well if there's more time and energy into it which is great you want to work with ambitious companies you have great ideas but then it came back to the teams and they're like well who's going to build this MVP then because it's got bits of management in there it's got bits of optimization stuff in there ddd people keeping our clean boundaries yep clean boundaries you're not affecting our model I think you've got the agile PD for all that not one team who can intimate very quickly can't afford to have two teams collaborating who wins DDD or agile who's voting for DBB who's voting for agile to ham you're right but you're not right because it's that's the wrong comparison to make DVDs never been about keeping these clean models and not compromising that's absolutely not what it's about so what we did here is we said yeah it's evasion speed is the most important thing here we have to iterate quickly get some feedback work out if this product is a good idea and then we can think about later on scaling up and breaking it back out into separate models but what we did do is we said okay a couple of people from each team you can build the MVP but these two teams you are now using Spotify terminology you are now a tribe so these two teams are going to work closely together there but that both teams are going to understand this MVP so when it when it does grow and it does scale they'll have the knowledge to break it back down into different contexts or maybe new contexts so what they're saying is these two teams are now going to insulate a bit slower because they're going to collaborate more but that's important here because Discovery's important we'd rather have two teams going slowly in the right direction than going fast in the wrong direction okay another question for you since you answered the last couple of questions I'm feeling good about this one how do you create alignment between your teams anyone want to guess so if there's one thing you take away from this conference if there's one thing you go back to work on Monday and tell your boss you need to be doing you need to be telling them I want to play more video games that Nicktoons guy he told me if we play more video games our teams will be more aligned and we will be more productive 100% scientifically proven that was a good day that was we were playing Mario Kart having a vector n64 day pretty cool by the way if anyone likes to run play games I invite you to come up and join us at the Salesforce power where we where we play games in between the most hard work but there are other things you can do there are other things you can do so show them cells is a good way so the point here is whether you're doing discovery or not you need to understand how your model fits into the rest of the system it's like we talked about these boundaries will evolve and so you need to understand what other teams are working on show and tells or a really good way to do this help so at the end of each iteration you should try and do a show and tell and it doesn't mean you have to go to every other team but if you're doing show and tells you can be talking about your business priorities your user research and how that's changed your your domain model and other teams may come to your show and tell and realize our well we're working on something very similar to that we should be collaborating with this team or so Chantelle's enable network to form and that's how you get insights about your boundaries needing to change it's happened to me a few times something else you can do is cross team pairing so go and spend a couple of days working in another team just pair up with a developer work on work on their parts of the domain and that will help you to build up this big picture of how your model fits into the overall picture gives you a wider understanding all the different pieces you can also try cross functional pairing and this helps you to get a deeper knowledge so go and work with a product manager or business analysts and understand more about the business priorities and that side of things and when you have all this information about business priorities and what other teams are working on that allows you to think strategically you can see across different teams and you can suggest ways to realign your teams and realign your software if your teams got problems and your models not clean and you're being blocked by the teams if you only say you're having problems people tend not to listen to you if you can say look we're having this problem we've been blocked all the time I know this team has this part of coding in the month I know this team has this part of the model in their code if we can realign these two teams we can fix it but you can only say that if you understand what other teams are working on and something else is offender storming has anyone heard of event storming it's that thing where you put lots of post-its on the wall it looks really cool in the pictures and it is actually quite cool if you get a chance to do it so the point with event storming is again we want to map out as much of the system as much of the domain as we possibly can spanning across many or all of our teams and when we see it all laid out we can see optimizations we can see where our model fits into the overall picture and that helps us to work out when our boundaries can be improved so with all of this in mind I want to propose a different way of thinking about bounded contexts and I said something similar to this at the main driven design Europe and guess who came up to me after the talk Eric Evans all right you didn't like that did you and he went No so he doesn't like it this isn't improved EDD stuff this is me me freestyling it so what I think is that bounded context they're a proxy heuristic for autonomy so when we're talking about language that's used together when we're talking about data that's used together we're trying to create autonomy by removing dependencies removing dependencies in the software and removing dependencies between teams so we can deliver software faster so I think of them as autonomy contexts so what i'm trying to do here is find things that change together for business reasons and thinking about business capabilities specific products or specific parts of a product we then want to get all of the different technical pieces needed to deliver that capability inside this boundary so like we were talking about you can have UI in there if you want to and finally its it's all owned by a single team so this team can innovate very quickly now we can take new new ideas implement and quickly put them in front of customers and get feedback because we don't have any dependencies and for me that's the goal of bounded context but like I told you it's not a big store so here's what you probably should take away from this talk if you don't take away the video gaining thing if you want to be you should take away the video gaming thing but yeah it's Iran so to be good with DVD if you want to create bounded contexts that are truly useful that provides some purpose to your organization your organization has to be in the right shape so you you need to be good at saying yeah I want to connect this modeling code and I need the organization the teams to be structured in this way here's a quote that says that much better than I ever could and basically if you want to be good if you want to create these great models in your code if you want to be effective with DDD if your organization is instructed in the right way you can't be you've lost already you have to fix the organization first or at least work on it so here are some things I think you should do so experiment with models don't think about DVD is this way of creating a perfect model modeling the real world forget about those things just just use those clues and look for different models the model with the case management the model without the case management etc create lots of ideas and learn about Theory of Constraints this is how you can justify your bounded context you can say yeah I've got this model it eliminates bottlenecks in an organization we can deliver software faster justify your choices yet so you can live a software faster and alignment like we were talking about you don't really you don't really just find bound good contacts and that set your models perfect because your boundaries will evolve as you learn more about the code as business priorities change your boundaries need to evolve so you personally you need to have a broader understanding of what's happening in other teams so you know when the models need to change so event storming cross team pairing etc so we're almost finished now the pain is almost over did we find the treasure so I just want to tell you about someone who did all this stuff if you want to find the treasure do what this guy did so back at the start of my career I was working for a lot of companies where I'm having meetings all the time I'm not getting any work done and I'm thinking to myself seriously series true story I'm blinging to myself I don't really want to work in IT I don't really want to work in software I mean I love coding I just don't get to do any of it seriously don't get to be hardly any coding always politics and meetings driving me mad but then I heard about this company they were doing continuous delivery they had open source code on github this was a long time ago and github were just starting and they had this cool manager so I'm like hey can I can I work for you and the manager was like sorry Nick if you come back in a few months we might have a job for you right he could see the passion in my eyes he didn't want to shatter my dreams right there and then he thought if I can get rid of this kid for a few months yeah he won't come back but I didn't take his hint and I did come back in a few months and I hey can I can I work for you now and he's like oh no he's came back he getting back what do I do now is like Nick can you come back in a few more months I'm like what about if I have an interview now and then when you are hiring I can work for you he's like oh he so awkward he couldn't you didn't want to like keep I'm like a little puppy looking at him he's like I can't shut up his boys dreams she's got okay you can have an interview Nick so I had an interview first stage and I passed and I had a second stage interview and I passed and suddenly he's like oh Nick when can you start suddenly he had a job for me straight there and then but that's not the story basically when I started working at this company on my first day I paired up with the senior engineer we wrote some code after lunch we had a glass of orange juice we clicked a button and we deployed that code into production Wow I wrote code and I deployed in one day no meetings their house was none of that rubbish stuff and like six months later I'm doing this every day I'm just thinking to myself it's unbelievable like no other company they're like years and years behind this and so I starting asking people how did you how did we get to be this good how did you make things like this and some people were just like I've been here a year I'm still still trying to get used to it myself it's unbelievable but one person said to me oh yeah yeah was the manager he started here was a developer about a few years ago he started talking about this DVD stuff and serious constraint stuff and we started doing it we started reshaping our boundaries and reorganizing our teams and that's how we got here I'm like wow and that's when I started going DVD in theory of constraints mad learning about all those things but that manager he is now true story hundred percent true story that manager he is now the head of technology a huge organization and then got businesses in different industries and he started out by applying this stuff and just fixing his organization and all of you have that opportunity so I think that's the treasure you should be looking for used EDD and use bounded context to transform your organization not just to create pretty models in your code and you can just remember one thing the art of discovering bounded context like reading lesson at school the arts of discovering bounded context is the art of aligning organizational technical boundaries quotes ever cavernous doesn't this we're finished thank you [Applause]

Channel: Devoxx

Views: 46,524

Rating: 4.5685277 out of 5

Keywords: DVUK17

Id: ez9GWESKG4I

Length: 41min 53sec (2513 seconds)

Published: Wed May 17 2017