Nick Tune - Defining Socio-Technical Boundaries with the Bounded Context Canvas (EN)

[00:00:15] So let's uh, let's do a countdown.
[00:00:19] Five, four, three, two, one.
[00:00:29] Share screen.
[00:00:34] Right, I should now have permission to control everyone's machine. So I'm gonna have a look through all of your photos, choose the ones I like the most, and I'll be bribing you later.
[00:00:46] So, can everyone see my Miro board? Could someone just type in the chat if you can see my Miro screen? Yes, you can see that. Cool. Right, so welcome to my talk this evening. This is my fourth time at Flowcon, slightly different circumstances this year, but still, it's good to be
[00:01:08] meeting up with lots of people in some ways and discussing the same topics.
[00:01:16] Tonight, I'm going to be talking about how to define sociotechnical boundaries with a tool called the Bounded Context Canvas.
[00:01:25] And as you can see, I'm going to be doing this talk on Miro. You can follow along with the Miro link here, or you can follow along on the remote board. Either approach will be fine.
[00:01:44] So the first point I wanted to make is that sociotechnical architecture is maybe not a word you've heard before, maybe it's a word you've heard before. might it's not uh it hasn't entered the public dictionary really yet in technology.
[00:02:03] So you might be thinking, well, if it's not a common word, it probably isn't that useful. But actually, sociotechnical architecture is useful. And if we look at some of the research that's been done over the past couple of years, we can see why it's useful, and also I can explain what it is. So Nicole Forsgren, Jez Humble and Gene Kim, they've been doing their Dora Devops surveys for some years now. I think it's between five and seven, I lost count, probably four.
[00:02:36] And they also released a book about a couple of years ago, and they talked, they looked at how different companies operate, what separates the um high performers from medium performers and low performers, etcetera. And they came up with all of these uh, all of these findings. And surprisingly, what they found is having a loosely coupled architecture and an organizational structure to match was one of the biggest predictors of continuous delivery performance. I know in my experience of thinking about continuous delivery and conferences and books over the years, architecture hasn't really been at the forefront or the center, the center piece of continuous delivery. But here they are in this book saying, well, architecture is key, one of the biggest predictors of your organization's ability to perform with continuous delivery. They also found that this, this quality of a loosely coupled architecture and organization structure allows you to grow your organization and uh scale performance linearly, so every time you add a new person, you get a predictable amount of productivity out of them. It's not like the typical companies where we have such big bottlenecks where adding more people slows things down.
[00:03:51] What they're actually saying here is adding more people, you continue to be more productive if you get the architecture boundaries right and your teams are organized around those architectural boundaries.
[00:04:05] So ThoughtWorks, they did some studies on on their projects, and I was uh, I think I saw this from a talk by James Lewis a couple of years ago, and what they found on their projects is
[00:04:20] what they call it when work leaves the team, so basically, when a team has to collaborate with another team on a piece of work, it takes an order of magnitude longer for those teams to complete that piece of work, compared to just one team working on that piece of work on their own. Now, this isn't a universal rule, but looking at this finding, looking at the accelerate findings, we can see that the signs suggest that by having a loosely coupled architecture and
[00:04:50] teams which are aligned to that loosely coupled architecture, we can perform more effectively as organizations.
[00:05:02] Now, what tends to happen when when we talk about loosely coupled architecture, autonomous teams, etcetera, we start talking about microservices and two-pizza teams. And this idea that if we just make things small, then we'll have good design, we'll have the right boundaries, the right teams, etcetera. But, you know, let's think about this for one second. To get these big productivity gains just by making things smaller, nothing's that easy, and designing complex systems will never be as easy as let's just make, let's just make things smaller. And as I'm as I'm saying here, we wouldn't even have a job if it if it was that simple, so let's be grateful things aren't too simple.
[00:05:53] And let's think about a couple of the principles or one of the key principles here is about complexity. We have to balance local and global complexity. So if we make things smaller, each individual piece is it has less moving pieces, less size, less volume, it is simpler to understand that one piece in isolation. And that's local complexity. The problem is, by having more pieces, there are more interactions between those pieces, and the global complexity of the system is higher, the interactions between those things.
[00:06:31] So size is helping us to balance local versus global complexity. And that's just one of the key trade-offs. If we make everything too small, we just go all the way towards local complexity. So local versus global is is a trade-off. And this also has impacts. So think about, think about back to the accelerate findings. They're talking about architecture and organizational structure.
[00:06:59] So and if we think about ThoughtWorks, by having more pieces which are smaller, we we have more opportunity for pieces of work to leave the team. We have it's more likely that multiple teams will collaborate on a piece of work. Therefore, more work is going to take an order of magnitude longer to complete.
[00:07:24] This diagram here visualizes what happens when things get too big. If we start making services too big, we have to expand the team, we have more communication paths in the team, and we have increased um social complexity, the complexity between the people involved in the team. So lots of trade-offs here about size. And it's making things too small, making things too big has a lot of trade-offs and it's not that simple.
[00:07:55] So, how do we find good sociotechnical boundaries? What might be something that can help us here?
[00:08:11] So I've put together this short diagram and I want to try and visualize some of the key players involved in this system and and and the relationships between them. So we have software development teams. And what teams are doing is they're working out what problems do I users have, how how can we solve those problems? And the teams then build a software architecture, a software system, which provide the capabilities to satisfy those user needs. As Melissa Perri talks about in her book Escaping the Build Trap, this is a value exchange. The company creates value and users or businesses or customers exchange their value for the for the business value, for customer value.
[00:09:00] So, what what can we say about these relationships here that might help us to understand how to how to design and evolve good sociotechnical boundaries?
[00:09:15] So here's one I prepared earlier.
[00:09:20] So what we know is that the architecture of the development teams or the structure of your organization is going to be um aligned to the software architecture or vice versa. And that's known as Conway's Law.
[00:09:38] What we also know is that the software architecture is a model of the business domain that we're working in. And the market is is actually part of that domain.
[00:09:52] So, what this really tells us is, we need to understand the domain in order to model the software architecture in in a loosely coupled way, in the optimal way, and then that becomes the template for the organization of our teams. So start with the domain, look at a software architecture and then try and fit the teams to that architecture. In in reality, it's a much more iterative process.
[00:10:25] But essentially what I'm saying is, try and start with the domain.
[00:10:31] That's the first part of this talk. The second part is touching on the concept of domain architecture a little bit before we get to the canvas.
[00:10:46] So one of the first points I want to make is when when people talk about, we're going to move to product teams, autonomous teams, aligned to parts of the domain. That's a good decision, but that's not a solution. Choosing to align your software with your domain is there's not a one-to-one mapping there because there are many ways to model your domain. You you have to design the boundaries, you don't discover them. You're not looking for perfect boundaries that exist.
[00:11:17] So let me give you an example here.
[00:11:20] So let's imagine you're working in a domain.
[00:11:25] And your domain has these concepts.
[00:11:29] So you've got shapes and you've got colors.
[00:11:33] How do you organize these domain concepts into your architectural boundaries, into your microservices or your two-pizza teams, etcetera?
[00:11:45] There are quite a few ways you can do that, there are more than three ways you can do that. You can organize things by shape, you can organize things by color. You can organize things into unique combinations or things that must be used together. And this is really what domain modeling is about too. Like there is no one perfect solution, like finding domain boundaries is is a design process, a discovery and design process in and of itself.
[00:12:14] And so, in order to find the right boundaries, there are a couple of couple of characteristics or heuristics to think about. So the first one is, what's your business model?
[00:12:26] So a tool we can use here is the business model canvas. So, for example, if we're looking at shapes and colors, if our business model makes 90% of our revenue from colors, then maybe we want to organize things by color. But if our business model is making 90% of our revenue by shape, maybe we organize things by shape. So it depends. The way we align our domain boundaries depends on what we're optimizing for as a company, what's the business model.
[00:12:55] And if you look into business models, you'll see there are lots of different kinds of business models, and this article here talks about 50 from platforms, uh multi-sided marketplaces, freemium model, etcetera. So, so in order to have the loosely coupled teams and the loosely coupled architecture, you need the domain boundaries.
[00:13:14] And the right domain boundaries, you need to connect that back to the business model.
[00:13:25] Also, even if you do understand the business model, that alone doesn't help you to choose the right boundaries, it doesn't help you to find the candidates because it's also about coupling. We need to understand which things are changing together. And this is where domain driven design talks about language, looking at, looking at words in the domain which are used together.
[00:13:53] So let me give you a quick example of this.
[00:13:57] So the the concept of a tomato could be classified in different ways depending on your context or depending on your domain. The botanical definition of a tomato is a fruit, but if you're in cooking, then it's it's a vegetable because it's used in savory dishes as a vegetable. And even when there is a scientific definition of things, the way your domain the way people think in your domain may contradict science. So there's this famous story about the United States of America, their Supreme Court in the 1800s, they declared that tomatoes were vegetables, even though scientifically they're fruits, so they could charge more tax on them because people were importing tomatoes to avoid paying um the tax. And that's the essence of domain-driven design. Domain-driven design is all all about, model your domain, uncover domain language, use that to find these boundaries and and look for your core domains, which are your business model. to find out where to focus. So so that's a quick primer to the background of why the canvas can be useful. I'm now going to talk to you about the canvas itself. I quickly check the time. I'm quite good.
[00:15:19] So talking about the boundaries, the sociotechnical boundaries, um they're actually bets. You're making a bet. So we've we've got our domain, we've got these many different ways we could architect our system around the domain, we have many different ways we could organize our teams. How how do we make a choice? So we make a choice based on our business model, based on things that will change together. So minimize the coupling, minimize having to make a change across two services, across two teams at the same time. But in order to do that, we're guessing. We're guessing about how we think things will change over time because we can't predict the future. So our architecture and our organizational structure is a bet. We think that these boundaries will lead to the least amount of coupling over time and the least amount of um work leaving a team.
[00:16:19] So the bounded context canvas, I consider this tool to be a way to view your bet.
[00:16:27] So you can see all of the key information in one place.
[00:16:34] And you can ask yourself, does this bet make sense? Are these the right boundaries we want to go for in our system? Do we think that these choices cohesively will lead to the looseest coupling and uh highest autonomy in teams and obviously the greatest flow between teams?
[00:16:56] So here's the canvas, and here's I've highlighted how each section of the canvas touches on things, the concepts I just explained to you. So at the top of the canvas on the left, we have a description. I didn't actually talk about this part, but I talked about the others. So the description is really about the purpose. What So a bounded context is effectively a microservice, you can think of it that way, a module in your monolith. So the description is effectively, what does this thing do? What's its purpose? What business benefits does it provide? And that description, that purpose, helps you to understand how motivated would you be as a team if you were building this? Does this excite you? Would you be proud to build this? Is it an interesting challenge? So this helps you to see things from the team perspective.
[00:17:48] Uh this I'm referencing Daniel Pink's book Drive here. He talks about purpose, autonomy and mastery as being the key motivators for people to produce their best work and feel um connected to their work. Moving back to the canvas, we then have the strategic classification. This section looks at business model and business strategy. How does this individual bounded context play a role in your business model and your business strategy? We then have the domain roles which talks about the the type of behaviors this bounded context has. And that's focusing on local complexity, how complicated are the concepts inside this bounded context? When we move down into this section here about inbound communication, outbound communication, now we're looking at global complexity again. How big is the interface of this context? How many messages does it consume and publish? So that that's the global complexity, the number of collaborators it interacts with. These are team dependencies. So for every service or microservice or other bounded context that this bounded context talks to, that's a dependency for the team that owns this bounded context. So that's team complexity there.
[00:19:09] And then in the middle, we have the ubiquitous language, which is like a business glossary. We can capture key domain language concepts here. And the business decisions is kind of your business rules. So how complex are these business rules? So that's the local complexity. So, as you can see here, with with this canvas, we're trying to capture all of the concepts I talked about previously, which affect our boundaries. And so we can look at this overall canvas as a bet with all the information in one place. Do we want to make this bet? Will this bounded context give us loose coupling and team autonomy? That's a dependency for the team that owns this bounded context, so that's team complexity there. And then in the middle we have the ubiquitous language, which is like a business glossary. We can capture key domain language concepts here and the business decisions is kind of your business rules. So how complex are these business rules? So that's the local complexity. So as you can see here, with with this canvas, we're trying to capture all of the concepts I talked about previously. They affect our boundaries. And so we can look at this overall canvas as a bet with all the information in one place. Do we want to make this bet? Will this bounded context give us loose coupling and team autonomy?
[00:19:51] So the Bound context canvas is creative commons. It's on GitHub. It's the fourth version now. Uh, I started it last year, but it's now changed a few times. We get lots of contributions and questions on GitHub, that's all fine. If you have ideas to improve it, that's good too. There's also a free mirrorverse template which you can use here. Uh, if you've not used Miro before, you can sign up with a free account. Go to the templates, type in bounded context canvas and you can just drag this onto your board. Yeah, it's it's all totally free.
[00:20:23] And here I've prepared a a very a partial example for you.
[00:20:29] Here are some of the insights you can get from the canvas. So if I start here with the description,
[00:20:36] we can see people are talking about it's built using CQRS and event sourcing. A bit too technical.
[00:20:44] The description doesn't really explain anything that the name doesn't. So we can see here, we probably don't understand the purpose of this context. We haven't captured the elevator pitch to explain to non-technical people why we're building this and that's important. explaining what this capability is and how it provides value. So if we see a warning sign like this,
[00:21:08] we're not ready to build this, we're not ready to commit to this bet because we don't understand the business value enough. We can then see here in the street strategic classification, we've got something which is core and it's also generic.
[00:21:22] I'll talk about these concepts later. But when we see those things together, it tells us, hmm, we've got two different concepts here. One is essential to our business model and the other is a small generic piece that's not. Do we want those things coupled together? Do we want the generic bits slowing down the core domain or what if we want to outsource the generic bits later, we can't now, it's coupled here.
[00:21:50] We can see in the domain roles on the right-hand side over here, it's it's got three different roles here and these roles have very different purposes. So again, it looks like it's doing too much, the local complexity is too high.
[00:22:04] And then we can look at the interface down here, we can see that this context is publishing five messages to five different collaborators. We've got so we've got five different collaborators here and they all have their own requirements. That's probably five different dependencies on different teams there, that might be too much to manage. And we can also look at the interface itself and just think, is this a good design?
[00:22:32] So if I look over here at the collaboration with the public website, we've got get my property tax, compare my property tax, add a credit card.
[00:22:42] Those those concepts don't belong together, adding credit cards and looking at your tax. I'm sure there's a joke there about, yeah, I can't find it. But anyway, this is like, this is a basic idea of how you can use this canvas. And some of the problems you can uncover touching on those different aspects of local complexity, global complexity, social complexity, etcetera.
[00:23:10] And if you're interested in the canvas, there is also this tool on GitHub. called contexture. where a company called software park, they are building a tool where you can manage the boundary context canvas. in in a system, store it as data and maybe connect it to your codebase. and automatically generate the canvas from your codebase. That's quite a new product though, so it's not it's not that advanced yet, but it's worth keeping an eye on.
[00:23:40] So I want to quickly jump away from the canvas for a couple of minutes and I want to talk about how you get to a situation where you've got the information on the canvas so you can review it. and assess that bet.
[00:23:52] So over the summer, some of us, we put together this modeling process. So if you're new to domain driven design, you're not sure where to start, not sure how to design your domain architecture. This process gives you a first iteration through the design process. It's definitely not a waterfall modeling process. It's highly iterative. You don't always have to do things in this order, you don't do things just once. So if you're not sure where to start, go through these seven or eight steps. and then evolve your design from there.
[00:24:28] So first thing we can do is the business model canvas as we talked about, use that to capture our business model. We can then do some event storming. So get lots of people together, model our domains. either remotely or in person, add some timelines.
[00:24:47] And once we have our once we have our domain laid out,
[00:24:51] we can start breaking that domain down into possible bounded contexts, looking for possible boundaries using heuristics, etcetera.
[00:25:02] Some of the heuristics I talked about earlier, so business value, organizing by domain concepts, language, thinking about team size. Bringing in some technical constraints there. So if you have legacy systems that will impact your boundaries, we can then start looking at how these systems talk to each other, designing message flows between them.
[00:25:26] And we can use Eric Evans's concept of the Whirlpool, so we we we design our architecture, we explore different use cases and we evolve the architecture.
[00:25:38] We can then start mapping out mapping out our different bounded contexts as core supporting and generic. to make sure we've we, you know, to make sure we know if each context is one of these and not it's trying to do too many things.
[00:25:52] So I skipped through that very quickly, but once once you go through this process once or a couple of times, you'll be in a position where you can start populating the information from these tools onto your canvas.
[00:26:07] And then we can start building the canvas.
[00:26:11] So this is really the main section of the talk now, how you can build up the canvas and how you can make make um, get some value from each aspect.
[00:26:21] So the first part of the canvas is the name. People might just think the name is a generic placeholder, which doesn't have any value. It's often, it's often one of the most useful parts of the canvas. because naming stuff is hard.
[00:26:37] And people try and use we just try and use easy names. So generic words like management. But words like management are bad because because they they don't they don't make it clear what's inside and what's outside.
[00:26:59] So generic name attracts generic behavior, the word management is very generic. So looking at this, like anything related to business property tax could belong in here because the word management doesn't say which aspect of business property tax we're dealing with. So a more specific name here would be the business property tax register. Like it's more specific, it's clearer and it makes it easier to identify what doesn't belong here.
[00:27:30] Also, with the name, um, one of the one of the trigger words is and. Whenever someone uses the word X and Y, it's already a warning sign that we've got two things here. Whenever we see the word and, we can always just wonder, what if we split those two things into separate contexts?
[00:27:51] We then get to the description.
[00:27:56] And this is where people start to realize they had different ideas about what this context was. So even when people can agree on the name, when you force them to put those fuzzy fuzzy thoughts in their head onto the canvas as a couple of sentences or a couple of paragraphs, that's when people have clashes of ideas. Like, oh, I, I didn't think that would belong in here, I thought that was somewhere else and so on. And so just by writing the name and a description of your context, you can already find where you disagree or where you had misalignment on those ideas. And also in here, we can also look out for the word and in here too. Whenever we see the word and, whenever we join two concepts, it's always a potential boundary to split those things separately.
[00:28:48] So I like to use the format of what and why. What does this thing do and why does it do it? And I, I always tell people, imagine you're in the elevator and the CEO walks in or someone who doesn't work in software. And you have to explain to them what you're working on, what value does it provide to the company and how what does it do? I think that's a good way of framing this.
[00:29:15] And definitely you don't really want to put implementation details in here. We're talking about an elevator pitch, the business purpose. We're not talking about which database or which programming language will be used to build it. We're not, we're not at that level of detail here.
[00:29:33] We then look at the strategic classification. So this is going back to the business model we talked about earlier. So domain driven design, we have core supporting and generic. So your your core domains are the parts of your system where the more you invest in them, the greater the payback. Supporting domains are there to enable you to optimize your core domains. They provide features which don't have a big ROI for your company, but they're necessary, they're limited to your domain. And then generic domains, they are
[00:30:10] things that you'll see in many different domains. The obvious examples are identity services, payment services, etcetera.
[00:30:19] On here, we can also talk about the role that this bounded context plays in the business model. So, does this bounded context represent a set of features that customers pay for directly? Does this bounded context represent a set of features that bring people to the product but don't generate revenue? Is it about compliance or is it about something else? These four examples here are just um, a couple of suggestions, you can, you can kind of put anything here. And then evolution is talking about Wardley mapping terminology. So how will this context evolve over time and what level is it now? Is this a commodity? Is it something custom built, new and adventurous?
[00:31:07] And that helps us to think about the long-term view.
[00:31:14] So I've got a quick example here of those business model roles. So if we're thinking about search engines like um Google or Bing,
[00:31:22] search itself, we don't pay to use search on Google, that's a free feature, that's an engagement feature. Advertising is how the company makes money, that's revenue. And then GDPR is about compliance.
[00:31:37] Now, what's interesting is your core domains aren't always your your revenue generating capabilities.
[00:31:48] So in the example of Google search, um, it's the search that brings us to Google. If there was no search, we wouldn't go there for the adverts. Maybe some people would, but I think most of us probably wouldn't use Google if it was just adverts and no search. So what's core is what makes your business different, not what makes you the revenue.
[00:32:13] And if you haven't seen Wardley mapping before, this diagram makes it look very complicated and scary. But it's actually not that scary. And uh, I think if if there was one tool or technique I would recommend to almost anyone, it's probably Wardley mapping. If if not for Wardley mapping the technique itself, just the concept of thinking of how how do things evolve over time, how will these different parts of my architecture evolve over time? And this can help us to make choices like we we can't buy this thing. off the shelf now, there's no commodity products available, but we think there might be one in one or two years. So let's build it in a way that enables us to replace it with an off the shelf solution. Or we might see that our core domain is going to become a commodity soon, and that tells us what's the next core domain? In one or two years, this thing won't be special anymore. What what's the future?
[00:33:17] Right, then we get to the interface.
[00:33:21] So a bounded context is a box. It has queries, commands and events coming in and queries, commands and events going out. A query is a request for information.
[00:33:33] So a bounded context A might ask bounded context B, give me a list of all the users who haven't paid their bill. A command is a message or an instruction telling another bounded context to do something, Hey, delete my account.
[00:33:49] Or add this item to the basket, for example. And an event is a notification that something has happened.
[00:33:57] And I think this, this um, this pattern, these these concepts are a good way of thinking about all communication that comes in and goes out.
[00:34:10] Yeah, uh, not much more to say there really, I think I'll move on. I'm sure there was something I wanted to say there, but I forgot now.
[00:34:18] So anyway, using the language of commands, queries and events, we we can map this in kind of a visual way. So the inbound communication on the canvas is showing things coming in and the outbound is showing things going out. And we can we can see patterns here. We can we can spot obvious patterns like we have chatty communication with another bounded context. It sends a query, it sends a query, it sends a query, then it sends a command. Like how can we reduce those four messages into one message to reduce the coupling between those systems. When we talk about messages, we're not talking about a message bus here. We're not talking about Kafka or anything like that. We're just talking about representing each communication between different bounded contexts in in a logical way. What's the what's the intention of that communication? And so commands, queries and events fit that nicely. And I think even if you're not a developer or an architect, you should still be able to be involved in these conversations. It should still make sense to you. This is about domain architecture, business architecture. It's it's not about software architecture. In fact, these messages could be between people talking to each other in the organization almost. We're trying to keep away from software at this point, think about domain architecture.
[00:35:48] Um, I've got a couple of tips here. When you when you, so I was talking about the canvas as a bet, a way to visualize your bet. And so when you visualize things, you can spot obvious patterns, you can apply critiques, obvious critiques to them. So naming, you can look at all of the messages on your canvas and the description and the name and just think. Do all of these words together, does it all make sense cohesively? Are we using the same word consistently? Are we using two words to describe the same thing? Are we talking about tax and credit cards when they don't belong together, etcetera? We can also say, what happens if we flip the message type? What if we replace this command over here for an event, how does that impact the design? How does that impact the coupling in the software and the teams? And we can look at encapsulation trying to reduce the size of the interface to reduce the global complexity.
[00:36:45] On the canvas, we also show collaborators. And typically, there are four different kinds here. A bounded context can talk to another bounded context, an external system like Salesforce or Stripe. For example, you can talk to a front-end/mobile app. Or you can have users directly interacting with your bounded context. And as as I was talking about earlier, usually, the collaborators are dependencies between the teams. So the team that owns this context and the team that owns the public website, there's a dependency here. And if if we see too many dependencies, we can we we've got a warning sign already before we start building this context, it looks like it's too big. We've got too many dependencies here. Can this one team manage relationships with these five different other teams or will it be too much of a cognitive load? I think Matthew Skelton will talk about that on I think he's on Thursday.
[00:37:45] Again, we can look at the collaborators and apply some common critiquing patterns here. How many dependencies? We can challenge each dependency, what would it take to remove this dependency? We can look at the chattiness.
[00:38:07] All right, so now we get to something which is, um,
[00:38:12] so it's called context mapping. It's it's been in domain driven design from the original days in the big blue book. And context mapping tries to describe the relationship between bounded context and between teams. So there's a technical element here and there's also an organizational element, and this helps us to identify problems up front.
[00:38:34] So one pattern over here is a partnership.
[00:38:37] A partnership is when two teams are working together, so two teams, they own two bounded contexts, a bounded context each, and they're working together towards a shared goal. We have patterns like the conformist,
[00:38:52] which says, my bounded context is going to adopt the domain model of your bounded context. Because there's too much effort to translate from your world to my world. So we have a bunch of these patterns and and we can show them on the canvas. So for each collaborator, we can see the kind of technical integration and the and the team relationship. So one thing we might say is if a bounded context is collaborating with six other bounded contexts,
[00:39:24] and it has a partnership with all of them, that means this team has a partnership with six other teams.
[00:39:31] And a partnership is working towards shared goals. So going to the shared meetings, maybe having a shared backlog, lots of shared ceremonies, that's a very high level of collaboration and coordination. The team probably can't get too much work done. If anyone here's heard of team typologies, you'll see that there's a lot of overlap here. So the partnership pattern from domain driven design is is akin to the uh collaborating pattern from team typologies. Team typologies has an X as a service collaboration mode, interaction mode in domain driven design, that's similar to an open host service. So that there is some overlap here. So if you wanted to, you could use the team's typologies patterns here and not the domain driven design patterns.
[00:40:23] We then get to the business decision section of the canvas and as I talked about earlier, this is the business rules.
[00:40:32] So firstly, this helps us to work out how many complex rules do we have here. How complex is this going to be locally?
[00:40:41] We can work out which of those rules is made by the software and which of those rules, which of those decisions is made by a user. We can start to analyze what information does this bounded context need from other bounded contexts to make this decision. How many dependencies do we have in order to apply this business rule? So this rule might be a sign, this rule might be the cause of too many dependencies. And then we can also ask, who cares about the results of this decision? Because when we talk about who, we're talking about other teams and other bounded contexts. The more context that care about this decision, the more coupling we have on the outbound communication side.
[00:41:25] We also have a couple of different kinds of rules or decisions.
[00:41:30] So some rules we apply up front for business rules that can never be violated. Sometimes we can't prevent situations from happening, we have compensating rules that apply afterwards.
[00:41:45] So I've got a couple of examples here.
[00:41:48] So an invariant in domain driven design terminology is that all usernames must be unique. It's never acceptable in the system for two users to have the same username, that will just break everything in our system. It'll violate all of our security and privacy rules and it just can never happen. Now another rule is that your bank balance cannot be negative. However, it's not always possible for banks to enforce this rule because of outside um constraints. So when I was 16 years old, I think or 15, um, I had a bank account, like a a teenager's bank account, and they told me, yeah, we've got a business rule, Nick, you can't go overdrawn on your bank account.
[00:42:33] I thought that's cool. Save me from myself. And then one day I got a letter in the post, Hey Nick, that bank account we gave you where you can't go overdrawn, you're overdrawn and you've got 30 days to pay us back and if you don't, we're closing your bank account. They closed my bank account. So the the point here is that sometimes you have a rule but you can't always enforce it, you have to apply some compensating action afterwards. So the the canvas helps us to think about each of these rules and if we're doing upfront invariant or compensating policies to enforce them.
[00:43:14] We then have the ubiquitous language. So this is a glossary of domain terms which exists only in this bounded context. The each each of the phrases here, the definition only applies in this bounded context, we can have the same phrases in different contexts and they can have different meanings. So my tomato is not your tomato, you own the definition here.
[00:43:36] And this helps us to just capture what are the key terms in this context we think everyone should know about, what are the definitions we need to get straight. And also, one of the benefits of domain driven design is that we keep the code using the same language as the business speaks in. That way it's easier for developers to talk to the business, take those requirements and implement them in code because it's the same same language. So this ubiquitous language section helps us to capture the important domain terminology. And we can identify those problems like tomato where it has multiple meanings.
[00:44:14] And then domain roles. So domain roles is a bit fuzzy at the moment, it's not a clear defined concept. But it helps us to think about what type of behavior does this bounded context have? So Alberto Brandolini, he talks about these three different kinds. So he says some bounded contexts are all about creating a specification.
[00:44:40] They they describe something that needs to be done. That description is then handed over to a context which executes it, it manages the business process. And then we have other kinds of contexts which keep a record of things that have happened and they watch the execute and they they just analyze what's going on. So an example here was when I worked in the um, when I worked in marketing. So we had one context for building an advertising campaign. You specify your your target audience, how much you're prepared to bid, when you want the campaign to run, etcetera. That specification is handed over to the advertising campaign runner, that runs your campaign for a period of time.
[00:45:25] And there's also a context which is watching your advertising campaign and it's analyzing what's happening and it's calculating how could we optimize this advertising campaign.
[00:45:37] So just thinking about which type of bounded context we have can help us to see concepts which shouldn't belong together. So if we have draft and execute together, maybe they should be separate contexts. But in any case, we want to decouple those bits of the code in case they do become separated at some point in the future.
[00:46:01] And a couple of the heuristics here is the more roles you have, obviously, that's a bigger warning sign, it's indicating local complexity.
[00:46:13] I guess do the do the roles match up with the interface of your context?
[00:46:20] So if you're saying your context is a draft context, I don't want to see loads of messages on the inbound and outbound communication about executing some business process. There's an inconsistency there and that's a a design smell we need to zoom into and explore in more detail.
[00:46:40] So that's pretty much it now on the on the timeline anyway, so I just want to quickly show this recipe with you for finding good boundaries, for making good boundaries.
[00:46:50] So, understands the business model.
[00:46:54] Explore the domain. Identify your tomatoes and where they're not really tomatoes or different kinds of tomatoes.
[00:47:02] Then we can start looking for options, how can we group these domain concepts into shapes or colors or combinations? We need to be keeping in mind keeping our minds on local versus global complexity. And then as we're doing this, we need to be thinking about what's the impact on the organization. What's the social complexity here? And do these bounded contexts give our give the teams that own them purpose?
[00:47:30] And then as always, think about your design as bets. You're making bets on the future, place your bets and then monitor those bets. Are those bets um working out as you anticipated or are you having more coupling than you expected? So just one final thing here. I put together a load of resources down here. So team's typologies book, business model book, organization design journal, and a and a couple of books which I found to be useful in this topic.
[00:48:00] There's also the virtual DD meetup and the domain Z conference next year.
[00:48:06] And that's it. I'm going to hand back over now for um

Transcript