Crafting Great APIs with Domain-Driven Design by Fabrizio Lazzaretti @ Spring I/O 2026

In this talk, Fabrice Lotterie explores effective collaboration methods for API design by bridging the gap between business and IT. He emphasizes the importance of prioritizing business capabilities and utilizing techniques like domain storytelling and event storming to create a shared understanding. The speaker discusses the visual glossary as a tool to ensure a common interpretation of terms, enhancing communication during the API design process. By integrating methodologies that include both qualitative and quantitative analysis, Lotterie outlines a step-by-step approach to defining APIs, ensuring that developers and business stakeholders can work together efficiently towards high-quality API specifications.

[music] >> I'm Fabrice Lotterie. I'm a managing consultant at Wavestone. Mainly architect in different industries helping developers and team excel and go to new technologies and microservices with great APIs as integration in between. Normally I'm doing that talk together with great Junker. We also wrote the book together with the same name. Unfortunately, she wasn't able to join us today. But she's also an architect at Concentric and

she's also doing a lot of domain driven design. She has a lot of expertise there. Wrote already three books on the topic. Yeah. And this is what we want to look at today, right? How much can you read? What do you think how great is it to look at this? It's it's not even visible where where because of of the density of the pixels here on the

board. How do you think we can do such an API? It's a good API. It's the Slack real-time messaging API. How can we in collaboration work on API specification like that, right? It's really hard. Doing this in a workshop format is not simple and maybe you tried it. I almost always failed and that's what we want to look at today. How can we do APIs that at

the end are good in collaboration without showing this on a whiteboard? So, right? The problem that we normally are facing is on one side we have business. They they don't like YAML. They normally if if you show to business people YAML, they know no I don't code. It's not coding but still, right? It's it's hard there to get the connection and therefore we we search for something

on the higher level that we can discuss together and that faces and really don't do that gap between what business wants and the And also just with developer rounds, it's sometimes hard, right, on a YAML because on one hand they will look at the syntax error. If the IDE says it's red because we did a a small error. >> [laughter] >> They normally don't like that, right?

Then then you're again on that level and not on hey, is the API endpoint correctly designed? On the other side, you have then have tabs or spaces. Is it two tabs or four spaces and all that stuff and we want to abstract a little bit from that. And so for that, we want now to look into the approach we designed. It goes in a lot of methodologies

that already existed but that we found out with many [snorts] customers that it works great to really combine business and IT to get to great API that works for all. So, and that's shortly the process that we first go from top to bottom and then I dive into with an example that we look on how we can do this. So, the first step is create the capabilities.

So really start with a business model. What capabilities do we want? Which do we have? And then how do we prioritize them, right? There's a lot to do. Let's first prioritize what should we do first and what is the most value oriented thing we can do. So really first always what should we do and then okay, how do we do? And there we do normally domain storytelling.

This is a format where we can explain really shortly a story. So a business expert can explain a story and the other can see it also. Aha, okay, that is what the user and also maybe a employee will do in that business journey to come to the goal. And with that we have a first story. There we are first understand okay, that's really what we want to

do from the business side and then we can go one further step. And this is normally event storming what we do. And by Brondolini, Alberto Brondolini it was developed. It's a format where we can then really look at the business events that happens, that occurs on that. And there we can then go a little bit more into the detail and also come from happy cases more into

exceptions and there really go a little bit digging deeper and there really see then okay, where do we have components at the end? Where do we have really natural breaking points for microservices and so on. With that at the same time, we always do a visual glossary. Visual glossary just is a really simple glossary format to really that everybody knows if you would use that word, everybody

has the same meaning what is mean what means in that context. And we see a lot this is really helpful because at the beginning everybody says yeah, yeah, it's clear. But you will normally see everybody has a little bit a different interpretation. Afterwards, then we can do the context mapping and service cut. So this was already what I said, right? From the event storming we can then

do a service cut and really this is how we can separate this in modules or into microservices and really also separate teams naturally that they don't need to talk too much or that they have overlapping domains. And then after all these steps, we finally come into hey, let's now define an API. If all that's clear, let's do the API and you will see this is really simple.

If you do all the steps before, there the hard work is. Then this is almost like you will see a AI prompt and you almost have the API. And then of course, the implementation. And here it's not really one step after the other because it's simpler but it's really an iterative process, right? So always if you go down on these steps, if you see ah okay, sorry,

