 Felly, yn 2011, 2012, rydyn ni'n rwy'n cymaint gwirioneddol gyda cyfnodol ac mae'n ddweud yn ymddi'r drŵn. Rwy'n dweud yn ymddangos i'r company sy'n dweud ymddangos i'r ysgolwyr cyfnod ac mae'n dweud yn ymddangos i'r ysgolwyr. Mae'r cyfnod yn gyfnod i gweithio'r ticots yn ymddangos i'r ysgolwyr, mae'r cyfeirio'r ticots yn ymddangos i'r ffordd, o'r ffordd o'r ysgolwyr, ac rwyfod o'n dweud i'r dweud i'r ffordd ac mae'r dweud yn ymddangos i'r ysgolwyr a ymddangos i'r ddweud i'r dweud i'r dijoeniaeth i'r paru gweithgarwyr, i'r ddweud i ysgolwyr ac mae hyn yn dweud i'r dweud i'r ysgolwyr, oherwydd rydyn ni'n gweld fel yr oed yn ymddangos i'r company a byddai'n gweld eich gweld i'r byd ymddangos i'r cyffredinaniaeth. Mae'r dyma i'r ddiweddol Felly, yn y cwrin o'r company, yn y gweithio cyfnod, a yn y ddechrau, rydyn ni wedi'i gweithio'r peth. Rydyn ni'n gweithio, rydyn ni'n gweithio'r code, rydyn ni'n gweithio, rydyn ni'n gweithio'r code. A rydyn ni'n gweithio'r button. Rydyn ni'n gweithio'r button, a rydyn ni'n gweithio'r producció ar y ddechrau. Felly, mae'n gweithio'r button. Mae'n gweithio'r cwrs. Nes du, rydyn ni'n gweithio o'r tychau, halu cyfoeddion nawr o'r cyfn умilul Certai Llywodraeth Hadwyr Cymru, dwi'n colladdi, nidio'ch fod o'r cyfrwm felly leso'r ddechuillっと ac gennymill yn synthau supply ac b- dato'r troi. Mae'n fwy wedi am Alice, mae'r bod�w dynny'n d Kommentig. Mae yn credits i gael ymgyngoeู่, mae sy'n gweithio'r fowalog boards chi'n gweithio, ac mae'n ddechuwn o tomahag i hed� contain ar-he挑 Llyd. A contacts gallu�r wneudot rhywithodol I wanted to try and introduce it to a company myself, to try and take these ideas I'd been using successfully at other companies that other people had taught me, and try and take these ideas of continuous delivery to another company. So I thought, well, why not try the UK Government? That could be a good starting place to try and introduce continuous delivery from myself. So I worked on a project in the UK Government related to business property taxes and, to be fair, in our team we were doing continuous delivery. We were deploying to production about, on average, three or four times a week, so I thought that was quite good, that was quite a good start. But then the nightmare kicked in when I realised that making significant changes was a very painful and complex process because we had so many dependencies on other teams. We had customers complaining about a bug once, about the address field. It was only three lines long, but their address was five lines long. And so our mission was to add a text box to a web page and make that field longer. Like, how hard can it be to add a text box to a web page? Two weeks later I'm sitting in a meeting with five project managers to put a text box on a web page. Wow, this is what I've let myself in for. How hard can it be to add a text box to a web page? About a month later I'm sitting in a meeting with five project managers to put that text box on that web page and we're not making any progress because we have an architecture and an organisational structure that looks like this. To make one change on the website we need to coordinate a change across all of these services and all of the teams that own them. And this is a problem I've seen many times. We talk about companies wanting to adopt continuous delivery and there's a big effort to make this happen. And we can achieve continuous delivery in one team, but very often we still have an organisational structure and a software architecture which causes so many dependencies to exist that making real changes takes a long time. So when I read Accelerate last year I'm like oh wow, guess what they discovered? A loosely coupled software architecture and an organisational structure to match that's actually quite important for continuous delivery. And then ThoughtWorks in their studies they found that when a piece of work leaves the team when multiple teams must collaborate on a piece of work it takes an order of magnitude longer to complete that piece of work. And I thought well I had five teams and it took about five orders of magnitude longer to not be able to do the work so I can agree with this. And then we see other studies from the likes of McKinsey and what they're finding is even at the big enterprise level trying to achieve digital goals and digital transformation the structure of the organisation which is affected by the structure of the software architecture. That's one of the biggest hurdles at that level too. So the question I would like to look at today is what can we do to design these socio-technical systems to maximise the benefits of continuous delivery not just in one small team but removing those dependencies so teams can make most of their changes without being slowed down. So here's an idea from Alan Holub. What if instead of aligning our software architecture and our teams with activities like front end or back end or technologies like databases what if we try aligning our architecture with the software domain we're working in? The idea here is if we want to make changes in our domain in the business on the products and our software architecture and our organisational structure matches the domain I'm not going to say it will be easy but it will be no more difficult than it needs to be to implement those changes because the only dependencies that will exist in software and between teams are dependencies that truly need to exist in the domain. But how hard can it be to do that? How hard can it be? We see stories like this where companies just oh let's go to microservices let's have these small, loosely coupled software services. How hard can it be? In this case they built their service twice. They had to rebuild it twice because they got their boundaries wrong and they went back to a monolith. We see stories like this too where we move to microservices and we introduce more dependencies between the teams that make the problems worse. So it's very easy for me to stand here and say align your software architecture and align your teams with the domain but it's quite irresponsible if I don't show you why this is difficult and give you some tips on how to do this. I noticed Jezz had some shapes in his PowerPoint this morning in his slide deck. I didn't copy him, I already had these. But here's a game. If this is our domain and we have these concepts in our domain how do we group these in a way that has the minimum number of dependencies? We could organise by shape the triangles, the circles and the squares or we could organise by colours the yellows, the greens and the blues or we could organise things into unique combinations that must be used together at certain stages of our business process. There are always multiple ways to model a domain. But how hard can it be? Well, let's take a simple example. Is tomato a fruit or a vegetable? Very simple question to get started today. Who says it's a fruit? And who says it's a vegetable? Oh, well that's interesting because science says you're wrong. A tomato matches the botanical definition of a fruit. Scientifically a tomato is a fruit. A very simple example and most of you got it wrong. That's why it's hard to design software systems. But actually in the 1800s there was a tax in the United States on vegetables. So people started importing lots of tomatoes because they could use those as vegetables in savory dishes. And so the US government said no, no, no, right. Tomatoes, they are now vegetables. Forget about what science says. Tomatoes are now vegetables and we're going to charge you tax on them. So what this teaches us is that domains are quite fuzzy and contextual. In the context of science a tomato is a fruit. But in the context of cooking because it's used in savory dishes and has a savory flavour it's actually a vegetable even though science says well actually it's not. So from these small activities we can draw some general fundamentals about modelling software domains. So firstly there are many ways to model a domain. Often when we're designing software systems it feels like there's a very obvious choice. A tomato is scientifically a fruit. How hard can it be? But it's not. It can actually be wrong. And it's the context we're working in which defines how useful is a given model. And the way to start understanding domains to find the different context is to look at language. How do people talk about tomatoes over here? And how do people talk about tomatoes over here? What's the language they use to describe these concepts? And that's where we get to which strategic domain driven design. What we're looking for are these concepts called bounded context in our domain. Parts of our domain where certain concepts have a very specific meaning. Where the same word can mean different things in different contexts. So let's take an example from the domain of sports equipment e-commerce. We're working for one of the world's biggest sports equipment companies we've got an e-commerce website we've got a warehouse and we have to be very good at what we do to compete with the likes of Amazon who want to take over everything. And in the company everyone talks about this concept of a product. Oh, a product has a price. A product has a rating. A product has a description. And in the inventory we have a stock. In a very naive team we think oh we talk about this concept of a product and it has all of these properties therefore there must be one class that has all of those properties on it. But that class quickly grows into a God object in the software which all of these contexts become coupled to. And that means the teams are now coupled by this coupling in the software. But we can see in this very simple example that if you're working in pricing you probably don't really care about how much of this product you have in stock or maybe you do in a sense but it's not the key part of your system. You might change the price actually based on stock, that example. Likewise in the catalogue you care about the description of this product but maybe the price doesn't affect you so much here. So the idea with bounded context is we look for these separate models where the different where the same concept can mean different things and we isolate those. Separate bounded context with no shared code no shared database we try to avoid having this enterprise canonical data model which all parts of the system are conformed to and each bounded context is owned by a single team. But this is a very simple example and a very naive example and I still haven't really explained how can you use this information to design systems better. So for this we have a part of strategic domain driven design called domain discovery and this is where we go out and we properly try to understand the domain we're working in and we use a technique called event storming. Has anyone heard of event storming or tried event storming before? Okay, that's cool. So the idea with event storming is we try and get everyone together or as many people as possible who understand something about the domain we're working in. It can be developers, it can be testers, domain experts, product managers. We try and get all of these people together and we ask them let's model the domain we're working in together. Let's combine everyone's knowledge and try and understand this domain. But we have a problem. All of these different people in the business they all talk in very different languages. Developers might use UML business people probably don't know UML too much. So event storming has this simple idea of let's create a very simple language that anyone can use so that we can all model the domain together. So what we do is we model our domain as a timeline of events using orange post-it notes. So if we were modelling the software for a conference submission process we might start with. The call for papers opened event followed by the talk proposal submitted event. After this event the call for papers might be closed and then a talk may be accepted. So far it seems very simple and the idea is to keep very simple because anyone can do this. Everyone is included in your domain discovery and we can have everyone's ideas on the walls. Time and time again when doing event storming you realise that we're not just combining people's ideas of the domain we're uncovering people's assumptions about how they thought the domain worked and it didn't. I was recently doing event storming with one company and the developers were talking about this calculation they create and the marketing person said no, no, that's not how that value is created and the developers were like yes it is because I wrote the code for it and she went oh she was shocked because she was using that figure and it didn't realise what she thought it meant and she kind of shocked and walked out and had to make some changes but orange post-it notes are very simple and as people get familiar with event storming we can start to add more notation we can add small yellow post-its to represent the different kinds of users who are operating in the domain we can add purple post-its to represent business policies and rules and we can use big pink post-its to represent external systems that we must communicate with in order for our business process to work and in fact when you start doing event storming you can start improvising adding all kinds of information that you think is useful once people are up to speed with event storming and they see the value of it people will just start adding what they think is useful so I'm not here to talk about event storming today here are some great resources you can use the one thing I want to share from event storming is once we started modelling our domains with event storming and we have mapped out all of the different parts in our domain these post-it notes turn into those shapes we saw earlier the small squares and circles and triangles and yellows and green and blues and now we're in a position where we can start exploring how do we group those concepts into different bounded contexts so the first thing we do is we use our toolbox heuristics heuristics ask us questions and give us ways of thinking about how could we group these different concepts so let's take an example from a financial products domain so we're working for this company who has a marketplace of financial products credit card deals mortgage years and loans like a comparison website and so the first heuristic might be let's align our software with the domain language as we talked about earlier how hard can it be we have credit card deals mortgage deals and loan deals well the bounded contexts are quite clear here they speak for themselves it's so obvious people are always talking about credit cards, mortgages and loans but then we notice that actually people start talking about something else another orthogonal concept we have tier 1 products and tier 2 products and tier 3 products tier 1 credit card deals tier 2 credit card deals tier 1 mortgage products and tier 1 loan products so now we have 2 ways of slicing the domain and if we listen for the language all of these concepts are used regularly by the business so how do we make a choice in this case well this is where we need to understand the business model we can create many models of the system we're working in but to actually choose the right one we need to understand the business model so we can use activities here like the business model canvas I'm not going to talk about this today but this is an example of an activity you can use which I do use so what we're looking for when we're choosing a model is which are the core parts of the business where the business generates the most value or there's the most potential for value if we can isolate those parts of the system we can make those parts of the code to iterate and add new features on and we want to apply continuous delivery here more than anywhere else so we have this concept in domains of a design of core domains we call them core domains where those parts of the business where the payback is greatest so in this case maybe it was the tier 3 products maybe this business model is about maybe this company generates most of their revenue and we also have core domain customers who want great products with a low interest rate but we also have supportive domains such as in this example the company gives away free financial advice which brings people to the company and helps them to optimise their core domain but there's limited benefits there and we also have a concept of generic domains these are concepts you'll see in many different domains like the ability to make payments for example make payments from customers the idea here is we don't want to gold plate these parts of the system continuous delivery on these parts may not be as important as on our core domains and in fact we may even want to buy those things off the shelf but not always now here's an interesting one finding bounded contexts is also about understanding how will these boundaries in our software affect the people who are building them so how can we design our software systems so that a team's building them have purpose, autonomy and mastery one example of social heuristics is about social complexity if we create lots of very small bounded contexts and lots of small two pizza teams that own each bounded context each of those bounded contexts will be a very simple piece of software it should be much simpler however now there are more chance of dependencies between the teams and we know that that's going to take an order of magnitude longer whenever a piece of work spans multiple teams but if we go the other way and we create big bounded contexts to maintain the rate of working parallel we need to have bigger teams and now we risk burning out the teams if you've got a team of 15 to 20 people has anyone experienced that before where your standups are taking like half an hour and 50 to 60% of the information in the standup doesn't apply to you and you're just holding your eyes open to not fall asleep that's boring but the real pain here is because you're in such a big team there's so much work happening so many slack notifications and emails and pull requests and you feel like you have to keep up to date with all of this information and that can lead to burnout you might end up working longer hours just to actually get any work done so the way we shape the software systems that has an impact on the teams as well DDD has often this misconception that it's all about creating beautiful models in your software that's not quite true because there are many technical factors which can also affect the boundaries of your software legacy software different parts of a system having different performance different needs scalability needs, security needs and the way data is stored and accessed all of these things can still affect the boundaries of your bounded context it's not purely about the domain and also one final heuristic when you're modelling systems it's very easy to ignore the user experience we'll create this beautiful software architecture and then we'll bolt the user experience on afterwards the UI there's really no perfect solution here if we have the monolithic front end we now have a handover between the front and back end teams if we move towards vertical slice bounded context where the bounded context contains the UI as well now we have a risk it's not a guarantee but we risk having a user experience which is inconsistent because different pages are built by different teams it doesn't have to be just add the risk there and I'm sure you've all been to a website or clicking around the website you can kind of work out the organisational structure the company has that built that website it's lots of the pages are inconsistent so those are the five key heuristics for modelling boundaries within each of these key heuristics there are many hundreds of sub heuristics and related heuristics so one technique I would like you to use when you're modelling your bounded context is to create a scorecard or a radar or you just question yourself if we model our system this way what are the benefits in terms of value and domain and social and technical and UX, what are we trading off here and what's the most useful in our situation I'd now like to talk to you about a few patterns but first the obligatory don't abuse patterns slide so if we use patterns as a starting point that's a good thing if we take a pattern from one situation and apply it to another without applying any thinking that's a bad thing because no two situations are really the same by thinking in patterns it teaches us to think analytically like considering those five key criteria but if we just get into a mindset of thinking which pattern should I apply here that can be very dangerous so anyway don't use patterns but use them carefully one pattern I recommend is the business process pipeline as a starting point when you're doing event storming and you're modelling a system it can be very difficult to work out where do we even start here where do we start modelling this domain there are so many different ways I don't know where to start so here's an example from a domain smart cities and urban furniture so we're working for this cool new company and we're building what's called a street sofa it's a sofa which is installed on every street corner all around the world like London, New York, everywhere this sofa has an inbuilt entertainment system where you can find local information you can order a taxi you can view what the weather's going to be like and it also has big advertising displays attached to the sofa because that's how the company makes money so if we were to model this system as a business process pipeline we might find that there are three distinct activities in the business process once the street sofa has been manufactured we now have to provision it with software we have to write some software to provision our software onto the device once we've done that the sofa can then be installed on the streets where it has to be activated activated means it's switched on it's connected to the internet it's an identity and it's alive and then it moves into the management phase of its business process where we can remotely monitor the street sofa and we can send updates and etc so one tip when we're looking for these different steps in the business process is to look for what we call pivotal events in the business these are specific activities which people typically talk about more frequently or with more importance in your business so in this example we've got street sofa manufactured the business are always talking about this manufactured event once something is manufactured we can then start provisioning this street sofa they also talk about provision once it's actually provisioned now it can be installed on the streets so these pivotal events represent transitions in the life cycle of some concepts as always don't stop at the first model or the first pattern the business process pipeline is always just a starting point where we can go from here is to start looking for capability slices so if we analyse the street sofa domain more closely we can see that there's a whole bunch of stuff that needs to be done to provision, activate and manage the furniture control system some software that runs on the device making sure all the different components are working and talking to each other and it has internet connection etc we then have the citizen guidance system that's a separate piece of software installed on a separate piece of hardware and it also needs to be provisioned activated and managed same for the advertising system installed on the sofa so we have these capabilities and now we have those two ways of modelling the system again there's no perfect answer about which pattern is most useful in any specific domain it's about playing the scorecard and working out which is the most useful to you and let's look at a different domain which is commercial airline planning so we're building some software which airlines use to plan the journeys that planes will take so we start off by looking for the business process pipeline here so the first step is we have the routing team and it's their responsibility to calculate the journeys so an airline will have these legs that they're allowed to fly on for example one leg might be from London to Bangalore on Monday afternoon at 2pm the journeys context is all about combining those into complete journeys it then gets handed over to the fleet department and their responsibility is to work out which one of our planes will fly on each of those journeys it then gets handed over to the cruise department and their responsibility is to work out which crew members will now be on each of those flights so it seems like we have a very clear and a very simple business process pipeline here but there's a twist in the story because even when the schedules have been calculated the data can change so we may have a journey and a plane allocated and the crew members all lined up to be on this flight in three months from now but the data can change crew members may leave the company planes may be taken out of service we've seen that recently with the Boeing MaxJets and also legs can be cancelled for example for some reason the flights from London to Bangalore on Monday we may not be allowed to fly that anymore then we have to recalculate all of this now the business say their process is whichever department currently has the schedule it's their job to fix it so if I'm working in the crew department and the routing data changes it's still my responsibility to fix the routing data and to allocate a plane and then to recalculate the cruise so the business have said each of these people has their own screen so they need their own bounded context okay these forces us into a different pattern into an anti pattern you see all of those bounded context need access to the same rules we need to reapply the same rules if the crew department has to fix the routing data they need to reapply the routing rules and the fleet allocation rules so this means we need a separate context where all of those rules live it's like a brain context all of the rules and the logic lives here and now all of the other context in the system become coupled to the brain context and it kind of sucks logic out of them and they become anemic so whenever we want to change one of the bounded context there's a very significant chance that we have to change too in fact if one of the rules changes we might have to update all four of those context in the system so coupling in the software league the coupling and politics in the teams but this is not always an anti pattern sometimes we might want to have a smart rules context it's very rare I would say that but I wouldn't rule it out so the lesson we can learn here is that we just made a big mistake we confused our business process with the user journeys the business said it's up to this user to fix the problems but that's not the business process the business process is we have to recalculate the journey and allocate the plane so in this situation we can use the proposal pipeline or the immutable pipeline each of those users can still have their own screen but that screen can talk to multiple bounded context in the back end by doing this we now no longer have the brain context all of the rules live in the context that owns them and we simply send this proposal back to be recalculated and push through the pipeline again so let's take a look at another domain now connected vehicles so we're building a platform where people can remotely manage and monitor and analyse all of their vehicles out in the world those vehicles could be cars motorbikes or boats or anything now each of those vehicles has its own proprietary format of sending data back to the server or to the main system and some translation logic has to happen there one thing we could do here is have each of the bounded context applying the translation logic to each of those protocols but that becomes very brittle and it makes those bounded context complex so what we can use instead is a gateway interchange context so gateway means we have this bounded context which sits at the edge of our system all data coming into our system from outside goes through this gateway the gateway context will then translate each of those custom protocols into a standard domain format and it will then send each piece of data in the payload to a relevant bounded context that owns that piece of data so we've now isolated all of that translation in one place at the edge of the system obviously we now have gone back to this previous pattern where we have one bounded context which contains all of this logic and others depend on it but there's a key difference here we're not playing business rules in a gateway interchange context it's very dumb translation logic so that's the difference here another pattern you might see when you're modelling domains is the octopus context or the homogenous octopus context and what this pattern is it's about having one context that reaches out and touches many other contexts so I don't know if you're familiar with the concept of GDPR so it's basically this new European regulation that came into place and basically if a customer says delete all my data you have to delete all of their data within a very short timeframe of a couple of months or your company can get sued billions of dollars or half of your revenue so it's quite a big thing so anyway one company implementing GDPR how should we do this so they create a GDPR context all requests come into the GDPR context and the GDPR context reaches out to all the other bounded contexts and microservices and says if you have any data for customer XYZ delete all the data you have for customer XYZ very quickly and send me a notification back when you've done that because I need to keep a record of all GDPR transactions so when we're looking at these patterns we can start to analyse them against those five criteria we noticed earlier and work out what are the strengths and weaknesses of each pattern so if we were to analyse this octopus context pattern here are some of the things we might notice in terms of value it's about cost efficiency or risk reduction we're trying to centralise something in one place so we don't have to duplicate it in many other places now this is beneficial in one aspect because it saves those 10 or 50 other teams having to implement GDPR logic on the other hand it takes away their autonomy and we've now introduced a dependency on the social side and when we think about politics of this pattern because we have one team and maybe 10 or 50 other teams who all depend on them that's going to be a very political situation when they need to make a breaking change you have to convince 50 teams who all have their own backlogs and stakeholders whipping them to deliver new features you're going to have to stop what you're doing and implement this new change that's a very difficult political situation I've been in a number of times and technically if we see a pattern like the octopus where we have many dependencies what we can try and do is to centralise lots of the complexity or some of the workflow inside the octopus when we were implementing this pattern there was one idea that a message would be sent to each a queue on each bounded context and each bounded context would process that message and send a response and if there was an error each bounded context would retry that themselves but now we're saying to every team in the company you have to have a message queue and you have to implement the retry logic yourself that's quite a significant cost across 50 teams who weren't all using message queues so we could invert that and we could put that retry logic inside the octopus and we just say 50 teams all having to implement that same logic ok here's another example slightly different kind of pattern now so let's look at digital music streaming we're a company who provides a platform which enables other companies to build their own music streaming service like iTunes they provide everything APIs for searching for music streaming it, downloading it etc but the company has decided we want to have our own websites we don't want to have a platform we want to build our own website to use our own platform too one pattern we could use here is autonomous context and micro front ends so what I mean by autonomous is each bounded context owns the UI so UI, APIs and data and on the front end we combine these UI fragments into a single web page using micro front ends now this sounds like a great idea because we have fully autonomous teams who own end to end slices but it's actually not a good idea and not because of the UX but because of the dog food context pattern so the dog food context pattern is about creating a bounded context to get feedback on your own core platform so in this case the reason the company wanted to create their own website using their own platform was not about making money they wanted to create this website to get feedback on their own platform to understand how do our customers feel using our platform what can they do, what can't they do and by getting that feedback from using our own platform we can improve our core platform which is where we make most of our revenue as a business so we actually want this handover between the dog food context and the platform that helps us to understand the customer's feeling even though it now takes longer to implement a feature in the front end that we're looking for there's now one final category of patterns I'd like to share with you called relationship patterns so I may have given you the idea that when we're doing DDD and looking for bounded context we're looking for completely autonomous loosely coupled services and teams that never even have to know about each other or talk to each other or have any dependencies that's actually not quite true there will always be dependencies between your software services some kind of dependencies and of course there will always be some kind of dependencies between your teams so with DDD we have a collection of relationship patterns that help us to work out in any given situation what's the best mode of integration between the teams and the software to minimise the cost of that dependency so we have the classical patterns for example we have two bounded contexts that work very closely together so we have a piece of code that's common to both of those bounded contexts which both of those teams work on that's quite a classical pattern you don't really see that too much one pattern that we do see quite often is the open host service the benefit of the open host service is that if you're building a bounded context you don't build a specific end point for every other team or bounded context that use your bounded context you create one standard interface and you ask all of your clients to conform to this interface to much less work on your side and hopefully it's not much more work on their side either another pattern is the customer supplier where we actively engage with the team we're working with and design the interface collaboratively in some situations that's not possible we have to integrate with another system or another service and they're not willing to work with us collaboratively so we might want to create antycorruption layer where we isolate our bounded context from their bounded context and we have a translation layer very similar to the interchange context or sometimes the cost of translating from a different system to our system are so high we just have to accept that we have to accept their scheme or their model and that has to influence the code we create so none of these patterns is perfect and they're all choices equally over the past few years we've started to see different kinds of patterns emerging like in a sourcing for example hey if my team is blocked on your team why don't I just create a pull request in your code and unblock myself now that can be difficult if I've never worked in your team and I don't understand your code base that's where rotation sub teams patterns become useful if we have people rotating between different teams but secondly there's more chance that two teams are working together and one team is blocked on another team the first team can actually submit a pull request because someone in the team has worked in that code before we also have like partnership and alliance patterns and I'll give you an example so one kind of sub teams patterns I've seen is the semi fluid sub teams where we typically have multiple small teams who are all working together on a bigger piece of the system and what they'll do is they'll have one person who stays fixed in the team typically some kind of team or technical lead and then once a month one person from each team will rotate and move into another team the benefits are now if sub team one has to make a pull request to sub team three chances are someone in sub team one has a good understanding of that code so the cost of making the pull request aren't so high there are two partnership patterns where two teams are working closely one example is the begrudging partnership where actually we don't want to work together but we're stuck together like two bounded contexts which are joined by some shared database or some shared code library understanding the trade off with these patterns can help us to make the right choices for example if we see this pattern in our domain we might not want to but it might make sense to have a shared backlog until we've decoupled things another example is alliance teams so this domain we're working in now is advertising tech so we're building this cool product which enables businesses to run advertising campaigns on social media networks like Facebook and Twitter and LinkedIn and one day the business come and say look this snapchat thing is taking off we need to be able to run campaigns on snapchat too how can we implement this quickly because everyone is asking for it and competitors are going to have it soon we might choose to use an alliance team here so we have three existing contexts one's about building campaigns one's about managing them and one's about analysing them and each of those contexts needs to change in order to incorporate snapchat so we might decide we might not but we might decide to form an alliance team where one or two people from each of those teams come together and they work on this snapchat project together until it's finished and then they go back to their original teams now I'm trying to point out I'm not a fan of project teams fan of long lived code managed by teams but this is a very short project team and people go back to their stable teams after and maybe we can do some rotation here too so I'm almost finished now and I would just like to say if you're not familiar with the main driven design and you see all of these concepts it can all seem very confusing and enterprising and scary but that's really not the case and anyone is encouraged to get involved in domain driven design it's not it's not a set of sacred rituals things like core domains and bounded contexts all of these things are ideas in the community but the community is always looking for new ways of working new heuristics new patterns for example event storming was invented I think four or five years ago and the community has adopted this event storming and it's taken off massively and everyone's doing it now so if you like these ideas and you're interested in domain driven design please don't be put off by any of the jargon DGD people are always happy for new ideas and new faces one last thing there are a lot of things I wanted to talk about today and I had to reduce my slide deck from 150 slides to about 80 so here are the things I didn't talk about so evolutionary patterns how do we migrate our architecture from one state to another for example how might we migrate from the brain context to the proposal pipeline there are evolutionary patterns we can use there like slicing scale to make those transitions the way we classify bounded contexts like core domains and supportive so much richer topic there to explore and if you are interested in any of those topics or patterns I've got loads of free content on my website so please take a look and if you like it let me know thank you