Video details

Carving Microservices out of the Monolith with Domain Storytelling - Henning Schwentner


For a microservices architecture to be succesful it is crucial to have the right boundaries between the microservices. But where are the right boundaries? I would like to present a tool that helps us answer this question. Domain Storytelling ( means that we let our users tell us stories about their work. While listening, we record the stories using a pictographic language. The experts can immediately see if we understand their story. After very few stories, we understand the language of our users and find different areas of the domain. Each of these areas (called a subdomain) is a good candicate to become a microservice in our architecture. In this talk I show how to find subdomains and which heuristics can help us.
Check out more of our featured speakers and talks at


After all. He says, well, we have a solution for your problem. And that solution is called auto leasing or car leasing. And that means you don't have to buy the car yourself. We are going to buy the the car for you, and then we will rent it to you, leave it to you for a monthly payment for an installment. So we have the car manufacturer, we have the car manufacturer, we have the end customer, Bob in our example. And Bob doesn't have to buy the car from the manufacturer directly. But now we get this leasing company in the middle and the leasing company will buy the car from the manufacturer and then lease it to the end customer for a monthly rate. And, of course, this leasing company has a big monolithic software system in place to support this process. And the software is called monoles, obviously the right name for such kind of software. When we have this monolithic software, that's okay. But let's put this monolith for a moment aside and let's think about the leasing thing. Let's think about the domain. Let's think about our business, what is happening here? So let's look more closely at what is happening when we're leasing a car. So we start with our customer, Bob, and the customer tells his wish for a car to a salesperson. And the salesperson then will calculate an installment for a contract for that car installment. That's the name for the monthly payment that the customer is going to make, the money they have to pay every month. And let's assume the customer is okay with that contract and with that installment says, well, I can't afford that installment. Then the customer will sign the contract and give it to the salesperson. And then the salesperson will pass on that contract to a risk manager, a risk manager. What's that risk manager? They will check the risk, and that is they will check the credit rating of the customer. Is it good or is it bad? And it will calculate the resale value of the car. That's the risk of the car, while the credit rating is the risk of the customer. And if both the credit rating is good and the resale value is high, then they will vote the contract. The risk manager votes the contract. To vote means that the risk manager says, yes, we want to do this contract or no, the risk is too high. We can't do this contract. Let's assume the risk manager says yes. They vote positively, then the salesperson can give the car over to the customer. So what you see here that's your first domain story didn't hurt that much, right? So what did we just do? We told the story, or in the real world, we would let the domain experts, the users, tell their story. And while they are telling their story, we repeat the story. We draw a diagram of the story to show our users, our customers, what we have understood from what they have told us and what you might know. Understanding, misunderstanding each other, that's something that developers and users, we're pretty good at that. Misunderstanding each other. And misunderstanding, of course, is a big problem for software systems. So we have to get rid of misunderstandings. We have to understand each other. And this is a tool for helping, understanding each other because we repeat what we have understood. And then our users can say, you understood me right or no, you didn't understand me right. We have to do this a bit different. Okay, so let's look more closely onto this domain storytelling. Explain. What did we just do? So first of all, it's important to know that domain storytelling is one tool out of a family of tools. And this family is called collaborative modeling. Collaborative modeling. It's a term that comes out of the DDD community, domain driven design community. And collaborative modeling means we are not modeling alone. We developers are not modeling alone. Okay, this is not what I wanted to happen. Okay, so my clicker is still in only being shared over Zoom mode. Sorry about that. So we have the developer here. That's what I wanted to point out. And that's us. And the idea of collaborative modeling is that we don't want to be alone anymore. We don't want to model a loan, build the software alone in a dark seller or basement. But we want to do this together with our domain expert, together with our users. So we want to work too closely together. Collaboratively. That's why it's called collaborative modeling. And why modeling modeling? Because we have to understand the domain of our software, and then we're building a model in that domain, in our software. That domain model. Okay, so when we are together, developer user or developer domain expert, then what we are going to do is knowledge crunching. That's another term from the DDD world. The idea is we crunch on that domain knowledge that we learn from the users until we get the juice out. The essence. That's what we want to know. Not everything of the domain, but the essence of the domain knowledge. And there are different methods that can be used for this collaborative modeling. User story mapping is one that you might have heard of. Event storming is another one. And what we are looking on today is domain storytelling. User story mapping. Event storming, those are done with sticky notes. Domain storytelling that's done with stick figures and arrows. Okay. But it's not only about stick figures and arrows and icons. That's one part of the main storytelling, the pictographic language. But it's also about the workshop format. It's also about bringing people together. So what's fun about this method is bringing these two things together. So domain storytelling is pictographic language, plus a workshop format. And then you get the most use of all of it. Okay, let's start with the workshop format. What do we need for the workshop format for a right workshop to understand our domain experts is of course, we need our domain experts. So we need to bring together the right people. And as you can see here, of course, Chuck Norris is always the right people, but most of the time, well, he has to save the world or something so he can't make it for our meetings, which, of course is a pity. If Chuck can't make it, then we need two groups of people, the storytellers and the listeners. So the storytellers, those are telling the stories and the listeners, they hear this story and they try to understand that story. Typically the storytellers. Those are our users, our domain experts, the people that have the domain knowledge and the listeners, that's us, the developers. We learn something about the domain, but it's not as black or white, because when we bring together several users from different departments, like a salesperson and a risk manager, then they typically also will learn something from each other because we are looking at the whole process of the whole story and we will break down the knowledge silos as well. That's also idea. So we developers learn from the domain experts, but they will learn from each other. Also storytellers listeners. And then usually there's a third role. That's the moderator, some guy that leads through the session and that models, draws the picture on the wall. Moderator, modeler. Sometimes moderator and modeler. These robots are split up, too. Okay. And what are we doing then? We let the domain experts tell their story and why we then tell them their story because storytelling is something that's deeply rooted in human beings. Everybody is used to hear stories. All of us have probably heard fairy tales on the lab of our grandmother. Who knows? Hansel and Gretel, probably most of you. Yeah. Okay. So for those of you who don't, that's an old German fairy tale. And telling stories, that's something that our grandmothers are good in. Hearing stories. That's something that we all are good in. And we want to have a means to make communication easy between developers and domain experts. That's why we don't use some formal notation like UML or BPMN. Those are great tooths, too, but they are well suited for communication between developer and developer. We want to have a tool that's good for communication between developer and normal people. So developers and users and normal people users, they're not used to formal stuff like DPM and diagrams. So that's why we're using storytelling. And we are using this also for expectations management. So this is what's happening in many software projects, of course. So here you can see as the developer and that's our user and the user is thinking, wow, with this new solution, all my problems are going to be solved. I get this flying horse, and then I will be happy. And you know what they get in the end? Is typically something like this. So it's also about expectations, management. It's about bringing the ideas of the users and the developers together and bringing that on the same page. And the basic idea is pretty simple. We hear the words, we hear the sentences and when we hear those sentences, we draw them into the diagram. So when we hear the salesperson passes on the contract to the risk manager, then we draw the salesperson hands over the contract to the risk manager. And if you look closely, you can see there already has been a misunderstanding. So the salesperson does not hand over the contract, they pass on the contract. So when we are here and we have shown our user, this is what I have understood from what you have told me, then our user can say, no, you did get me wrong. Please change this hands over to passes on because hand over and pass on those two words. They mean different things for me in my domain. And that's what we want to learn about, right? We want to understand that domain, in this case the leasing domain, to build software for that domain, in this case, build software for leasing, not for anything else. So we have to be exact about the language here. So basic idea, we take the sentences that we hear and we draw them onto the diagram. That is what we call active listening. Active listening means not just like passive listening, like nodding yes, I hear what you say, but active listening means, I repeat what I have understood in my own words. For example, I say the same sentence in my own words. What I have understand. That's called rephrasing. Or you can do it by redrawing it on a diagram. That's what we're doing here. We're using concrete stories and we're not using abstract diagrams, as I told you, concrete stories because that's something that all humans can do. Formal or abstract processes. That something that people with formula, education, what programmers can do. Okay, that's about the workshop format. And now about the pictographic language, the pictures that we're painting, the diagrams that we're drawing. So we started with the first sentence. And what you can see here is we make a story out of it by drawing several sentences. So the story evolves why we hear it. So the customer tells the wish for the car to the salesperson is sentenced one, and then comes sentence two, and so on. And we make these diagrams out of very simple elements. And this pictographic language is very simple, deliberately very simple, because we want that it can easily be learned. We don't have to explain it or we can explain it in two or five minutes. So it's basically only two kinds of icons and one kind of arrow, and that's it. So the two kinds of icons are the actors, the stick figures, those are the people that are doing something in our stories. And the other kind of icons are the work objects, the things that our actors are working on, doing something with. And then we have the one kind of arrow that's our activity. And that is what the actor does with the work object. So it's actor activity, work object, one possibility of sentence or actor activity, work object, another actor, when they hand something over or when the two actors work together on some work object, then the arrow points in the same direction and so on. So different sentences, the different types of sentences are possible. And then we have another element, that's the sequence number. We have those in the picture to bring the time into the story so we can see what's happening after what. So actors, work objects, activities, that's basically it what we look in our leading example, the risk manager is an actor. The contract is a work object and votes that's an activity. What we can do now is use different icons for different kinds of work objects, of course. So we have the installment of the car, and there are different icons here to make the story easier to read. And the same is true also for the actors, of course. So most of our actors sorry, most of our actors are people like you can see here. But sometimes it's a group of people, or even it systems can be actors in such stories. And here's also it might make sense to put a head on their head or tie a tie around their neck if their bosses or something like that. So we can vary these icons, of course. And what you might have noticed that seems a bit awkward in the start, but it makes sense when you learn it is that the actors appear once and the work objects, they appear several times, even if it is the same work object. So you can see here we have the customer, our actor, and they fill out the contract in step four, and then in step five, they sign the contract and you can see this is, of course, the same contract, but we have two icons. We will see later why this makes sense to have several icons here. On the other hand, we want only one customer, only one person here to see the collaboration of the actors in our pictures. So it's easy to see when two people work together and when they are working all alone. Spoiler might help us with thinking about the monolith and splitting it up later. Okay, we're drawing all this stuff on a canvas. When we're doing this drawing on a whiteboard or on a blackboard or something or a piece of paper, then it usually makes sense to have one big space for drawing a story, putting the name on top, and having some space where we can put annotations and stuff like that. Okay, that's our picture of language, a canvas to draw on actors, work objects, activities. But what we're not having. You might have noticed that is conditions. There is no if else. There is no or, there is no switch case. And that's not because it was forgotten, but that was intentionally left out. And why is that? That is because conditionals, that's something that we technical people understand because it's part of programming, but that non technical people struggle with. And that's also not what storytelling is like. When you think about Hansel and Gretel, it's not like if the weather is good, Hans and Grate will go out into the forest and which catches them. Else if the weather is rainy, hence and Gretel stay at home and the big bad Wolf comes and eats them up. That's not how stories work. That's not how stories are told. And that's why we are using only or we're telling only one story in one picture and we're showing only one case, one scenario in one picture. That's why domain storytelling is also called a scenario based modeling method. Scenario based means we're modeling one scenario in one picture and that on the other hand means if we want to look at different scenarios, then we have to look at different stories. So typically one domain story doesn't come alone, but it comes in a group of other stories to see those different cases. Usually we start with the good case, the 80% case, and more of that. So leasing, how does it go when everything goes well and then we move on to the not so good cases. What happens if the risk is too high? What does the risk manager do then? When they reject the voting? What happens then? Maybe a new offer is made with a higher interest or whatever. So we model that in another picture. So we start with a good case and then go on to the special cases. And of course we will not model every possible case. We're modeling just enough cases to understand what we are doing. Remember, this is a method for communication between people. This is not something that we want to put into a compiler and get code out afterwards. So this is annotation for humans. So scenario based Modeling One Reason for Having More Than One Story Another reason for having several stories is the scope. Every domain story is in a scope. What does scope mean? Scope is made of out of several factors. One of the factors is granularity. Are we modeling cos grained or are we modeling fine grained? So are we looking from the birds eye perspective, only the broad strokes? Or are we modeling every detail? So we have cost grain domain stories and fine grained domain stories. Usually we start with cost grade domain stories and see, this is a task, a step that we want to look into more detail. And then we draw another diagram, another domain story for that story to see. This one step in its detailed substance granularity one scope factor, another is the point in time, are we looking at the process at how it is now, or are we looking at the process how it will be in the future when the new software system is there, or when the law has changed and the regulation is different? Or when we have optimized the process? So that also plays a role point in time. Second scope factor and the third scope factor is domain purity. So are we telling the pure domain story only stuff that our domain experts know and understand the paper process, or are we explaining the digitalized version of it? Are we using the computer where we polluting our idea of the domain with the solution stuff? So those are the three scope factors. And for us here in splitting monoliths, especially these cost grain domain stories are usually interesting because we want to know the whole process and know where to cut the boundaries into our process. And that will help us cut or carve out the pieces of the monolith as well. Okay, so the main storytelling can be done with different tools. So I've showed you some PowerPoint slides here that's not so well suited for the workshop situation, of course. So when you are in a workshop situation, then today the best tool to use is Egan. Io because that can be used on computers and you can use that remotely for everybody sitting in their home office situation. But you don't have to use a tool like that. In the old days when we were like this altogether, then just a whiteboard and some sticky notes in the market. That's fun too. And you can see here it makes sense to put the actors and the work objects on sticky notes because then you can move them around and the whiteboard is fun because then you can wipe things away and refactoring is easy. But you can also do it on a piece of paper which is more permanent. And when you have something like a digital blackboard or a digital whiteboard or what I also like is having a tablet with a stylist that's also since we only have 1 hour, I'm not going to talk about different modes because what I want to do with you in this time is a little exercise. So everybody please roll up their sleeves. You're going to be my storytellers here today and I want to showcase with you some domain story that we can model together. So then we can see how this feels, how this goes on. And we need a domain that we are our experts in. And I assume you all know how to travel by train. So let's imagine you travel to this conference to the NDC by train and I'm going to show a browser window for that. This is this Egan. Io modeling tool. Okay, so traveling by train to the NDC, how does that work? Who knows that? Sorry, check the schedule. Okay, who's checking the schedule? The traveler. Okay, so we get the first words here. The traveler checks the schedule or schedule or some bridge here. Okay. So step one, traveler checks schedule and then the traveler goes to the train station. Okay. And then buy a ticket. I hear from different sites. Sorry, I think my keyboard is not working anymore. So the traveler, sorry, goes to the train station and then buys a ticket. And then what's next? After buying a ticket, the onboarding of the train. Okay. Boards on. I'm not good on typing when people look at me. Okay, then the traveler has boarded on the train and then. Sorry, buy a coffee, buy a coffee. Okay, so the traveler buys a coffee. Who do they buy it from? From a machine. Okay, sorry, I don't have a good coffee icon here. There. You see why it's fun when you draw on your own and you can draw all the icons, the conductor shows up. Okay, thank you. So there's another actor here, the conductor, and they check the ticket of the traveler, right? Yeah. Checks ticket off traveler destination. It's a bit like in the online situation. Then they would say, you have to unmute yourself. But I'm the only one with the mic here. So the traveler arrives at the destination and then is that it? Or do we need something else? The train travels. Okay, who does that? Who is the actor there for the train? Okay, so there's one more actor, the train driver who drives the train for the traveler. Can you see the numbers here? So this is now step eight. That's probably too late, right? This should be done before the coffee. Right? So this should be step five. Okay, so I'm going to replay this with this replay mode. So we have our traveler who checks the schedule and then goes to the train station. The traveler buys a ticket boards on the train. The train driver drives the train for the traveler while the traveler will buy a coffee from the coffee machine. And then the conductor checks the ticket of the traveler and the traveler arrives at the destination. Okay, so what we've seen is apparently a course grained story. And also it's a pure story because there are no it systems in it and cos grain because we're not looking at all the details. We're looking from a broad perspective. So, for example, we're just saying the traveler buys a ticket, but of course, buying a ticket. There's 20 substepts in that step again. So probably one of the next steps would be to say, well, let's look at this ticket buying and look at that in detail. And also let's look on how this process can go bad. So what happens when the traveler arrives at the platform but the train isn't there because it's late? The 80% case in Germany, the country where I live. Okay, so you see, we just modeled another domain story from another domain. And now the session is about microservices and monitors and so on. And we didn't talk about monitors so much until now. So we are going to do that now. So what are we using these domain stories for? And how can they help us split the monolith? So first of all, they can help us learn the language, and that is discover or rediscover the domain, understand again what is happening in the real world. Put aside the monolith, the software that is in our minds, and that pollutes our thinking about the domain. So that's why we want to focus on what's really happening, understanding. Why are we doing all this? We're not doing this because we want to use the monolith or because we want to use software at all. You're doing this because we want to lease cars in this case. And then in the main stories, we can find words that we don't understand, like installment. And then the main experts can tell them what this means. For example, here the monthly payment of the customer. And then we can use that to move on to user stories. I'm going to jump over that now because I want to look at how can we use those domain stories to design a program? How do we use that for building a piece of software? When we're talking about domain stories and design of software, then Domain Driven design is, of course, not far. And domain Driven design has this idea of we want to root our software deeply into the domain. We want that our software grows out of the domain, then it can blossom in green like we can see. So we don't want to build the software in outer space. We want to build it in deep contact with our domain. And that means we build the software as a mirror or as a reflection of the domain, of the real world, of what our users are doing, of what our users are working with. So we are looking, for example, for these work objects, for the things that our domain experts, our users are working on, and we take them and we build a model out of them in the software. And domain stories can help us here because we find these work objects and domain stories, and we also find what's happening there. And both things are interesting. What are the things? What are the work objects and what's happening to them? What are we doing with them? That is the work objects and the activities. And there's two basic roots of thump here when it comes to software construction. And that is take the work objects and make objects in the software out of them, make classes out of them. So work object becomes class and take activities and make methods out of those. So here in this example, when we look at our domain store, you see, well, the contract that is apparently a central concept in our leasing. So let's take this contract and build a class out of that. So the customer signs the contract. The risk manager votes the contract. We build a class contract. And then step two, we look at the activities and make behavior of the system out of it. So we take the signing. Step three here customer signs the contract and make a method sign. Out of that, we take the risk manager votes the contract and make a method vote. Out of that, two rules of thump. Work objects become classes, activities become methods. And what we end up with. You want to take a picture? No. Okay. And what we end up with is what we call domain model with rich domain behavior. Behavior. Because we're not only having a class that has a name from the domain, even the methods have names from the domain. And that's awesome. That's the wet dream of the object oriented programmer. Right? We want to have classes with real behavior. And this is easy to translate into Java or whatever object oriented language we're working on. Sorry for showing a Javaslide on a net conference. I told you, Java is good for building monolithic, right? This is the idea of we can even do it in PHP. Sorry. This is more or less the basic idea of object orientation. This is why it's called object orientation, because we take the objects out of the real world and make objects in the software out of them. Fun fact, you don't need to use an object oriented language for that. You can, for example, use F sharp or other functional languages to use that as well. So an F sharp or other functional languages, you would say, I take a work object and make a type out of it, and I take the activities and make a function out of those. But the idea is basically the same. If you want to look into code, there leasing Ninja. Io, that's a case study where I implement this leasing thing in different languages to see how this works out. But here we want to see how we can lose it for splitting the monolith. And yeah, we already started with building the monolith because we did a good thing. We built our behavioral rich domain model. We have this class with domain specific methods. But this is not enough. Because what will happen when we go deeper into our domain? We will add functionality and functionality. And functionality. So we won't only sign our contract, only vote our contract. But we will also extend it. We will terminate it, we will sell it to a refinancer, and you see our class. Our domain model is growing. The one big model is growing what we get there. So the one big model. Well, is that something that is bad? Isn't that what we are supposed to do? Model the domain in every detail? Well, okay, Boomer. That is how it used to be done in the old days. But today I have to tell you, be careful, be aware of this one big model. The truth that I have to tell you, the sad truth that I have to tell you is that the reality is you don't have the one big model, but it's more like a mix of the mental models of the several people that are working on these softwares. And what you end up with is the big ball of mud. It's the monolith, or in one word, the horror. That's what we get out of it. And I want to quote the late Carlaga Salt at this opportunity because he said whoever uses a canonical model has lost control over his life. And the canonical model, that's the one big model for the whole system. Maybe you said something about sweatpants, but he was right. Anyway, the one big model is problematic because we have a big complexity in the domain and all these interesting domains. We have big complexity and we have to get that complexity into our brain. And that complexity is too big to be understood as a whole. And that leads to errors. And that's why the monolith and the big ball of mud are pain. They get these Waker mold issues out of them. So when I do a change, Ducks appear everywhere, anywhere in the system. This is a problem. We don't want this big monolithic system that causes pain. So what do we do? I was talking about models and saying the one big model is the problem. So how about moving away from the one big model to having not one model, but to have several models and to go right from the start and ask ourselves, well, this domain that we're looking at, can we split that up into subdomains? Can't we find boundaries in a process like this? And I would say in this example, we have the steps one, two, three, and eight, which belong somehow together and form what we would call a sub domain. The domain is the whole area of the world that we're building software for, and the subdomain is a part of that. And this subdomain might be called sales. And then we have another part here for the steps five, six, and seven, which form a subdomain on their own. And this might be called risk assessment. So we're looking into the domain and we are asking the question, what are the subdomains? Where are the boundaries in our domains? That's something that we analyze. That's something that we find something that's already there and we use it to build something new. We're using it for construction because we then say, hey, we're not building the monolithic software anymore. We're building a software out of modules. We're not building monoles anymore. We're building module leads, and that's built out of one module sales and one module risk assessment. We're building different parts of software for that. And these softwares can be smaller and thus easier to maintain, less error prone. Also, it's easier to work on them with different teams. So that means for our models here, we're not building the one big contract model anymore. We're not building one class contract with sign and vault. We are building two classes that have the same name, two classes that are called contract. One class with the sign logic, one class with the voting logic. So we're taking the same thing from the real world. There's one piece of paper, our leasing contract, and we're not putting into one model, one big model here, but we're modeling the same thing in different models. So one class contract with the signing logic, one piece of software, one model with the voting logic, and we're drawing boundaries around them. Those are the boundaries that we just found in our Domain Stories. And that's what we're going to do with the monolith. We're analyzing the domain that the monolith was built for, and we're trying to find these boundaries here, these subdomains. And for every subdomain, we carve out one module of the monolith, and we call this module that we carve out a bounded context that's DDD speak for this bounded context because there's a boundary around and context because that's the context of the model. If you have never heard this idea of having several models of the same thing before, then this looks scary to you. And that's okay, isn't it? The opposite of what we have learned. Maybe you have to think about that and to read about these DDD stuff, we don't have the time for that today. Assuming that you have accomplished that idea that we're building several models, then the idea is that we take the whole cow, the whole domain and cut it into pieces, and then we are splitting our models. How can we implement multiple models in Net? We can start with just having several DoLS which have an inside and an outside, an implementation and an interface. And maybe we can then move on to microservices if we want to. So how do we use it then to cut the model to carve out such things that we found such bounded context subdomains out of it? How can we split the money? I brought you the secret recipe here, and it's basically just three steps that we need. The first step I showed you that is put them on site aside and ask the question, how should it be? Analyze the domain, for example, with Domain Stories to understand what is the context map, the idealized context map where we want to go. Then second, ask the question, how bad is it? So analyze your big ball of mud to see where you are. So see where you want to go, see where you are, and then you know in which direction you have to go. That helps when starting. And then, of course, how can we move DS to the ideal? There's this magic arrow how to come from the monolith to the big ball of mud. And there are several patterns that can help us. We don't have the time to go too deeply into that. But one of them, of course, is the Strangler fig application. So this idea that we strangle our old application while it's still in production and while we have a new system that is growing around it like this famous Strangler fig plant in the jungle that grows around a host tree and eventually strangles this host tree, and then only the fig remains. And we want to do that with a software as well. So here in this case, for example, we start with this big bottle of mud monolith software. And we see we have this one big model with sign and vote. And what we want to do is a step wise, a baby steps, small steps approach to taking them on Earth. So we start maybe with a copy of the stuff that we have here in the big bowl of mud, and then we throw everything out that we need in the sales part, and then we're building the first bounded context or maybe even micro service that is standing at the side of this monitor. And what's important at this point in time, we have still the big ball of mud in production and we have a new part of the system also in production. And there will be some bad things done to the big bottle of mud. Usually that will get uglier, that will get even uglier, because we have to take some detours to sorry, we have to take some I'm not going to do this again. We have to do some detours because here in the big ball of mud there's all this monolithic big database and we have to see, well, this sign method, when that is called, that has to call this method over here. And things have to happen. But step by step we can carve out things here. And then the next step would be to carve out the risk assessment and throw out anything we don't need there. And maybe eventually you can get rid of the big ball of mud. Or truth be told, maybe not. So this is also something that I see happen in many organizations, which might be also okay because we have at least parts in the system where it is better than before. And if we get out the core domains, the most important stuff out of the monolith, then that may help a lot. And maybe on the supporting and generic stuff stays here in the big part of not okay. Of course, this is a bit like when you only have 1 hour to talk about such a topic, like in this joke here, how to draw an owl. Two steps. Step one, draw two circles. Step two, draw the rest of the damn owl. I would advise you, don't do it alone. Take somebody with you who has experience with putting them on it. I know someone so you could get in contact with me. Okay. And with that I come to a conclusion. So if you're interested in more on the staff splitting monolith, but also domain storytelling in general, then domain, that's the official website where you can find more info. Also, I'm proud that Stefan and I wrote a book that was just published. You can get that on as well. Buy it now and then. You're among the first people in the world that have it and leasing Ninja. Io, I told you that's something that you might want to look at if you want to see some code. And with that the engine is near. If you want to have some swag. I finally brought some swag but last year I only could show this picture in the talks on Zoom. So if you want to have a sticker, just come to me after the talk and of course don't forget to give feedback. Preferably of course the green stickies. And with that thank you, happy and you.