we misunderstood something. Maybe we need to go up, right? If you are here and say okay, this is the definition now ah okay, I don't got that. Maybe we have to say we have a new capability. Maybe we have the wrong capabilities prioritized. So, and with that, let's start with the first step. Getting to know what we want And this is normally a business process canvas or

a business pro sorry, business model canvas, not process. There is a typo process. Business model canvas is a really simple way to do a business model, right? A business model don't have need to be a 100 pages document saying how we do the business model with all forecasts but really shortly say what do we do, for who do we do it, with which value proposition. And this

doesn't need to be the whole business. If I'm in an enterprise, I will not do that with my team, right? But as a team, ask yourself what are you doing, for whom over which channel and so on. And this really helps to say hey, why we do it, right? Really first think about why should we do it? Which is the value we bring in? And in all

steps later, also the API definition and implementation, you can then always come back here. Hey, these are our key resources. Why do we talk now over that fully different entity, right? That doesn't matter. Let's let's focus on this. How do we get our revenue, right? So this is really what what we always want to come back. The value, why should we do it? And you see it's

now already filled out. We have one one example that goes now through all slides. This is a online library. It's a online library driven by donations, so a community online library that has of course books and it's online library that we will go through and at the end also design the APIs for them. So, if we now have that, then we can go into the capabilities. So,

which capabilities do we have, right? We are in now in an online library. So proposing a book that the online library shouldn't check into the inventory. Listen to a book, the audio book version. These will be now for our fictive online library the main visible value oriented capabilities. And so we will now take these capabilities that we first identify with and then we can do this. This

is a Wardley map. We can do a Wardley mapping and say for everything, hey, how is the evolution? Is it a commodity, a product, custom or genesis? And on the other side, is it visible or is it invisible for the end customer? And with that we can prioritize every capability and this helps because then we see here on top are really the ones that that are most

important for us. So we will focus there and normally you say then the best developers, the the best team, they should probably look at these capabilities work, right? And if it's here down like here, donation financed, this donation stuff, right? This is this is a commodity. This is not special. Here you can then say, do we need to develop that by ourselves or can we just buy

a product, right? There are like a lot of products that can handle donation. We will not be a better library if we have a better donation So, let's maybe buy a product, don't waste time there, and really look at the mobile web app because that should be a the thing that um changes us from the other libraries. now already the visual glossary is coming. I had it

afterwards before in the process, but you can really already start here and evolve over it. All right, you know normal glossaries. Um they have normally a lot of text and nobody reads it. That's why Stefan Turner came up with the idea of a In a visual glossary, you only write the terms down and you only do arrows in saying, how do they reflect, how do they compare

to other terms, right? For example, we have here a catalog entity entry and the title and this is now a contains relation. Then we have the reading list entry and that refers to a catalog entry, right? And with that, you can really shortly, everybody in the room knows, okay, these are the terms and this is the relation between that. And that helps a lot. So, for example,

I was in in an um insurance company and I was with the claims team and I asked, okay, what is a claim? They said, yeah, sure, we don't need to talk about that. But then you do something like that and say, okay, this is a customer, this is a claim, this is an incident. Is it a one-to-one relationship between a claim and the incident? And then you

have different business people and one says, no, no, it's always one-to-one. And the other says, no, it's not really one-to-one. You can have multiple claim for one incident. And then you start really good discussion because they now really think about the terms and because you don't have a big wall of text in a classical glossary, they really listen to that, they read it, and they start discussing.

So, for me that really helps to with business talk about that, just the most important terms and you can start really on the beginning and then add more to them and discuss one after other, is that the right relation? And that will really help a lot, also right in the API design afterwards, is that really a one-to-one relation or not and so on. Is this a contain,

how is the customer to that and And now the domain story. So, with with the visual glossary mostly in in parallel, um we do a domain storytelling. Domain storytelling is really simple. Um it doesn't need a lot of introduction if you do it in a workshop. It's really just you have one moderator that asks one business expert saying, okay, now tell me how that use case or

that business journey um works. And he says it one sentence after the other and you draw normally one arrow representing that sentence. And that you really simply and also with not too much syntax or relation, right? In the UML, it's it's way more complicated. It's really simple. You can just say, okay, the librarian gets a budget. With that, a member proposes a book and then the librarian

