Hello everyone, today I have a very special guest here, Dr. Alistair Coburn. And should I call you Dr. Alistair Coburn? I like Alistair, thank you. Everybody calls me Alistair since forever, I like that the best. Okay, so Alistair, first of all I'd like to say thank you very much for your presence here. I'm pretty sure that everybody is going to learn a lot with you today. But before we start going through the technical stuff, I'd like to ask a question. Where is this crazy hair? Good for you. This is for anybody who doesn't know, this is the picture. And notice also that my job title is Project Witch Doctor, so it's actually worth asking about this. The crazy hair was because I needed a picture for my business card. So I went to a photographer and my hair was no longer than today, no particularly worse than today. And it looked awful. But he was showing me what he could do with Photoshop and there's a, he dragged my frowny face, I call that my Japanese face. You see my lips go down into my jaw. So he was showing me he could make my frown bigger by dragging it down. And then he pushes a button. It's called pinch. And it makes the center smaller and the outside bigger. So he did that. And then the guy who helped me with my Japanese script for my name, in Japan they call me koban. And it's a word word and so I said that to the guy I said hey I'll send you my business card and he says only if it has the funny hair so I had to print business cards to send to the guy in Japan and then I had two sets of business cards my ordinary picture and the funny picture and nobody took the ordinary picture except to their boss. So they would take one for themselves that had the funny hair and one for their boss that had the straight hair. Then after a while, nobody took the straight hair anymore. So I just stopped printing them. And so that. And since this is an MBA class, it's also important to know why does it say Project Witch Doctor? And the reason for that is because I'm very human-centric, people-centric, communication-centric in my projects. And big bosses in organizations don't understand this. Literally, they don't understand. Like if I describe what I do to people not in the field, and I say, I just make sure there's good communication within the project and with the sponsors and the buyers and the users, and things go better, as a consequence, anybody would just go, yes, of course. But I had just saved a project in Norway in this particular moment, and the boss asked me, why did your project succeed and all the other projects failed? But they had a bunch of failed projects, right? And I told him about, well, I did this thing with the communication. And he said more or less like, no, hablo whatever you just said. He really did not understand the concept of just improving the quality of communication. So to him, what I did was mysterious. It was like voodoo. You know, in Spanish they say brujo de proyectos. So I'm a brujo, right? I'm a voodoo guy. I come in with my chickens and my rum and I get everybody drunk and we watch the chicken dance. You know, to these people it makes no sense what I do. And so I decided that that was going to be my official job title, Os Brujo de Proyectos. Muy bien. Okay, so that's an explanation. Ask a question and you're going to get an answer. Good, good. So, Alistair, we're going to start talking about hexagonal architecture. Okay. So I think that's the main thing today here. And I have a question here. So just to keep everybody on the same page, what is the hexagonal architecture? It's got nothing to do with hexagons. But I'll show you. How about I walk through the pictures that I've got and then that'll set up some vocabulary so you can ask a follow-on question. Is that okay? Perfect. Perfect. I'll share my screen and walk through about 10 pictures that I have. Go ahead. Okay. Entire screen. Let's go. Boom. You can see this? Yes. I'm going to be hidden, okay? But I'm going to show up when I need, okay? Let's go. All right. So we're going to start with a model. This is sort of the newest explanation I've got, and it's nice if we anchor in ordinary human behavior and ordinary society. Things make kind of a sense that way, right? So what I've got here is a dinner boat. Let's say it's in a river and the people, you know, have to take a boat to go out and eat on the dinner. So if you look at the top left, we have the guests coming and maybe they come by car, they come by bus, they come by train, they come by bicycle, they walk, you know, whatever they do. But they go over to this dock that you see, this little place here is a dock. And then they get on a boat. And the boat, you know, goes over to the dinner boat. This is what you would expect if you're going to go have dinner on a dinner boat. And there's a nice doorway and a red carpet. And you know, people welcome you and they hand you a drink. And that's what it's like to be a guest. you go to that particular dock. But now the people who are running the dinner boat, they don't want their staff coming in here and mingling with the guests. So there's a separate dock and you see that on the bottom left and the staff, they come however they come with cars or bicycles or, you know, whatever, and they get on a different boat and they go into a different doorway called, you know, staff. It's for people who are doing serving, right? We see this all the time in a restaurant. You'll see the front door for the guests and the back door, and it'll say service entrance, you know, for whatever. Now, still the boat has to get supplies. So let's say on the other bank of the river, we have that the suppliers could come and they come in with their trucks and their vans and whatever and they have, you know, whatever the food is, the drinks, whatever is needed. And they take another boat, kind of a boat, and they have a different doorway that come in on the dinner boat so that they can do that. And just for the sake of argument, let's say that you've got to get rid of the trash. And so you've got another dock and you take out, you have another little shuttle boat, right? And it goes to a different dock. So we've got four docks here and we would tag them with their purpose. So we could say for guests, that's a noun, but what we like to do is to say what its purpose is, what its intention is. So we say, well, this one is for enjoying dinner. If you're coming here for enjoying dinner, use this dock. Now, for serving, if you're coming here for serving, then use this dock. For reloading supplies, use this dock. And for removing trash, we'll use this dock, right? So the dinner boat has got these four docks, if you will, and four purposes where people will need to come in and do something on the dinner boat. So dinner boat doesn't just have one entry. It's actually got four doorways and four docks. And I've happened to put two on the left and two on the right because it'll match computer architecture. So that's our model. It's very normal. It's not a surprise. What we're going to now look at is how to put that into software. Okay, now I'm going to shift to an old PowerPoint presentation I found that's got a couple of things. This is from 2009, I noticed, when I was talking about this. And normally when people talk about applications or systems, they put the user at the top and the disk on the bottom, or they put the user on the left and the disk on the right. And that's kind of normal. But it's missing something that's important to me, which is the disk is outside of the application and the user is outside of the application. The symmetry is not a left-right one. The symmetry is an inside-outside symmetry. I really wish to make it that the database is outside the application and the user is outside the application. Most people, when they implement them, they get them all connected in, and you get this mess that the GUI has got some business logic in it, and the business logic knows too much about the database. And now we've got a problem, which is you can't really regression test the business logic without the GUI because the GUI contains business logic. You can't make a batch program. You can't hook it to another program. You can't make a microservices. The database breaks or you change the database. You can't isolate the app. There's just a bunch of bad things that happen over time. bunch of bad things that happen over time. So what we want to do is just put everything outside the application. This is a hexagonal architecture. Okay, why a hexagon? Well, because I needed to get away from a rectangle, right? This is rectangle. Rectangles look like this, and rectangles cause us problems because people do that, right? So I needed a shape that was not a rectangle. And also, it turns out that you have quite a lot of ports. Three, four, five ports is pretty normal. So I needed an easy to draw shape that would let me have, well, three, four, five ports without any trouble. So hexagon. The hexagon doesn't mean anything, but it's kind of nice. The little facets give us those exact same ports like we had in the river, right? For enjoying dinner, for serving free regular supplies, for moving trash, that would be exactly four ports. So that's where the hexagon. and the domain unlike clean architecture unlike onion architecture i don't care how you organize the inside you can use domain driven design clean you can use layers it's not my business so this already makes it different than clean and layered and onion architecture, right? All I care about is you put those ports there. Literally, all I care about is you put those ports there. That's it. It's all I care about. And then you use those ports to talk to the outside world, and we get that separation that I was after. I'm going to develop this a little bit. So we've got these adapters. And it's very important. The adapters are outside the application. Everything is outside the application. Except for the application itself. The business logic. The domain language. All the domain stuff. Okay. So this is why it's called ports and adapters. We have ports. The ports all capture an intention, like for enjoying dinner. And we like using these phrases for doing something, for accomplishing something, for some purpose. It's a way of naming these ports that allows us to substitute different adapters, different technologies, different databases, different everything. So we keep this for doing something intention as the name. And just to give you an example of a fairly complicated system, this one had four ports, but it was a weather warning system. And the main input port, at least originally, was a wire feed from the Weather Bureau that would announce, you know, tornadoes, high winds, floods, rain, snow, everything. And the main output was, at that time, in the 90s, were these analog answering machines, literally. Were these analog answering machines, literally? And then, of course, there had to be a port for updating, you know, the user base and making changes to certain things in the database. And that would be our administration stuff. And then we'd have to have a database, you know, for the customer data, you know, how people wanted to be notified. And so that's the application. Now, the reason that this architecture was so important was because over time, he stopped using a wire feed and started using an HTTP, a web-based feed. And his subscribers stopped using an analog answering machine, and they wanted to be notified on their pager. And then they wanted to be notified by email. And then they wanted to be notified by HTTP. And then they wanted to be notified by whatever, right? And so what happened was that the number of combinations and permutations of his system was getting terrible, unwieldy, unmaintainable. Now if there was even the tiniest amount of leakage of his business logic into the GUI or the database, he would be absolutely unable to update his system to keep up with all the changes in technology. So this architecture was absolutely essential for him to absolutely harden the boundary around his application. So that's the hexagon, the ports, the adapters, and so on. What I'm going to do now is shift to the newest way I have of talking about it that's very UML, very computer-oriented way of doing it. I'll draw a hexagon. I mean, not draw a hexagon. I'll draw a rectangle again and all that stuff. But just before I leave, a port is a reason or intention for a conversation. or intention for a conversation. You would have phrases like for calculating prices, for setting up the system, for getting tax rates, for notifying subscribers, for controlling dispensers, and so on. You would expect to have multiple technologies attached to each port. You'd expect to have multiple function calls attached to each port. And the problem with this naming convention is that it is not utilized by the compiler. There is no type system that checks that you did the right, you know, verb phrase, that it's meaningful. And so this means that people typically don't do it. People typically don't do anything that's not enforced by the compiler. This is a very human to human type of a naming, and this is the thing that people let go of first. But okay, this is my preference. So now I'm going to say all the same thing, but I never knew this existed, honestly, until about maybe six or eight months ago, that UML has a thing they call a component, and the component has a thing it calls a provided interface and optionally a required interface. So there's the application. It's a rectangle, you know, old style. We've got a rectangle. And there's our application, and it only uses its own language with any external collaborators. And that's the weird part right there. In UML, the provided interface is shown with a solid ball hanging off of whatever side you hang it off of. And that solid ball means that that's the API that the application publishes. It says if you want to use this application, you have to use these function calls in this api right so the calling object has to use this vocabulary and in uml you use a dashed arrow to show that the calling application is using this vocabulary so it uses relationship uml right the part that was a surprise for me, I didn't know existed, never heard of before, is that they have this kind of a C-shaped open connector, the socket they call it, and that says that the application insists on generating calls to its service providers using a specific vocabulary. The called object has to accept this vocabulary. That's a weird thing. And I struggled with that for a long time until I accepted. And it turns out when you do this, you have a component. You have a component that you can plug into other places. Let's take a look at that boat just for a moment. Where's my boat? That boat has a certain shape. You could sell the business, move the boat to a different place, different docks, different tugboats, different suppliers. That boat is self-contained because all of its interfaces on all sides are defined and self-contained. all of its interfaces on all sides are defined and self-contained. This is a component like we ordinarily understand the word component. It's very ordinary. It's just we're not maybe practiced at it. So the application now, if I leave the hexagon aside, now I'm going to show you this part right here on Moe come on boy I can do this the application there in yellow is a component it's a component it defines the left side in the right side and you can cut it out and you can just reinstantiate it somewhere else and just hook it up okay that's a component in your mouth here we go now so now if we look at the original three-layer architecture, there's the human. They go to the UI. The UI knows the details of how to present information, collect user intentions. The UI, because you write the UI, knows how to use the application. There's that dashed arrow to the solid ball. The application knows the business rules, how to enforce them, and the business model, how to use the application there's that dashed arrow to the solid ball the application knows the business rules how to enforce them and the business model how to use and update it and then the application the stuff that you guys write has to know the interface of the repository and so the repository publishes an interface that solid ball the application has to match it and that's the dashed arrow. This is where the trouble comes in, is because the application knows too much about the repository. What we do then is we inject one more layer module thing between the application and the repository. And the repository, this adapter is written by you because it accepts on the left side the language that the application insists on talking in. And it will generate the language that the repository insists on listening to. So that's this adapter. Now we get one on both sides, because in fact, the screen, you know, when you get a screen framework, a GUI framework, it knows stuff about how to present information and collect user movements. It doesn't know anything about the domain language of your application. So in fact, you write the GUI mapper, you write the code that converts user movements to domain requests. And you write the repository adapter that takes the application language, the required interface, and maps that to the repository. And I think, yeah. So here's, when you put a tester on there, one of the good things here is this. This is a generic picture. So you've got your generic driver. It could be a test framework. It could be a UI. It could be anything, whatever that is, HTTP, microservices, REST interfaces. Who cares? It will call or use the provided interface of the application. It will declare its required interfaces. Then you can choose to plug in, and that line means either or. You can put in a test double and test your application, or you can put an adapter to an external system. You can switch them at build time. You can switch them at runtime, whatever you like. Now we've solved those problems we had before. Now because the application is a component, we can put tests all around it. If anybody leaks some business logic into the UI, we'll catch it through the tests. If they have too much dependency on a database, we'll catch it, it'll be in the tests. You can stick in tests, you can replace different external technologies, et cetera, et cetera, et cetera. So problem is solved. I think that's the end of everything that I would show. So I will stop sharing now and go back to the Q&A. Okay, perfect. And I did like this translation. Okay, perfect. And I did like this translation. When we work with the domain language, everything changes. So, this part with the repository, the repository that we can translate the language, I think means a lot. So let me ask you a question. In your opinion, what's the difference, or if it's the same thing in your opinion, the difference between a port and an interface? It's the same thing? Oh, you know, I'm really glad that you asked that because I wrestle with that one so hard, right? It's like, what is really the difference? Because I wrestle with that one so hard, right? It's like, what is really the difference? And so every function call is an interface, right? By definition. Cool. That doesn't get us very far. So is every function call a port? It's not interesting. The concept of a port, the very concept of a port, implies changing what you attach to it, right? Now, on the calling side, that's easy. Anybody can call it, and, like, you don't even notice. You don't even care. All the really interesting things to me, the difficult and mysterious part, is this required interface on the right side. And very few places, very few places do you have a defined interface that you will expect to maybe change something on the back to substitute. And here's the test for me, something on the back to substitute but and here's the here's the test for me and i'm glad you asked this do you have automated regression tests on that interface and most people will say no i have seen in the ddd community this idea of a bounded context and the adapter between and they claim that this is a hexagonal architecture and i go and i investigate and they never write tests at that boundary and i go if you didn never write tests at that boundary. And I go, if you didn't write tests, then you're not protecting that interface. You're not protecting the boundary. If you're not protecting the boundary, then it's not seriously a boundary. I like it. It's nice. But it's not really an interface to me if you haven't got automated regression tests on it. If you have regression tests, you have to be able to swap between the running system and your test system and your running system and your test system. And now you have an interface where you've got at least two swappable collaborators. The test suite, the test double, right? And the whatever, repository or the secondary actor. Now you're swapping them. Now you have what would legitimately be called a port. So for me, here's a strange thing. In the end, after much sort of debating and staring at my belly button and arguing, I concluded that the difference between an interface, any old interface, and the port is whether you have automated regression tests at that interface and can swap in your test suite or your running code. If not, it's an interface and it doesn't mean anything. If it is, you can call it a port. Okay, so that's my answer. Perfect. thing if it is you can call it a port okay so that's my answer perfect and when you're talking you stay perfect like I get some random answer and you say perfect how about I get it a 93 instead okay got it when you're talking about adapters we also have the Gengar 4, the adapter design pattern. What's the relation between the adapter pattern and these adapters that you are talking about? Because normally, when I want to create, for example, a connection to a database, I can create an adapter for MySQL and for the Postgres, and then I need to use the very same interface to be able to swap the database. So, using this pattern, this adapter has relation with this, or is more a kind of strategy design pattern I'm trying to go through a little more deeper you know in the code it's perfect and I see the discussion between Rodrigo and Gabriel and they're on this exact thing and my my collaborator in all of this these days is Juan Manuel Garrido de Paz in Spain and we debated this so many times. And I wrote a paper, the newest paper is called Component Plus Strategy. And I looked at the, so let's back up in time. In time, like 2003, when I finally started to decode this, 2004, 2005, I'd been working with it, but I hadn't decoded it. I saw two patterns in the literature. One was called pedestal, I think. I haven't been able to find it. And it was the basic ideas, a little bit of what I had. And then I went and saw the Gang of Four book, and I saw the adapter pattern. And I said, that's exactly it. So if you say it's exactly an adapter, then you're exactly right because it was by reading the adapter pattern that I was able to like finish unlocking how this thing works. So it's an adapter, right? Very clear. Then when I was reading about it, one of the things that's different I didn't show in these diagrams is if you're going to swap the test double and the production system, that means you have to have a variable in the application that says which it is, which one you're going to use. That happens to be the strategy pattern. Now, so I got into this and I said, okay, I could call this thing component plus adapter. But because of the, you have to, part of the configuration, the setting up, you have to pass in as a parameter, which one do you want? Do you want this database or this database or this technology or this test doubler? You have to pass it in. That's the strategy pattern right there. And then Juan was defending and saying, no, if you read the Gang of Four book, strategy is only for an algorithm and an adapter is for language. And I go, yeah, I don't care if they say it's for an algorithm. It's got the properties I'm after, which is this idea of sending in a different one and choosing either build time or initiation time or run time, which you want. So I'm going to call it a strategy. I'm going to share my screen one more time just to show this here in this last picture that I showed. Let's see. Taking my life in my hands. So there you see, and there's exactly the test double. The test double doesn't need an adapter. And this is another conversation that Juan and I went crazy over was, do you need an adapter? You don't have to have an adapter. Well, if you're writing the test double, the test database, you'll make it fit the required interface. You don't need an adapter. How do you draw this when you don't need an adapter? My God, we were going crazy. And then Juan drew this picture, and it solves all the problems. So for me, the test double is strictly a strategy because the test double is not an adapter. It doesn't need an adapter. The external database, the repository, needs an adapter. Your strategy is that you pass in an adapter thing. So I'll stop sharing now. And you guys can take a screen snapshot of that if the people want to. So there's a very subtle relationship, a difference between strategy and adapter as far as I see, which is strategy is sort of the more general and it says you're going to pass in a parameter and select it. And then sometimes you'll need, you don't need an adapter, you just use the object. And then sometimes what you'll pass in will be the adapter so you can swap it around so calling it now um component plus strategy instead of component plus adapter the architectures ports and adapters okay so those are the language and why we choose the language and you have to understand that now we're really, you know, debating how many angels dance on the head of a pin, etc. But there are people, you know, we're trying to keep the language appropriate. They're not mislabeled. It's a really good question. 93. Yeah. Is that perfect? Improvement possible. Yeah. Yeah, instead of three. Perfect. There's some improvement possible. Yeah. A question about when to use hexagonal architecture, because we know we have a lot of context when you are creating a software. Sometimes you have a very small software, you have to solve a very simple problem and sometimes you need to create a software that will last forever however the problem is every time when you start with this very innocent time software when you see one year after this creation, this tiny software is a kind of monster and you cannot control it anymore. So in your opinion, how can we balance the complexity that we have to apply to a software when we are creating because context changes. So I don't know if you get my question. Of course I do. a script to go over some files on my disk and suck out all the URLs out of all of them. This is a one-time program. It's not going to get maintained. It's going to get used in some way. I'm not going to write regression tests for it. I'm going to write it, run it, and forget about it. So don't need hexagonal architecture. For me, I would say, first of all, if there's a database, use it. If you're going to write regression tests on your system, use it. Total cost, when you get practiced at this, total cost to set this up is about 20 minutes. You're going to create an instance variable for each of your ports. You're going to pass in the parameter either at runtime as a method or at instantiation time. That's good, right? 20 minutes. So you're going to tell me that you're going to build a system with a database and a UI and you won't spend 20 minutes. Okay, 30 minutes to make it so you can test it and evolve it. So, yeah, if it's worth 30 minutes, if you're going to write tests. Now, I see in the conversation here something about other drivers, and I want to go back and show you, I'll show you in a moment that weather system again. I put on Twitter when I figured this out, I said, this is good. And I want to highlight that the test harness that drives the application is your second user. Like the human is the first user and your test drivers are your second user. The human is the first user and your test drivers are your second user. Ron Jeffries, from Extreme Programming, wrote back on Twitter and he said, no, the test harness is your first user. You're right. Now, if I'm making a system and I do this in my classes, workshops with companies, we will always set this up with the test as the first driver and a test double as the first secondary actor. And we'll write then the function. So we have a component. We define the UI. Test, no adapter. Test knows what it's doing. Test double, no adapter. Test driver knows what's doing. Test double, no adapter. Knows what you're doing. I always go, you know, give me the number zero from the database, whatever. Say hi. One plus one, two, I don't care. Right? Then I have it set up, and that takes about 20 minutes. So the tests are always the first drivers, and they don't need an adapter particularly. Right? So good, good. Okay. the first drivers, and they don't need an adapter particularly, right? So good, good. Okay. And do you see any disadvantage by using hexagonal or some similar architecture or design like onion clean arc, in your opinion? People say it's complex, and I've been trying to figure out where the complexity lies because for me it's one instance variable and a parameter in the constructor method. How hard can that be? It turns out where the complexity is, is in your file system because you've got all these folders with all your code. And you have to define, set up a folder that says this is the inside. This is, you know, all the functions that are legitimately called. You have to set up another folder that says here's all the outside stuff. And in there is going to be all the all the driver driving actors and adapters and there's another folder called all the driven actors and adapters and then you set up the ports and especially if you're using like java where you've got to declare interfaces and you have to declare all the damn interfaces on both sides the required and the provided and you go like typey typey so that's where the time that that's where the complexity is, right? So there is a certain amount. I mean, there's extra typing to be done. That's why it's a half an hour maybe instead of five minutes. But if this thing is going to be used for more than a year, you know, that 30 minutes is covered. So, yeah. more than a year, you know, that 30 minutes is covered. So, yeah. And you said about folders and so on. We have one thing that we cannot ignore anymore. Frameworks. We have Spring, Laravel, Django, Rails, everything. And normally, these frameworks are very opinionative they they kind of create a structure that if you not follow sometimes this is a kind of complex you work with them and yep yep no perfect perfect question and and i think the two examples are spring and rails as far as i know spring makes your life easy uh for wiring up the you know configuring it as far as I know, Spring makes your life easy for wiring up there, configuring it. As far as I know, it doesn't get in your way. Rails and many of these kinds of things that do direct to database, they own that database interface. It is virtually impossible to put that right-hand side required interface with your test cases in there. right-hand side required interface with your test cases in there. So, yeah, back in the 90s, I was visiting with a group of people at the time. I think it was called Delphi was the framework, and it was screen-to-database, screen-to-database. And I was trying to get these guys to do some sort of domain-driven design. Smart guys, excellent programmers. And they said, Alistair, I'm sorry. It'll cost us like five times the work. We'll have to tear apart the framework to do the domain objects. This thing is built screen-to-database. And I said, okay. If it's screen-to-database, you live with it, right? That's the benefit you're getting. And you won't do the domain-driven design. And you won't use hexagonal architecture. Then you'll go screen-to-database. And when technology changes and you have to get rid of it, you throw the system away and you start over. And that's part of the technology choice. So when you say when would you not use it rails is the perfect example I think you're not going to use hexagonal architecture with with rails thank you good question hey I'm looking at the time we have about five more minutes so pick your next question sure what is elephant carpaccio exercise? I love you. Good question. Good question. So people, let me just see. So sometime in the 2000s, I was with a group of agilists, met every month, and I said, how many of you people know how to slice the requirements of the system down to something you could do in like an hour or two? And only three people out of 20 knew how to do it. And I said, wow. And this is an advanced group of people. people. That means, generally speaking in the world, people don't know how to split an application or a set of requirements into tinier and tinier pieces that are all end-user visible improvements in the system. And so I created this exercise, which is, what do I do? What's my exercise? I said, oh, yeah, create the price of an order. There are certain discounts and there are certain taxes. Very easy. Take quantity, price, look it up in a compute tab, look it up in a discount table, take a discount, look it up in the tax table, add the tax, boom, right, done. Tiny. But try to do it in 15 to 20 user demonstrable increments. People don't know how to do that. And so when I watch the people that I really admire as programmers, they really work in like 20 minute segments, 5, 10, 20 minutes, and after like a half an hour, 40 minutes, if they haven't checked in their code, you know, if they haven't pushed it, they get really fidgety, right? They write a little test, and I learned how to do this somewhere along the line. I can, for almost any system, I can figure out how to make end-user visible difference in anywhere between like five and 15 lines of code. And that needs to be taught. It's a skill, skills development. So, you know, you have a big problem, it's an elephant. Carpaccio is a thinly sliced meat. And so I call it elephant carpaccio, teaching people how to make really thin slices out of a big problem I teach it to business people banking executives programmers everybody has to learn this cool perfect now I can say perfect Alistair again thank you very much for your participation. I thought that I knew a lot about hexagonal architecture, but with those slides, it was a kind of surprise, these translations and the way that you showed, it was the first time that I saw. So thank you very much. We really appreciate your presence here. And I do hope that we can do some talks and we can get together one day. So thank you very much. Well, thank you for all of you.