About this talk
Learn about Domain-Driven Design, and why it's important to know about it if you want to work with microservices.
- Right thanks for coming everyone tonight, my name's John Staveley, I'm a Dot Net contractor based in Leeds, I also help run Leeds Sharp. And I also run Leeds French Meetup, the largest French speaking society in Yorkshire, we have about 1,500 members and we meet for discussion groups and cheese and wine tastings. But that's not relevant to my talk tonight, but why I've explained that to you will become obvious later on. So my talk tonight is about Domain-Driven Design. If you're like me you started off with the blue book by Eric Evans. Sorry first of all, has anyone heard of Domain-Driven Design? Yeah. Is anyone using it? No, okay. So Domain-Driven Design, broadly speaking, is a way of organising your business logic for better maintainability and reuse. And if you wanna use something like microservices then it's kind of key and it underlies all of that sort of stuff. So that's your motivation for understanding it, if you want to move to a microservices architecture. So I started learning about it about ten years ago. Eric Evans book, it's a bit opaque, it's slightly out of date, it's badly arranged, the chapters are in the wrong order, he said so himself. Then they brought out this book by Vaughn Vernon, TLDR, doesn't even mentioned microservices, one of the main reasons for using it. It's meant to be a good book. And then finally they brought out this one, Domain-Driven Design Distilled, now that is my kind of book, I can read that and it's very easy to read and digest and so my talk's kind of based on the offshoot of this book. But to get it clear in my head, I needed a mental model of all of the different concepts, coz it's got aggregates, aggregate roots, sub-domains, core domains, partner domains, context mapping entities. And none of it really sat well in my head until I could get a mental model of it. So this is kind of what I came up with. Let's imagine that you've got a problem you're solving, and that's your domain, what's called a domain in DDD. If you make that analogous to something geographical like a continent, your domain would be the continent. Your sub-domain would be a country within that, in our case it'd be the United Kingdom. So the sub-domain is in the problem space, which could be different to the solution space and that's also a country, called a bounded context. Now one of the concepts used a lot is ubiquitous language so that's the language spoken within the sub-domain, so in the United Kingdom that would be English, in France that would be French, okay you can see where I'm going with this analogy. And the core domain is the country with the highest GDP, obviously in the EU that's the UK. And then it comes up with another concept called supporting partner. So that would be the biggest trading partner with above, with the core domain so that might be Germany for instance. And then it has a concept of context mapping, so this is how the different domains speak to each other. So within our geographical analogy that would be borders and how you cross them. So how I go between the United Kingdom and France, or the United Kingdom and Germany. So it has all these concepts, and it fits them all together. So within those domains you model other things, like objects, like people, like money. Let's say we add a concept of money, here you go, you might model, this is what's called the value object because, one of these is pretty much the same as one of these. It has no state about it, there's nothing intelligent and the idea is to put as much of your domain logic, your business logic in the value objects as possible to increase maintainability and reuse within the system. But let's say we model it differently within the system and that pound note actually has a unique ID on it. So that now is an entity within the system because it can be uniquely identified within your core domain, within your bounded context. Now I'm gonna go on to the idea of context mapping, again this is how the different bounded contexts speak to each other. And for this I'm gonna need a volunteer from the audience, someone with good acting abilities. Right, so in the problem we're trying to solve, the French bounded context is trying to buy a ticket so he can see his sweetheart in the UK, so he's speaking to the British bounded context so he can enable that transaction. - Toilet's down the 'all mate. - Now as you can see the two bounded contexts don't understand each other because they don't speak the same ubiquitous language and this is where context mapping comes in, and now I'll be talking you through the different strategies you can then use to, for the different domains to talk to each other. So now we'll go through the conformist mapping strategy. - Sorry mate I don't quite getcha. - The café's over there. - Oh you fucking English pig, I would like to buy a ticket. Right so at this point, French bounded context has abandoned all hope for the British bounded context is going to talk the same language as him and so has conformed to the ubiquitous language of the British bounded context. We'll now move on to the anti-corruption mapping strategy, for which I shall play two parts. I shall play the French bounded context, the anti-corruption layer, and then my colleague here will play the British bounded context. He'd like a ticket please. - Can you tell him it's €50 please. - Now you see with the anti-corruption layer it isn't necessary for the two bounded contexts to speak the same language, you have an anti-corruption layer sitting between the two of you which translates in between the two layers. So if you had an inventory service talking to a purchasing service then you would have a layer in between that would translate between the two of them. Now we'll talk about the shared kernel strategy. Ticket! Here no one makes much sense, but what we have is a core language between the two of us that is shared between the two bounded contexts. For that particular transaction we have some core logic that we share between the two contexts. Now we're going to do the published language strategy. Okay so now we've just interacted using some JSON, so obviously the conversation was very brief, it was very terse. So I showed some money, he showed a ticket and then everything was good. Now we will talk about the separate ways, also known as the Brexit context. I'm writing my own ticket. Now here we've decided that it's too much effort talking to each other and we're just fucking each other off basically. And that, ladies and gentlemen, is DDD.