purchase the book. So, really simple and you have really quickly um the story and the other in the workshop, they will also look at that and at the same time ask questions. And then you get in a good discussion normally. So, the other says then, ah, okay, do they really purchase the book or how how do he knows what to buy? Then somebody says, yeah, well, the

member first needs to propose it and so on. And with that, you get really in the full in this full um frame and and you have really simply explained the whole journey and everybody in the room at the end hopefully agrees, okay, yeah, that's what we want, that's what we need to And until now, it was quite simple, right? Now comes a little bit more of syntax.

Now we go into event storming. Who already did or knows some event storming? Yeah, quite some. Nice. So, there are a couple sub things of event storming, right? There is the big room, there is the process style event storming and we have a little bit um the more software design approach here and also a little bit um different notation, right? So, we have the business events in

the center, the commands here, the the user the the actor and then we have view models and we have aggregates. So, this means first, we have our events, right? So, first we can really search for events, what happened in our journey. So, we can go again back to our to our domain story and say, okay, what happens here? And then we can say first, okay, first a

book get searched. Then the book get borrowed. Then a reading list gets updated. And we can really search for this event, put them into order and also search for then the non-happy cases and other cases that can happen, right? What if there is no book? It's online library, so that will not happen. We have just enough licenses. Um and so you can start with that and then

always say, okay, what's the commands that triggers this? How is book search happening? Well, somebody first has the command book search and then the book is searched. Then who is doing it? The member. And then also really important, what is the model that will be changed there? What what is the view model and what is the aggregate, right? Here for example, the catalog is the view model

that is used and the search criteria is the aggregate. And then we can really put that up all together and then we see really naturally evolving these bounded contexts. So, we see when the aggregate normally changes or the user, we can normally say, okay, that's that's a good cut. Here we can propose a service cut or a new model. And with that, we will see that we

get some nice bounded context that we can then also name. For example, now it's here the catalog management, the landing and so on. And now we already have a little bit of an architecture coming up really quickly. But here normally business people can really help, right? They know what comes after each other and how how do they affect each other. And then we can do the context

map. In the context map, we can now take our bounded context from before and say, okay, now let's separate them, see which business event are happening somewhere and also which entities, so sorry, which aggregates do they have, which will they be responsible to track. And then you see also the view models. This is normally something they will using, but not owning. And then you start seeing the

aggregates and then you know, okay, these events will need to go to another bounded context to to another component. And then you already see where the APIs are coming up. You see different different lines, the dotted ones and the straight through lines. This is if it's synchronous or asynchronous. Normally you see them also naturally if if you cut it like that, that you normally don't need synchronous

calls. Most thing is like, this is really a business event, we come normally from business event and normally something asynchronous that will happen and is interesting for another bounded context or a service, but it doesn't need to be right now. Sometimes you have some things like here that you really say, well, this needs to be synchronous. And with that, still normally business can still follow and you

say, okay, that that's really what we want to do. And with that, then we can all of course then, that's a little bit more technical, right? Say, will that be now something that we buy or not? Here again, you can ask this question, what is more important, will it change more often? That's then a little bit of detail, right? And you can say, okay, here I want

to do a anti-corruption layer or I want to do an open host. So, should we abstract what's coming in and going out or not? This is then the question and this is important to know, will we replace it maybe later that component? If so, we should probably more to an an anti-corruption layer. And for that, we we can then change it without affecting the other components. And

with that, we now come already to the API design. So, we saw this line in between. Every line between two components are normally an API. And we see now we identified here in that example a couple of APIs. we will first now represent that in API product canvas. It's something that we came up that we say, "Hey, it's really good to now first as the next step

say, let's look at one bounded context which normally will go if you use microservices into one microservice and say, how will it communicate with the outside world? How will it communicate with other components?" And for that we came up with that bounded API product canvas. The API product canvas has a name right of the bounded context. Again, here the value proposition from the beginning of the business

model canvas, right? There we can say, "Why do we do that? Why do we need this business model Sorry, why do we need that bounded context?" Then contact, who will own this? Will which team will work on that? And what are the core functions? What should it really do? Then we have synchronous part where we can represent all synchronous um API calls. And you see it's it's

now really just represented again with stickers where we say, "Okay, what are the commands that we had before in the What are the read models that we need to give them with parameters? What will be requested and what will be responded? And this is still something that we have the experience that business people, if you do it in a workshop, can follow and discuss with you. So,

we're now having that discussion which we otherwise maybe have really in a open API specification on still a Miro or similar tool and we can have that with business people don't saying, "Okay, I don't understand YAML." Then we have of course the same for the asynchronous part where we can say, "Okay, which events will be received by that component and which will be sent out with the

aggregates in it." please don't forget that part, the quality requirements. So, think about then every component also, what are the most important quality requirements for that bounded context? Don't forget non-functional requirements here. And of course, a little bit of notice always good if something is not representable in here. that part and now let's look at an example. Here searching of a book is one bounded context. So,

really from the beginning this is the domain story um part for the catalog management and then we have a filled out um API product canvas. Now with with some get end points, with some events that are sent it out and some events that are received. On the other side, we have now the visual glossary of that as well. And this is a really good representation of an

API. So, really just in these two documents. And why can I say that? That shows the next part. We can now at this prompt to cloud code, for example, or normal code. It doesn't need to be the code Add these two images and he will give us a quite good first API definition. That works for AsyncAPI and OpenAPI. Um of course, like if we didn't have good

examples which was not in here of how an ISBN looks like or other things, these we will still to change, right? But the main structure, the end points, the description of it, the the language in it, the ubiquitous language of our bounded context is all in here and we can just use that. So, we will tweak a little bit on the fields, on on the regexes and

so on that we need to validate, but at the beginning we have a first draft already out of the AI just with what we before designed in the workshop with business together. So, that thing that came from business, IT and business agreed on, "Hey, that's how we want to build it. Now just do it automatically to spec." So, it's then a really automatic process at the end.

that's almost it. So, I want to repeat, collaboration is key. don't just build it alone. I think it's really important to to collaborate on that whole journey and think on, "Hey, what do we want to do? Why do we want to do? Where do we want our focus? Why? Really that why? What is the business goal? How do we make money with that? Where is the value

behind it?" To really go on that. Also in the event storming we didn't have it in the example, but Alberto Brandolini has also something in Hey, now say on the events, do they bring value or they remove value? So, that you really from the beginning to the end go over and say, "Where is the value? Did Does it bring value to our business?" And that is really

important why we need to bring business people on that journey. you saw everything was modeled visually. in our experience, it's really simpler to have all people together in a workshop and do it visually um instead of just writing along a long um texts. So, really do it just visually, represent it simple and then of course non-functional requirements and so on, they will have more text, but normally

just try to really draw it simple. That helps a lot and keeps the people together um collaborating more and quicker. short profiles of each bounded context like the API product canvas can really help, right? You can then add them into your confluence or wherever you have your documentation. So, it's really simple. So, if if you go to an enterprise architect or so in your company, just say,

"Hey, look, that's the thing. That's how it interacts. Here's the value proposition. That's why we have it. That's why we build it, right?" For new people in the company, it's really simple then, "Oh yeah, that's that's why we have this component." It's not just, "Ah, interesting name. I have no idea what it does. Why does it exist?" And it's a single approach that covers synchronous and asynchronous

communication. I think that's really important because a lot you're coming with one approach that works just for synchronous or asynchronous, but not both. And I think it's really important that we start here and say, "Let's do integration. Let's look at the whole business journey, but don't first ask, is it a REST API or so?" Because often you see only in that process how it best interact. Um

how should the interaction be? How do we bring the most value? Don't there start at the beginning and say, "Yeah, we just have a new Kafka cluster in the company. Let's do Kafka." And I think with these steps together, it really works great. So, we have in a lot of companies a great experience doing that. And I hope you can also take some points of that. And

if you're interested in more, we wrote also a book with the same title together. Um so, feel free also there to look into that book. And on the that QR code, you find the slides and also some follow-up link. And also our contact addresses on the grids and mine if you want to get in touch. So, thanks a lot and I think we have some time for

questions. >> [applause] >> A microphone is coming to you. Look. So, you you just described the process, but you've only briefly touched on the different roles in the process. Could you elaborate a bit of that? There's a developer, there's a main expert and Yeah, I really did not went a lot into it because for all then implementation bringing the API spec to the end, it's really both.

So, uh we really had the best experience. Uh let's go up to that picture here to really have here business and IT from the beginning to the end. Um why? Because both bring value, right? I think it's really the collaboration between both. Um it doesn't need to be the full team always, but some representative, maybe key developer, an architect and somebody from business or a couple, right?

Um it doesn't need to be everybody, but it really helps if you have some representative because that's normally, Maybe on if you're really designing something from scratch, it's really good if you have the whole team there because that will be the know-how that they will afterwards need for years, right? Of course, you will refine it, but this is so important that you really should take the whole

team. If you later say I was more thinking about in the lines that you have a lot of different abstraction levels. So, you you you have down to to the specific function, but you also have who decides whether to buy stuff or not, what's the budget, who's the expert in the process itself. I was thinking that there's a lot of more more people involved than just the

>> Okay, like on the granularity you mean? >> Yeah. Yeah. Okay. Yeah, there it depends. So, we really did that with with like a it's it's one two component that they already had to redesign, you know, and then then you did do it just with them. But also, we had great experience in doing it really over big process with integration of multiple companies. Then then the workshop

format just gets huge. And sometimes maybe you you do a couple of of of of the domain story telling sessions in in smaller rounds first to get a little bit of a feeling. But still there, take take more people. Normally, it's a really a good invested time because if you then say, "Okay, it's too expensive the workshop." and you start smaller, then normally you will just add

so many more rounds because somebody else comes in and says, "Well, you forgot that really important thing." You know, maybe maybe sometimes strategically you're not allowed to do the big round with 50 people, then start small. But if if you have the backup from management, go for the big round. Then on front is another question. Sorry? Ah. How do I get to that? >> Okay, let's first

do this. >> You gave a very interesting example in my opinion during the presentation where used an example of an insurance company where uh even people in the business didn't knew exactly how did uh claims incidents map to claims. Uh and I found it interesting that it was the IT people finding the that lack of definition of the business context. Is this common or it was just

uh I had that already in other domains. I I had it in in in the former space as well. It's it's it's almost it's more normal to find that problem than not finding the problem, honestly. You know, sometimes it's really on the core entity, sometimes it's just some some other, right? But really they're having the business and IT again in the room, somebody will up come up

with the question, but hey, how how do they come together? And then normally there you have really that valuable discussion, right? And just think again, what if we will not have the discussion here because we don't have that person that asked the question in the room. You will go down, you will go to API then you will go to implementation, then you go to go live, then

you go to first customer creates the second claim, it doesn't work, sorry, already one exists. And then you need again to go like, "Okay, now again, okay, how do we define, how do we bring it to production?" And it's so much more expensive. So, really there you you can never do enough loops, right? Really just ask these questions there. I I come from a school where there

are a lot of courses in technology in both technology and business and some business courses include things like this. >> Mhm. Uh do you think it's getting common for business universities and companies to learn these sort of uh definitions for the business itself so it makes easier to map these flows and these definitions to to to IT systems? Yes. Um a lot what I see is API

first as an approach that a lot of business are adopting, right? They say, "Okay, we we did we did like full Agile. Now again, come a little bit back, say API first." That's a lot of companies I see that say, "Hey, new strategy, API first." And with that you go into that direction a little bit, right? It's it's it's just API before implementation, but with that you

start going to that direction and that's normally the company I consult "Hey, we want to do API first, how do we do it properly?" Um so, I think there is currently a trend. Now, with AI there's also the trend, okay, we don't need an again specification, right? Like in Agile, we we just develop that quickly. I think there's come but I think currently the trend also domain

driven design is again more in the trend, right? It's 20 year old, but what we see there is again a trend and and more adoption. Yeah. Thank you. Welcome. You will also need a workout any more tool tonight, right? >> Could you open the slide with the bounded context once again so we just I make sure to have the question. Do do do. Yeah, um so how

do you decide that the catalog management is its own bounded context and not just a means to an end because if you wouldn't have the landing or reading, you wouldn't need the catalog, right? Yeah. Right. So, first it's a fictive example, so you also always have a little bit less constraints. Um so, two things I would here look at. So, one is really if if these things

change, you go more for it. So, I think we had also in the book some other examples um in there that then show there is more than just one event. one bounded context is really just to have a separation somehow. You have a separation maybe in language or really what it's responsible for. It doesn't need to be I will do a microservice out of it, right? The

There are some hardcore guys that really say, "Okay, we we change something, now it needs to be no microservice." But I would really go always for how many teams will work on it. Is it really another team that we have like five people that just work on that? Then for sure do it in own service, right? But it can also be just one developer doing all these

in one spring application and then that's just one one name space, right? And then you just know, "Hey, there I have some differentiation." So, I would not it's really a little bit a gut feeling and it's a little bit the environment and how you cut it. Um but I would not say too much it needs to be a huge overhead because you do a bounded context. It

At the end you can also do a smart monolith at the beginning and really just say, "I do good modules in between so it's separated and if it's ever gets bigger, we can split it out." But it doesn't need to be all microservices for each bounded context. Does does that help? Yeah, I mean, as you say it's a gut feeling. Like we currently have this discussion at

my work and it's really hard. Like everyone has a different gut feeling and on other presentations here I heard better to do less modules at the start. Now you already separated some things you did I already was like convinced better to combine and >> Yeah, right. It it it's really a philosophy, it's a gut feeling. Um the bounded context um there there are indication, right? And normally

it really just helps then also on looking on the non um functional requirements. If there are also things change, then really separate it in into separate modules that are separate teams or something. But yeah, it it's a gut feeling. Yeah. You're welcome. So, any more questions in the room? Uh since you don't have access to the app, maybe I'll just read you one >> Ah yeah, why

not? Thanks a lot. >> I don't uh what tools do you use for the artifacts produced by this process? How are the artifacts shared, retained, or and maintained? That's a really good question. Um most of them are in Miro, right? So, if your company has good Miro licenses and don't remove boards and so on, you can keep it in there. I seldom saw that. So, I would

really keep them normally as an artifact as a state when it was Um so, export it to PDF or something and then put it in your Confluence Confluence or whatever you have. Um and there store it there. Then the API product canvas normally PDF or so went really good. Um yeah. But it's it's a really good question. Um I think there is still room in improvement also

in how I do it. really hope happy to discuss that. Normally, it's just exporting to PDFs what what works best for me and then add it where all of the documentation is. And links, of course. More questions? >> Yeah, uh how do you manage the process in a context where the requirements are not fully clear? Or maybe it's a new project that can evolve over time. I

mean, how do you manage uncertainty? Yeah, I think that's one of the biggest question in software architecture, right? In general. Um just go with uncertainties. Um, be open about them. Everywhere in the process, right at the red red post-its or something. Hey, here we need to discuss something. It's not Keep them visible, the uncertainties, and then also do decisions with where you know there are uncertainties, right?

That you will be open to change it, um, but we will never sort out all uncertainties. Otherwise, we will never start with the next step. Um, so take them into account, be open about them, document them, and looked at also again everybody's in sync, because often somebody else in the company already knows something more about that uncertainty than you do. Um, there are a total of five

questions in here. The third one, who is responsible for creating API product canvas? How do you version that document? Yeah. Um, again, the team that develops it is responsible for it. I would say normally the architect as a lead there, or the lead developer if if you don't have a separate architect. And then I would keep that in Miro, the original, but each version do a export

and add it where you normally do your documentation. That worked best for me. The next one, how is event storming different from story mapping? from storming mapping, I don't know too much about that. Story mapping, sorry. Story mapping, ah, okay. Um, story mapping is more on the user stories, and this is about the events, the business events. So, it doesn't yet tell the story about something. Um,

it it's for me a step afterwards I would do, because here we really look first at the architecture, and not yet about really the user stories. And the last one, what's the difference between strategic design and tactical design? Um, first you do do you do the strategic design and then the tactical design. we go into detail into the book. Um, so first is really the strategic with

the first couple of step. Um, right here it's really on the strategy on how you do it, on on what you do, and then you go into the um, and then afterwards the tactical design. Tactical is it now really, okay, now that's more in operation, how we develop it, and it's not that relevant for business anymore. It's on how you tactical go on it, right? That explains

it, but not your question, >> Okay. Um, maybe one thing to add, right? It it really works for for greenfield projects really good, then it's just a long process, but everything in here works also for brownfield. we go more into the book into it. Um, so also on if you have old monolith and you want to go into microservice architecture, so you can really adopt a lot

of these steps also for that. because mainly it's the same, right? You want again to know what you do it, what you do, why you do it with business, and then again on how to separate it. So, it really works also for brownfield. So, any more questions? Otherwise, thanks a lot again for your attention and your time, and hope to talk maybe afterwards with some more if

you have more questions. Thank you.