Loosely Coupled - Collaborative Modelling and API definitions in the age of AI

Good morning, good afternoon, and good evening, everybody.

I hope you have a nice cup of something to drink or a glass or whatever.

I have a whole jug for me of coffee.

And I welcome you to another episode of Loosely Coupled by Bridging the Gap.

My name is Karol Skrzymowski, and I'll be your host tonight.

And today, today we're taking a little bit of a different approach.

We're still going to be having a very nice conversation, but this conversation will be very much hands-on.

So we'll be basically doing some work after work.

Well, I had a whole day of writing documentations and whatnot, and now I'm going to be now collaboratively modelling.

Okay, a bit tiring, but let's see where that gets us.

I suppose this part is going to be actually fun instead of being work.

So, without further ado, joining me today in our studio is Annagret Junker, Dr. Annagret Junker from CodeCentric AG in Germany.

Welcome, Annagret.

Thank you for being here.

Thank you for the invitation, Karol.

Well, I'm happy that you could make it.

Annagret, tell us a little bit about what you do, what's your background, and yeah.

Yeah, I hold a PhD.

I'm really proud of.

As an electro-engineer, long time ago, but because I did software my whole life, I'm more a soft worker than some kind of an electro-engineer.

I do architecture, and I'm really passionate about software architecture and all its slightly different aspects.

Usually, I come from the enterprise level and then to the solution level, but I even discuss about certain infrastructures, etcétera, etcétera.

I'm not so interested indeed in certain network technologies and those things and topologies, but I'm really interested in how to tailor a software so that it really works, technically, socially, etcétera.

So from a high-level perspective down rather than from bottom up.

Exactly, exactly, exactly.

Yeah, I think this is a very common thing for enterprise architects looking from top down and into the details rather than from technology, infrastructure, and networks because that's very, very detailed.

I don't remember when was the last time I actually did something with networks and infrastructure other than say, I need a Kubernetes cluster or OpenShift cluster or something like this.

Yeah, these days, there's so much automation and those things that you even don't know what really happens behind.

There's that add character behind, yeah, and so forth.

Well, yeah, that's true.

We can automate literally everything other than human beings.

Yeah, exactly, exactly.

And even sometimes it seems like some of us are quite automatic.

Yeah, I mean, but it's great.

I mean, you see, I'm not as young as I used to be.

I really started writing assembler code.

And I knew every registr by heart and which ones and O's were in there.

And MIMA is so, so much better because you really can express functionality almost in a natural language.

Right.

You know, we actually share educational background because I'm a bachelor in electrical engineering.

So my background from university is also logic gates, assembler, PLC, all that lovely stuff.

And the common joke was that, well, we as electrical engineers, we're not scared of electricity.

The electronics department is scared of everything more than 15 volts.

We deal with one kilovolt quite often.

So that's nothing.

But, yeah, there is an interesting hop from electrical engineering to IT.

This is actually a very interesting way to get into that from the machine perspective, from the logic gates perspective, assembler, where you actually have to very carefully think about what you're doing and why you're doing it.

Otherwise, you'll run out of memory, run out of space.

It's a, I would say, an amazing mindset if you also adapt the typical engineering, lazy engineering mindset to automate everything and make it as simple as possible.

Yeah.

In the end, it's software engineering, isn't it?

So engineering principles are not too different in the end.

Yes, but I would also argue, as Barry O'Reilly does argue, that IT as a discipline as a whole is a lot younger than the majority of scientific disciplines.

And at certain times, we still have a lot to learn to be a proper engineering discipline, because we went a little bit too far into art form rather than actual scientific science based engineering.

Well, I completely agree to us and probably will show that it's not so much engineering.

I'm an engineer by heart.

I'm really an engineer.

Yes.

But I think it's insofar art, because with each software system we do, we do some kind totally new, which was not there before.

We don't, as we repeat ourselves, of course, often enough.

But in the end, there is a teeny thing which is different and the teeny thing makes a new system.

And I think to have the idea, what can I do that I fulfil the requirements that I can do really that new thing that is art.

Yeah, there is a little bit of art of it.

I would argue that we're constantly recreating stuff.

Sometimes reinventing the wheel.

And you could have solved that already if you knew.

Other times we're actually building on top of the old things and making something a new, better, more performant, more whatever the requirement would be.

I mean, the problem is that we have a long way to go from the real requirement, from the very first idea up to the real code.

And doing that way to recognise that the problem at hand is already solved is really difficult because you have to search a lot.

And you have to think, is it really the same problem or is it not a completely different problem, etcétera.

And when you have said, and I think as long when you do so much research and I have programmed it by myself.

Yeah.

And therefore, and here is, by the way, something where I think where our LLMs really can help.

Okay.

Yeah, because they are fed with already solved problems.

Okay.

And they can give you a reasonable solution to your problem.

But they do all this, of course, but sometimes it's reasonable, sometimes even not.

Then you can use it.

Yeah.

But when you have a really new problems and the LLM can't solve it for you, then you have to think by yourself.

That's true.

There's a lot of problems we don't have to solve because they're already solved.

It's just a lookup.

Other problems we have to actually think and solve for ourselves.

I think a lot of that solving is on the structural level of architecture.

Right.

Because this is very contextual.

Logically, if you look at functional requirements, a lot of them are already solved.

There's a lot of them that are not really new.

They're just repetitive for a lot of companies, a lot of businesses.

Definitely.

But you don't know and you even don't get touch of that knowledge.

Therefore, you have to reinvent it somehow.

And then you have always a teeny bit which is different.

Always.

I'm really convinced that we can't solve problems in a generic way.

It's simply too expensive.

I totally agree in that because if we could, everybody would be using Salesforce, SAP, Microsoft Dynamics, etc.

without any changes.

We wouldn't need specialists in customising these platforms because all of the problems would have been solved already.

Luckily, it's not like that.

So we can live on it.

Yes.

That's our bread and butter to take those platforms and do the magic that is required for each business in the context of the service.

That said, today we're going to be chatting about modelling, collaborative modelling, precisely.

Modelling is one thing.

You can just be a business analyst or architect, sit down and start modelling.

Take a viso, enterprise architect, whatever other tool, or just a piece of paper and start modelling.

But collaborative modelling is a tiny bit different.

So would you mind telling us what are we going to do today?

First, let me define what is a model.

Because I think it's quite interesting what models we have and when you think about what is a model.

A model doesn't live to represent reality as precise as possible.

A model lives so that you can leave out things.

And it needs intelligence to leave out things.

We have the atom model from Bohr.

He left out things intentionally and it works quite well.

We have Schrodinger's equation.

By the way, I love Schrodinger's equation and I still am able to solve them for certain things.

And it's pure math.

It's wonderful math.

And then we have our typical boxes and errors where we describe our software systems.

And we leave out things as well there because we don't know.

Probably when I only want to describe the logical architecture of some things and I leave out API gates, firewalls, etc.

And I want to do more of the network topology, of course.

And I need all those gateways and things which are necessary to run a successful and secure network.

And the bridge behind you, all those nice bridges.

When you draw them, of course, those drawings are just models.

And when I put in 3D things on a 2D surface, of course, it's a model.

And now we need to ask ourselves.

One has an idea and the other one has to bring that idea to reality.

I have the business expert and I have the IT specialist.

And usually both don't speak the same language.

That's true.

So I would just pitch in a summary, just a quick summary of what the model is.

And I think this quote from George E.P. Box sums it up very nicely.

All models are wrong, but some are useful.

Exactly.

One of my favourites.

It's a universal truth about modelling.

And this, I think, also ties down to the psychology of humans in essence.

Because our brains simplify things so we can comprehend them.

So our brains live on models.

And those models are wrong because we cannot know everything because that's impossible.

But for us to cope with reality, it's essential to have those models.

And we don't need to be totally precise or 100% true.

It's not necessary.

We need to be precise only as much as we need to solve the current problem that we're facing.

Exactly.

And the current problem we are facing is that business experts and IT specialists don't speak the same language and don't understand each other.

And what we try with collaborative modelling techniques is that we come step by step from the business requirements to the IT solutions, but with both on the same level.

It's always something business experts and IT specialists are doing together.

Because they need to find their common language.

And during the whole process, they are able to find their common language.

And then in the end, even the business expert understood what the IT guys are doing and the IT guys understand what the business experts are talking about.

So this is the essence of collaborative modelling then?

My point of view, yes.

So where does collaborative modelling come from, you would argue?

What's the origin?

Oh, I don't know.

Interesting question.

My point of view is that you have five guys in a room with 20 opinions and in the end they need to come out with one.

The common joke?

The thing is that software development is people business and people have to work together.

And my point of view is the origin of collaborative modelling because you have to work together.

Fair enough.

My usual joke is if you have four architects in the room, you'll have five different opinions.

Sometimes it's more, definitely.

I think we have our architects need to be multiple personalities.

Multiple personalities, disorder would be useful.

Sometimes it should be useful as an architect, I think.

Oh, okay.

So that said, let's set the stage.

What are we going to be doing today in terms of collaborative modelling?

My idea was that both of us want to establish a rental bike shop where people can rent a bike.

Okay.

And first we need to set up a little bit of the business meetings and we have some kind of a canvas.

We do it collaboratively together because the two of us need to come to one opinion.

And then we need to create something where we can collect together the business requirements and we use a visual modelling for it.

It's called domain storytelling.

And then we need to find somehow how our software environment, our software landscape should look like.

Which services we need, etcétera, etcétera.

And we use event storming for it.

And in the end, we have the AI and the AI can generate the APIs.

More or less.

Sounds about great.

And how are we going to do this today?

So introduce us to the process.

I have prepared something, obviously.

I have here a nice micro board.

So let me share the screen.

I hope it works.

So you should be able to see my screen.

There we go.

And here is a nice...

Here is a nice advertising for our rental shop.

And we already have discussed how the business should look like.

And the business should look like we can do it with a so-called business model canvas.

It was introduced in the early 2000s by Strategizer.

And what you collect here are your key partners and your key customer segments.

Can you read that?

As customer segments, we have commuters and tourists.

Before you jump in, a few things.

So if you're following us live, this is the mirror board.

You can scan the QR, get in there, follow us live and follow Annegret as she talks about this.

I'm going to paste this on YouTube as well.

Right now, I'm going to drop it in the comments in LinkedIn.

So if you would like to follow us, just use the link, pop into Miro.

Everybody has a viewer and I believe commenter rights, yes?

And that way you can actually probably follow a lot easier if you just follow Annegret's cursor.

And that way we can make it a little bit more precise and easier for everybody, I suppose.

Thank you very much, Karol.

I've already hopped into it.

When you are on the mirror board following the link and you click on these, then you can see in the same zoom as me where I am and following my cursor.

What I said, we have as customers, we have here commuters and tourists who want to ride a bike.

And we have some kind of partners, the public transport and hotels.

And then we have your key resources with bicycle and riders.

And as usual in English, we even have resources as people, the mechanics who take care of our bicycles.

And what we promise our customers is that we have bikes easy to book, easy to pick up, easy to return.

And we hope that the tourists, okay, they are only occasional rent-a-bike, so the prices must be a little bit higher.

But commuters use the bike regularly, probably twice a week otherwise the other days of a week they are at home.

And so whole things can be done via app.

And then we have your one-time fees and flat rates, which are paid by the customer so we can get a little bit money out of it.

We need to have a living.

And what we have for costs are the bicycles, the racks, there's a bicycle steward, the mechanics of course want to pay as well and the app needs to be developed and maintained as well.

And here, what I really like with such a business model canvas, as I said, I'm an electrical engineer.

I'm not a marketing thingy or economist or something like that.

It's easy to understand.

You have everything on one page.

You don't need to read those 30 pages of business models or business programmes with lots of sheets and Excel, etcétera.

Here you see everything which is needed.

And that is what I really like because you get really the focus of the business.

When you do it together, this business expert, you really get an idea of what they are talking about.

And now we know that is our business.

So you know what to do.

You are now my business expert.

And now I need to get out from you what you want as a commuter from the bicycle shop.

So you have the role of a commuter and you need to tell me what you do as a commuter when you want to rent a bike.

And that we can do by domain storytelling.

Okay.

Domain storytelling is indeed a collaborative methodology to gather business requirements.

And the trick here is that the business expert tells his story really as a story.

The story has a beginning and has an end and has some kind of a climax in the middle.

And you tell me the story and I, as a moderator, draw literally the story for you.

And because I use a completely different language, you use natural language and I use a visual language, this visual language you can see if I understood you completely correctly or if I misunderstood you.

Okay.

For everybody watching, I want to make a disclaimer.

I did peek into this board before the stream.

I have no idea because I didn't read through any of those diagrams, just to be clear.

So I have no idea what Annegret has here for me stored.

So as a business specialist, I'm completely, let's say, unprepared.

But let's make it my best.

I do ride a bicycle.

I did maintain the bicycle.

I did rent the bicycle.

So that shouldn't be that difficult of a case this time around.

It was my intention that I have no preparation with you, since it's really lively.

Let us try if it works.

Now let's...

And you know how to tell stories because you have two small kids, so you know how to tell a fairytale in the evening.

And now I'm your kid and you need to tell your fairytale to me.

So imagine you are a commuter.

And two times a week or so you need to go to the office.

But from your home to the public transport station you can't walk.

You want to go by bicycle.

But it's too expensive for you to buy a bicycle because you do it only two times a week.

And therefore you want to rent a bicycle.

So have that picture in mind what you are doing when you have a normal work day and you want to go to the office.

What you are doing.

Well, given that I live in the Netherlands, there is more bikes here than people.

That's a normal thing.

But yes, okay.

So my commute scenario is that I basically have a bus stop next to my home but that's true that I don't have my office next to where I get off my bus.

So this is where I would either get into a different bus or a train or ride a bike.

And yes, given that I go to the office once a week it's not feasible for me to drag that bike anywhere there and leave it somewhere in the city where I can actually rent a bike.

So yes, where to begin from that sense?

My imagination was that you as a commuter are at home and now take the bus to drive to the bus station.

At the bus station you rent a bike which you have booked before you left the bus.

And then you can drive to the office.

Okay.

Completely not a scenario that would happen in the Netherlands in that sense because there are public transport bikes.

But let's assume that there is a company...

I'm from Germany so we have not so much bikes.

Yeah, you don't have that much of a bike infrastructure there.

Let's assume we want to set up our...

All right.

But let's assume that we don't have those publicly available bikes to rent from the stalls.

Yes.

Okay.

Yeah.

So I basically would be probably on the bus with my phone in my hand.

And I was like, okay, I'm getting close to Utrecht.

So I need to check which bike place, bike stall has bicycles available and then lock one for myself.

Right.

So go to the app and check availability on the local bike stalls.

And if there's a bicycle available, I would probably reserve it.

What you see now on the screen is that I try, as I said before, I try to draw the story you tell me.

Uh-huh.

So and what you can see here is that I really draw it sentence by sentence.

Uh-huh.

And the sentence is created from an actor.

As in our example, it's a commuter.

And first, as you said, he logs in into the bike app.

Uh-huh.

And searches for a bike.

So that's what you told me.

And I can hear, and you see here, I really can read those sentences.

Yeah, commuter searches for a bike.

And you even added a bearded actor.

Yeah, it was intentional.

Uh-huh.

That's nice.

Okay.

So yes, so I would search for a bike.

And then if a bike is available in one of the racks, bike racks, near the train station that I get off to, then I would reserve it.

And then after I get off the bus, I would pick it up.

So wait a moment.

So you can reserve it.

Uh-huh.

It's a rack.

Uh-huh.

And then, and as you can see, it's even an electric bike here.

So you don't have to do much work before you go to work.

Yeah, they don't want to arrive in a sweaty shirt, you know.

That's a good thing.

A question from my side.

Uh-huh.

When you have, you said you reserve the bike.

Uh-huh.

And I said you book the bike.

What do you think, which word would be better?

Reserves or books?

I would say reservation is a better word.

Because booking is, like, if I put it from a language perspective, how we use the word to book something, it's usually associated with booking a room, booking hotels.

So this is more of a permanent action.

And in booking, you also have a reservation before you book.

But booking is, you already pay for it.

So that implies paying.

Here, I wouldn't pay.

I would reserve the bike.

And then when I pick it up and when I probably leave it, I would pay for it, for the actual time I use it.

So that would be, that's why I would say reserve is probably better as a word.

Okay.

Beforehand, I go back here to our model canvas.

Uh-huh.

We said that the commuters usually pay a flat rate.

Uh-huh.

For a month or something like that.

But even then, it would be better to write reserves because you don't pay for a single ride.

You pay a flat rate.

And then you reserve the bike and not book it.

That would mean that we probably then have another revenue stream, which is pay-per-use.

Exactly.

And that is what it's really, I like it, what really happens quite often when you now go more into the deeper side.

Uh-huh.

Uh-huh.

That we have here a pay-for-use, even for...

Yeah.

You know, that is actually a model that used to, I don't know if it's still there, but it used to work in Poland.

Oh.

I think we lost Annegret.

Not sure if it's on my side or...

No, it's Annegret's side, unfortunately.

So, yeah, there we go.

Annegret is back.

Hello, hello, you're back.

Yes, we lost you for a second.

We lost you for a second there.

All right.

I think you're still...

Yes, you're still screen sharing, so there we go.

Glad you have your back.

Glad that it was just a hiccup.

Yeah, it was some kind...

But I really like here.

We see we need an additional revenue stream, which is, in the end, even an additional requirement.

And we discuss words.

Uh-huh.

And because we discuss words and decide for a certain word, we understand better what is meant.

Reserve, books, etcétera.

Yeah.

And I took it just from the model that was...

The way it worked in Poland, because I used to actually rent bikes in Warsaw when I was living in Warsaw.

There were plenty of publicly available bike stations with a, well, some sort of a booth where you could click through and get a bike that was currently locked in.

And the lock just opened when you paid.

If you had an app, had some sort of a flat rate, that was different.

But usually you just paid as you went.

And I'm very much used to that.

And because my usage is random, and once a week, let's say, then this wouldn't make sense for me to pay a flat rate.

Mm-hmm.

Yeah, exactly, exactly.

So, and now we have...

So, you have to reserve the bike.

Yes.

At a certain rate.

Uh-huh.

So, and then we have here the system.

And the system then sends you some kind of...

Oh, I need a nicer icon for it.

Sends you some kind of a code.

Mm-hmm.

Yeah, no?

As in a reservation code or something like that?

After the reservation, sends a code to your app.

Mm-hmm.

So, and when you then are at the train station, Mm-hmm.

or wherever you leave the whole public transport, you can unlock the bike, and then you can ride the bike, right?

Right.

So, and what you see here, it's really a story in the sense of a story, and it's really drawn somehow, yeah?

Yes, very much so.

So, and because I draw as a story, the business expert can really see if I understood him correctly or not, because it's a completely different language I use here, yeah?

Okay, now...

I listen to a natural language.

Yeah, now the question would be, in this kind of modelling, how would you approach variations?

Because we already identified the different revenue stream, that basically somebody would act differently, right?

Is this like use case per use case modelling, or we can actually build variations on the same model?

It depends.

Good answer, right?

Only always.

To be honest, such a story should not contain more than 12 to 15 sentences, because otherwise you can't read them anymore.

Okay, fair enough.

It's always a good idea to model different user groups in different stories.

As we add here, we have the commuters and we have the tourists, which are completely different requirements, usually.

Okay, yes, fair enough.

Usually, in my experience, I did those workshops a lot of times, you have a lot of business experts, and the business experts are mostly like architects, each has his own opinion and sometimes multiple opinions.

Yes.

But really, when they see how those stories appear, they come together to a common understanding.

It's really the dynamic in the workshop which makes those things so valuable.

As you can't prepare it, you need to be seen to start with a white canvas and see what happens.

As I did this evening.

And you see, even if you were not prepared, even so, we could draw a story.

Yes.

And now imagine if you take an unprepared, let's say, product owner or a business owner or a director or anyhow, we assume that they do know and understand their business on a certain level of abstraction, which basically means that they will be able to model this way.

Because they'll be just telling you about their business.

Exactly.

And because you need to draw, you need to listen.

Listen quite carefully.

And then you get really a common picture for both of us, for both of them.

You asked me about variations.

What you usually don't do is that you model error paths.

You only model the happy path in that situation.

What can you do is that you use it as a threat modelling.

Because here you can say, okay, probably the rack could be hacked by gangsters.

And steal all the bicycles.

And that you can see here, you can model it a little bit.

But usually you don't only do the happy path and do variations only by user groups.

When you have different business experts, you need two or three of them telling the same story.

And then you have really a good and valuable and strong story for your business.

Okay, this reminds me about a technique I learned.

That was this and the previous Monday.

And I'm going to struggle finding it in the book because that's business analysis.

And of course, I'm not yet familiar enough with the book.

So even the name doesn't pop up in my head.

But basically, oh, that was BAM.

Business activity model.

Yeah, it goes in that direction, definitely.

It resembles the business activity model because these are the steps that are...

Exactly.

Business activity model is something a little bit different because it's planning, then enablement, then doing something.

So the actual business thing that we're doing and then monitoring and then corrections.

But this is a little bit in that direction as well.

It goes in the direction because you have the actors, you have the activities, you have the objects.

You have work items which the actors are doing.

I really like the icons.

And I can give those model everyone and everyone who is a little bit in the domain understands it.

And that is what I really like.

And of course, I prepared here a certain story I want to show you because it's not so much different from what you told me.

Just to comment on this, what we're doing right now with the main storytelling is nothing related to IT per se.

It's understanding the business.

It's building our understanding of the problem domain we're going to be tackling from perspective of an IT system.

Exactly. I mean

Let me come to our example.

Let me show you what I prepared.

Here's a mechanic brings a bicycle to the rack and the community registered in the app pays a monthly fee.

Here it's a nice computer.

He pays a monthly fee via the app, searches for a bicycle at the public transport station, then books the bicycle.

Here I use books, for example, via the app, gets the code, unlocks the bicycle, gets the code at the rack, and then the commuter drives home with a bicycle and then returns the bicycle at the rack near his home and confirms the return via code.

Okay.

When you see here the first image, it's not so different from what you told.

But you can see here, and I want to stop you with your problem domain, what you really can do even here is that you see here we have different roles and different work items.

And when you have a step inside of the work items or in a changed role, then usually it's a hint that there are different business contexts.

And then we are already in the solution domain.

For not so complex problems, you really can do and define the business context even with the domain storytelling.

You don't need to go in the events domain because it's a nice methodology as well.

But you don't need it for easy problems and when you have probably even an already existing system, then you can do it just out of the domain storytelling.

You can define your bounded context, as I did here.

Here we have the risk management, etcétera.

And then you can even define already your bounded context on your server landscape.

Now I'll just comment one thing because you said we're already going to the solution.

Just to make clear, the solution here is not meant as solution architecture.

We're not dealing with an actual design of a system understood as IT system.

We're solutioning for the problem.

So we're still in the abstraction of a business problem and solutioning that business problem.

To a large extent.

That's still that high level of abstraction.

It's a high level of abstraction.

I completely miss you.

But when you go in the direction that a bounded context as a team is a service, then I already defined here my services.

On a very high level, completely agreed.

But I'm already in so far in the solution design because I already defined the service borders.

Yes.

As every word in our dictionaries when we work on different problems, it's going to be different because I try to explain to people what's the difference between architecture and solutioning.

And that's always a bit of a conversation that we're having with different architects, especially those that are fresh out of a team lead, dev lead role.

When I ask them to show me their architecture, they show me their solution.

So it's not an architecture.

It's an instantiation of an architecture.

That's why I'm making that remark about the solution because it's, again, a different solution.

We're logically solving the problem.

We already have a logical dissemination of services, but it has nothing to do with implementation or technology underneath.

Definitely not.

It's about logical tailoring.

Yes.

That's the remark I'm making because we're not jumping yet to any implementation and we'll probably not be jumping to anything related to implementation here at all during this session.

Let's see.

Let's see.

Okay.

You'll surprise us.

I mean, it's midnight, but probably we'll come to it.

Let's not take it to midnight.

Another one of my most loved technologies is so-called visual glossary.

What you do here is that you took here, we have certain terms.

Here's a mechanic.

We have the bicycle.

We have the rack.

We have a fee, etcétera, etcétera.

Here we have, even without going into the details, a different story from a tourist.

With the tourists, we even have the hotel because there we don't have the rack.

We have the hotel.

All those terms you collect together and then you bring them, you explain them not by sentence.

You explain them by their relationship to each other.

Okay.

When you see here, we have the hotel.

The hotel charges owe to undefined fees.

Yeah.

That's very close to, well, basically a class diagram.

Exactly.

When you're used to draw domain models as class diagram, it's very close to it.

What I like first, I can do it quite nicely with sticky notes on Miro.

I do it definitely during workshops and discuss it with the business guys.

Then I can discuss all the terms with the business guys.

Right.

Yeah.

When you are used to work in enterprise environment like me, then you have business guys who speak their native language as in Germany, it's quite usual that you have an enterprise environment.

You have German terms, but you don't want probably to have all those German terms in your code because you want to be a nationalised etcétera, etcétera.

Then you can do those things even in two languages.

Fee in German would be Gebühr, nice German word, even with a German umlaut.

Then you can do it even in two languages when needed.

Yes.

What you do here, what you see here, I don't have those usual relationship of a class diagram with aggregate or composite.

Since I always have here strong verbs as a hotel charges fee, tourist pays fee, hotel, stores, bicycle, etcétera.

Because I use those strong verbs, the whole diagram is more expressive than a simple class diagram.

Right.

Because the class diagram doesn't have those verbs on the transition between classes.

Of course, you can do it with just a relationship arrow.

I mean, yeah.

Because we use not so strange arrow forms like we know them from our nice UML diagrams.

Yes.

The business guys understands even that diagram.

Yeah.

Otherwise, it would be very confusing for a lot of people and that would be problematic.

As a visual glossary, it's not so confusing.

No.

But if we would start using UML notation in this kind of a diagram, it would be very, very problematic for a lot of people.

Therefore, I really like a visual glossary because it's really expressive.

And you can draw it with everything.

You can draw it with Draw.io, with Miro as I did here or whatever.

Or just whiteboard it.

And just a whiteboard.

And it really helps the understanding.

And to be honest, I really use it almost every day in discussion.

When I feel something goes wrong in a discussion, then I open a whiteboard and say, let us define our terms.

And not with words.

Just with relationships to each other.

And it really is a strong method.

Unfortunately, there is only one book that explains and that book is only in German from Stefan Zörner.

But for me, it's one of the most powerful techniques we have.

And you can do it collaboratively.

You collect collaboratively all the terms and then you put what is really the relationship to each other.

Right.

I'll try to remember to post all the links to all the relevant books.

Sometime later in the description.

But if I can, I'll post them as well as soon as I have the links.

I just need to put them as QR codes.

So you'll be seeing those QR codes soon enough on screen.

All right.

What next?

What next?

Now, let us assume we have all our business requirements we collect together.

And I showed you that even at that stage, you can define some kind of logical structure of your services.

But you are not sure and you even don't know really which data need to be exchanged between the services.

And therefore, we can do an event storming.

Event storming, probably the one or the other had already heard of it.

It's quite common in the area of software development.

What you do here is that we do a so-called overview event storming to find our bounded context.

And we collect first all the events in our story.

We have already our domain story.

And then we collect the event happening there.

So probably, let me show you.

And the events are already orange.

So which event you would see in our story or in the story you told me?

Let's see.

Well, one event on beginning my commute.

Yeah.

So an event is already something with an object.

Here we have the commute.

And then a verb in the past, started.

And what you do in the event storming, therefore it's called storming.

You have that storming phase.

And everyone in the room is collecting those events.

It's really nice when you do it with really physical sticky notes.

But you can do it on a Miro board as well.

And it's not as dynamic.

True.

But you can do it on a whiteboard as well.

And then everyone is collecting those events for her or himself.

And it's an idea of the brainstorming technique developed in the 60s last century.

Where you first create quantities and then out of the quantities you get the quality.

Okay.

Just for people to get an idea of how extensive event storming is, here's a picture of a wall.

After event storming.

This is the full event storming of some sort of a situation.

I just took it from Google.

But basically if you run event storming sessions in a room, you need quite a few metres of a wall.

Lots of whiteboards or lots of paper or lots of glass panes to be able to do that.

Because we're now dealing with a very simple exercise.

So our event storming will be very short.

But in general, most event stormings are very detailed and very long.

Because business processes are far more complex than what we're modelling today.

Far more.

There are even more simple examples.

Of course.

We have here the commute started.

What other events did you come up with?

Let's see.

Commute started.

I'm back at the main storytelling right now on my screen.

I would say probably user, as a commuter, I'm logged into the app.

So, yes.

I thought logged in.

Logged in.

Yeah, I suppose.

Commuter logged in.

Yeah.

Then possibly bicycles found.

Bikes found.

Then bike chosen.

And bike reserved.

Is there really a difference between bike chosen and bike reserved?

In this case, probably not.

But, you know, I have ADHD.

If I, during my time on the app, I will just look at it, choose the bike.

And then notification pops up.

And I'm like, oh, what's that?

I'm out of the app instantly.

So it remains chosen, but it's still not reserved.

And that is exactly what one can, when you do such an event storming, the guys in the room come up with different ideas.

And then you discuss, when I have here bike reserved, bike chosen, the guys can discuss, is that the same?

Is it not the same?

And what you see here even is that I order the events from the left to the right.

And the sequence appear or occur.

Yeah.

But basically in event storming, the timeline flows from left to right.

So if we have parallel actions, they would be on top of each other.

Or parallel events.

Exactly.

We can hear bike reserved.

And then we can see bike ridden.

So, and probably when he logged in, he first has to, let me see, monthly fee paid.

Hmm.

Especially if it's their first time logging in.

Yeah, exactly.

And then we can probably even say that would be optional, and we can even mark it here with arrows.

So everything is allowed in the end.

Hmm.

So in the next step, what you do in the next step, I need to copy something.

Yeah, sure.

Is that you give each event a certain command.

So which command will trigger that event?

So when we said commute started, what is the event starting that event?

Probably my wife telling me go to work.

Yeah, probably.

I'm joking.

She wouldn't say go to work.

She would want me not to work.

Leave the house.

Yeah.

So I think here we would have start commute and it would be here log in.

It's sometimes, or it's more the rule that you have for those commands that they are just a repeating of the event.

Hmm.

Only in imperative, whereas event is in the past.

That is indeed some kind of a thing.

So let me put it here a little bit more.

Hmm.

So as a bike's found.

Found bike.

Exactly.

And what you see here is that you even start to be careful with the plural and singular.

Yeah.

Do I find several bikes?

Probably I want to have several bikes because I want to ride with my family.

But then you can discuss it with the business guys.

Do you allow to find more than one bike?

Hmm.

Probably yes.

Probably.

So and then choose bike.

Hmm.

So and then you'll see who is doing that.

You put a role to the event.

And what you can see even here is that I use a lot of different colours that are not standard colours.

But that are the, yeah, almost standard colours for event storming, you find by Alberto Bandolini.

That's the events are orange, commands are blue.

And those roles are dark yellow.

So commute starters, of course, would be the computer.

And we have now, we have an easy, easy part because we don't have different things here.

So we left out, for example, the code.

So and here we have that bike.

Thank you for going further.

No problem.

Because when we said that a code must be sent.

Hmm.

So that we can unlock the bike at the rack.

Mm hmm.

At the rack.

Yeah.

So and then the code is sent when you remember our story.

Mm hmm.

It's sent by some kind of a system.

Yes.

So the actor then is different.

The actor is different.

The actor is not an actor anymore.

It's some kind of a system.

And then it's modelled as a thing.

So then we have here our bicycle distribution or whatever we want to call it.

Mm hmm.

So now we have even a nice, a nice overview of our process.

And then we give the process, we need the data for the process.

So let me copy it here.

Mm hmm.

We have the data.

And now we need to define which data we need.

And we need data which we change that are probably our aggregates of our bounded context.

And which data we need but which are not changed, which are used in a so-called read model.

Okay.

So when the commute started, we probably have here as an aggregate to compute.

Usually those things I won't model because that's a commute started.

Yeah, it's a trigger for the whole process, obviously.

But I don't have that information as my system.

So usually I won't model anything.

Right.

So therefore we start with the login.

And even with the login, no new things is created.

Mm hmm.

But obviously we need somehow the user who is logged in to check.

To check is it, is it the correct user who is, who is logged in.

And then now, then I would model an IDM system.

Yeah.

Then I would do here much more.

Yes.

And I have users and I have to log in user who is created probably etc.

But I don't want to model that.

Therefore, for me, it's a user.

And afterwards, a commuter is locked in and I don't need to.

We're simplifying.

We're assuming for this process that the user already has an account.

Exactly.

Exactly.

And that is what I mentioned in the very beginning, that especially when you start with those modelling, you need to be careful what all things you model because it makes a whole model quite complex.

Mm hmm.

And gives you no useful information.

It's, it's like with communicating architecture.

If you leave on a diagram too many, too many abstraction layers.

Exactly.

It's going to overcomplicate the diagram and make it not readable.

So if we're talking about the specific process, we leave out the details of other processes just to make the diagram readable to understand that particular process.

And of course, this goes to be able to log in, you have to be registered or somebody has to make an account for you and give you credentials.

So, yeah, that's, that's the obvious part.

And we're not going to go into that registration flow at this point because that makes no sense for modelling.

When we go further and we have that monthly fee paid, as input, we need some kind, let me call it fee structure.

As in someone needs to define what is a monthly fee, probably you can get certain discounts, whatever.

And you get here out of it, obviously.

A paid fee.

So then we found the bicycle here.

There we have then probably the bicycle in our hand.

And here it becomes tricky.

In my point of view, at least, because when I found something in my point of view, then I haven't changed it yet.

Therefore, I always would model a suite model.

Yeah.

But then when you have chosen it.

Then I have it.

Then you have changed the bicycle.

Then you have here the bicycle in the rig.

And now it's chosen.

It's not reserved yet.

And the other one can choose as well the same bike.

And now it comes who is faster.

As we have done the bikes with her.

And what you can do here even, is that you even model so-called invariants.

As an invariant in the sense, set up business rules which don't change when the object is changing.

And you can implement them quite nicely in your domain model, when you implement your services.

So here we would have some.

And then we have here the state model of the bicycle.

We have here a chosen one.

As a state.

And here we would have the state of reserved.

And now we know that when a bicycle is reserved and it's in the rig, then it can't be chosen by others.

Now we have some kind of business rules behind.

You can detect this with the events domain.

Yeah, chosen would mark it as not choosable, not reservable for the duration of the life of the app we're using or for a moment.

Exactly.

And reserved would make it not pickable for a longer period of time till we get to that rack, take it out, and it will drop the reservation, let's say, in half an hour.

For example.

Exactly.

And then we have...

And that are exactly the business rules.

And those you can define here as business rules.

I don't know.

Let me here.

And that you really can discuss with the business people.

As a lot...

So the purple...

Not selectable for others for 15 minutes.

Probably less in terms of chosen.

Yeah, doesn't matter.

You need to discuss it.

Yes.

And then after 15 minutes, it's free again also.

And those eight models, you definitely can then discuss quite easily and visualise with the business people.

So as far as I remember my theory, and given that I've never done event storming myself, the purple one is policy or reaction.

Exactly.

So the state that we are is the reaction then.

Exactly.

And not selectable for 15 minutes would then be...

The policy.

Exactly.

Okay.

So and then be here for the code sent, of course.

We need some kind of input data.

We need to know for which bicycle the code is sent.

Probably a little bit more context, like which rack, etcétera.

Yeah, yeah.

But that would be the context of the chosen bicycle, basically.

That would be the context of the chosen bicycle, because when you remember, we have here our visual glossary, and we know we have the bicycle, and the bicycle is stored in a rack.

Yes.

Yeah.

And we even know, and probably the rack, we have the location of the rack as some kind of GPS that we have modelled so far.

Yeah.

As when you go then deeper, you would model even those things.

So that you have for the bicycle and the rack, so that you have the GPS data in it, and you have certain searching radios where you can see when you can search bikes, etcétera.

Mm-hmm.

The nice thing is even, and I think it comes out even of our discussion, we don't anymore discuss the whole flow, how the bicycle is, and do we need higher wheels, or do we need electro, and do we need distinguish between heavy bicycles or not so heavy bicycles, etcétera.

Mm-hmm.

We really discuss the things at the event, and that makes a whole discussion so easy, not easy, easier than it would be because you can concentrate on a certain problem and don't need to discuss a whole problem at once.

I did my past event stormings with 40 or more people, which is really horrible.

Usually you should not do it more than 15 people, to be honest.

Fair enough.

But what comes out of it is that we really could come to the core of our problems, and that is really great.

Just on the organisational side of such a session, from what is taught in business analysis frameworks, this is basically stakeholder management at this point because for this session, we need to manage our stakeholders.

For event storming, you need, I think you should organise those sessions as diverse as possible.

Diverse as possible, yeah.

You definitely need the architects, you definitely need the developers who will implement the whole thing.

You need the business experts.

It's even nice when you have some kind of security guys in it because they came up with ideas you never thought to think of.

Yeah, but this is important from the perspective of ubiquitous language, so building a shared understanding of the problem domain between all those abstraction layers of different people working on the same problem domain so that we have the same language, not have dilution of language.

But I would ask you, going back for a second to the stakeholder management part, and of course we'll have different stakeholders.

If we look at stakeholder management from a business analysis perspective where we want to be efficient and effective over our business analysis, especially if we run a workshop, the usual discourse is that, well, you should not invite to such a workshop stakeholders that have strong opinions that are very much opposing each other and might come into an argument.

Now, what's your opinion on that in terms of event storming?

Because this is, to an extent, a tool for business analysis.

And I would fall into that category and if I would be like one time a successful event storming, I would probably not invite these people.

I would invite them.

I would invite them.

Okay.

Because the methodology leads to a certain process.

And you can put them out of the room always.

All right, you would just, out!

For example, yeah.

Or just mute them.

Okay, yes.

And usually I prepare those discussions with some domain storytelling.

And because I'm the door of the domain storing and the moderator, I can really moderate everything in a part so that those strong-headed guys are not taking over the whole discussion.

Okay.

Yeah.

And here with the event storming, the nice thing is, when you have that prepared, the nice thing is that the events are collected from everyone in the room, even the guys, which are usually more silent than the others.

Yeah.

Okay.

And then you can discuss the words, you can discuss what is.

I'm not so with you that it's only business because what we are doing here, when we put those data in the end set, our input data and output data more or less, we really do some kind of architectural decisions already.

Yeah.

As we know which data are belonging to which event, we even do here those invariants and do some kind of state modelling.

That is, in my point of view, is architectural work.

It's hard on the business side.

I'm completely with you.

But it goes in, we are already designing things.

Yeah, that's basically outlining the data architecture to an extent.

Exactly.

And when you have here in the domain storytelling, we are really doing business requirement gathering.

That is a tool for that, yeah.

But here we are already, we do data architecture.

And when we then, the next step when we have all those data together, the next step then will be that we define the bounded context.

So I need to zoom out a little bit so that you'll see the whole process.

And you'll see it becomes longer and longer.

It's not as complex as you showed from Google, but it becomes things.

So what we do here, when I go a little bit out into it, as we have here, the bicycle is distributed in the bicycle distribution bounded context.

We have here the member management.

When I register myself as a member, I pay my fee.

Then I have here the bicycle distribution, etcétera.

And the bounded context, you'll see here that either the role is changing and or the aggregate is changing.

And that is a strong hint that you have a border of a bounded context.

And then you can circle around and give them a sensible name.

As I hear we have the bicycle distribution and what you can see here is that because it's a process, that bounded context can appear several times over the process.

Because it's not a static view, it's a process view.

And then it's quite normal that things appear several times over the time.

Yeah, so if we would map it to a more traditional approach in outlining that as diagrams, a bounded context would be possibly a swim lane in a BPMN diagram.

Exactly, exactly.

We can translate one-to-one.

Not one-to-one, but very close between two formats.

Yeah, I mean, there's a problem.

What we do is that we really do it together.

Drawing a BPMN diagram in a workshop format is possible, but I wouldn't recommend it.

No, that would be a lot harder to do.

I would treat BPMN as a documentation form of the output of such an event storing session.

Exactly, that is quite nice.

That is quite nice.

Because we can translate this nicely and this will form a very nice documentation of what we've done, which would be probably more readable than an event storming output.

And now, here you can see we have those different bounded contexts.

Yes.

And what you can see here, probably we have here the bicycle returned.

And I have here the hotel and the rack.

And I have as roles the commuter and the tourist.

What we do in the event storming is that we even try to model the whole picture.

I said before that we have in the domain storytelling, we do different models for the different user groups, for the tourists and the commuters.

Probably even one, I haven't shown, but probably even one for the mechanics, for example.

But in the event storing, we try to model the whole domain and even more generalising the things from the different user groups.

But still, it's a happy path.

It's a happy path, yes.

Exceptions will need to be modelled separately but, yeah.

Exactly.

That's always the case.

In my experience, it's normally when you need exceptions that they are inside of a bounded context, inside of a service.

And what we model here is an overview model over several services.

My exceptions of course are there.

But in my opinion, usually when you really want to go into detail, then you can detail a model in one bounded context.

There are even things where you can model this event storming in detail.

It's a different aspect of it.

Then you go much deeper into policies and business rules because usually those are the domain rules you implement in one service and not over several services.

And therefore, you do it then in the detail model.

Here we have an overview model.

Okay.

All right.

Annegret, so we have our bounded context.

We have our events.

We know what's going on on the happy path.

What can we do then with this to take us closer to actual architecture?

Yeah.

I want to do it with you together but I think we are running a little bit out of time.

We might not be able to do context mapping together given the time that we want to talk about it.

So I give you here the whole...

By the way, I have a question for the guys outside.

Okay.

I have a book for you.

It's called Crafting Great APIs with Domain Driven Design.

You see it here?

Yes.

One of the guys attending, I can give you a free PDF version of it.

Giveaway.

And I want...

They can answer in the chat, right?

Yes.

Yeah.

To answer the question.

Okay.

So before you give the question, let me outline the rules.

So Annegret has one PDF to give.

Annegret has a question.

The first person to answer this to show up in our studio chat and we're gathering the chat feed from LinkedIn and from YouTube simultaneously in our studio chat will get that PDF and we'll contact you after the stream to outline details.

Okay?

All right, Annegret, then.

Okay.

Let's see what's going to happen in chat.

This is the first time we're doing a giveaway on this stream.

This is going to be interesting.

There are several team patterns already outlined by the DDD guys.

Here you will see two ACL and conformist.

And I want to know what is the most bad pattern one can use.

So we're asking about what is the worst context mapping pattern one can use.

Exactly.

I have my type, but I'm not playing the game.

So we'll see who answers.

Probably it's too complex a question.

No, I mean, okay.

Let's give some small hints.

Okay.

So what you're looking for is context mapping.

Context mapping has, I believe, six patterns.

Exactly.

Yes.

So out of those six patterns, and if you're with us in Miro or watching, two of them are visible on screen.

Exactly.

But out of six patterns, there are nine patterns I meant.

Oh, nine patterns.

Okay.

Which one would be the worst?

They are defined by DDD crew.

That's a good hint.

All right.

Let's leave people with this.

We'll see in the chat later if there is an answer to this question.

I'll leave the question on screen for the moment.

All right.

Context mapping.

What I do as a context mapping was original introduced by Eric Evans.

Yes.

In his book, Domain Driven Design, published in 2004 already.

And what he did is that he wanted to show in the context team dependencies.

And team dependencies means that one team delivers something to another team.

Both teams are using it, etcétera, etcétera.

And nowadays I use it more for data stream picture because that are more or less interesting things one has, which data need to be exchanged by the different services.

And to do so, I put out the bounded context.

I detected inside of the event storming and put in rectangle for each of those bounded context.

But only once.

As I said before, they can appear several times.

Yes.

Here you find only.

So it's more aesthetic models and dynamic model.

And then you put the events you found in the event storming inside of the bounded context.

And then you can discuss for one bounded context with synchronous communication you need only for that bounded context.

So here for the bicycle distribution with the aggregate bicycle, we have a get, a post, and a put.

And for member management, I think it's quite easy.

We have the member registered event.

We have the member and we need to get a post, a put, and a delete.

And then here you can see that we have here the accounting.

And the accounting has event monthly fee paid with a fee.

And that event then is published to the member management.

So here we have a data exchange between two bounded contexts.

And what you see, we have here the event which needs to be published by the accounting and then is consumed by the member management.

And what you see here even is that we have here a conformist for the accounting with an anti-corruption layer.

Why?

Because usually you will buy an accounting system and a member management system.

You won't implement it completely for yourself, but not to stain your own models.

You need probably for your monthly fee and for your member management, you build an anti-corruption layer for it.

And then the other things are accepted.

And the other thing we have here, we have the reg management.

And the reg management, you buy as well.

Therefore, you need here the anti-corruption layer as well.

And when a bicycle is unlocked or locked, then the event is published to the bicycle distribution.

So what you can see here is in the end is really the service overview.

As a bicycle distribution, we even have the data to be exchanged here from the reg management to the bicycle distribution.

And then you can define all the APIs.

Here we have the sync APIs, even this we need.

And we have the other APIs for the exchanges between the services.

As I said, it's logical architecture we are doing here.

We don't do some kind of internal solutioning, which database is used, which adapter pattern is used, etcétera.

No, that's completely outside of any implementation yet.

We have a first answer to the question.

I would deem wrong one, but let's have it.

Maxime is totally right.

That is what I want to hear here.

Don't use it.

A big ball of mud, I would say it's a consequence of using certain patterns.

You will accept this as an answer?

Yes, I want to hear.

That's the one.

Oh, yes, you're right.

Because that's actually one outlined as an anti-pattern by the DDD crew.

I want to hear it because the anti-pattern of a big ball of mud is exactly what we want to avoid when we do collaborative modelling.

See, dear viewers, I did not know the answer because Annegret made this question without telling me the question and without telling me the answer.

So my brain is like, what are the correct patterns of context mapping?

Big ball of mud is not the correct pattern in that sense.

It's an anti-pattern.

I was like, which one would be the worst?

I'm sitting here like, hmm.

But you can't do inverse.

Yes, that's very true.

So Maxime has really deserved his copy?

Yes, that's true.

I would deem that the wrong answer, but that was the answer you were expecting.

So that's actually great.

And if you want to read more about context mapping as outlined by the DDD crew, this is a link here for context mapping of their GitHub.

It's all explained there.

I just didn't scroll far enough down to see the cheat sheet where that big ball of mud is outlined.

Yes, the cheat sheet is big ball of mud is outlined.

Yes, that's true.

But just to be fair, this is not exactly a pattern we should be thinking about when we're designing.

This is an anti-pattern we should avoid at all costs.

Yes.

Annegret, you're showing us Claude.

Yes, I'm showing you Claude, because you said we are far away from implementation.

And I want to show that it's not so far away from implementation.

All right.

What we can do is that we can now really design based on that information we have here.

We can design our APIs.

And because I'm really a lazy guy, the AI can do it for me.

So I have here a prompt that the AI is an AsyncAPI.

An AsyncAPI expert.

And for bicycle distribution we have here, the AI should generate the AsyncAPI for me.

So let me put it here in my cloud.

So what we need now more is there are certain information needed, and we need the visual glossary.

I'm curious, because if I'm building anything using AI, any generative AI engine, I usually write a lot of context.

So I did not ever use images to convey the context.

So I'm very curious what will happen.

So I can now paste the context in here.

Now I need a little bit to show that I can see my screen, right?

You know what?

While you're doing this, I'll open a Gemini, which is my default LLM that I use.

And I'm going to try and do the same, and we'll compare results.

That would be great.

So I only need to screenshot it.

Mm-hmm.

All right, I'm going to do exactly the same as you do.

I lose my mouse.

I'm on the wrong side.

So I'm screenshot here the visual glossary.

Yes, all right.

I also have a screenshot of the visual glossary, which is going to save it now under the name visual glossary.

Yeah, but you can put this copy and paste there.

So I have here the visual glossary.

Then we need here the context map.

Mm-hmm.

There I am.

All right, doing the same.

And now comes a little bit of a trick.

As I said, you need to give them extremely much of context, yeah?

Mm-hmm.

To be more precise, what is the expected results, you can use so-called one-shot prompts, where you give them an example of the expected results.

Yes.

And that I do with a good Async API I created.

Mm-hmm.

I have it here.

Let me put – I have it in my local thing, but I give you – when you can get a moment, I can give you the GitHub link.

Either GitHub or just paste it into Miro as text.

Ah, so that I can

Or as a file. Either works because

Also, that is a good idea, yeah?

I can put it on the Miro.

That would be probably quicker.

Voila.

I only need to find my file.

See, people, nothing scripted.

We're doing this live as we go.

That's what I love about these streams in general.

It's an unscripted conversation.

We have an idea to talk about.

Let's talk about it.

Some speakers prepare in details like you did.

Others just come and start talking.

That's a lovely, spontaneous part of doing loosely coupled.

I have here – It's from – The file type is not supported, yeah?

Ah.

Just please copy the text in a text field.

That should work as well.

I will do – So, I have it now here with me.

There's a text field.

Ah, I think it's too long.

Yeah.

No, it doesn't work.

Barma, I give you the GitHub link.

I think that's – Yeah, okay.

Well, you created a very long AsyncAPI spec then.

Yeah, it's really long, yeah.

And by the way, in the repository I put the link out of, there are AI comparison I did.

And in that API also now.

Here is the link.

Yes.

But it's only here.

You see the link, yeah?

You can use it.

Yes, yes, yes.

Got it.

Got it.

And there I put some kind of API comparison and AI comparison, which is the best when you create those API things.

So, where's my clothes?

My clothes is back.

Okay.

So, I have everything uploaded to Gemini already.

And I copied your prompt from Miro.

That's great.

So, now let us see what comes out of it.

All right.

And I'm clicking play.

Now we have the fight who is faster, right?

All right.

Let's see.

Gemini has already given me a yaml.

And how does it look for you?

Let's see.

I don't know AsyncAPI that well.

So, for the moment, while yours is generating, I'm going to hijack the screen myself then.

Yeah.

Would be nice.

Let's see.

Chrome tab with Gemini.

There we go.

So, let's take a look.

I'll just zoom in a little there.

There we go.

Let's see.

Bicycle distribution version one description.

Events produced by the bicycle distribution service for bike sharing system.

So, it's a nice description.

Distributed booked.

Contact.

It puts your information there.

That is out of the example I used.

That is mine.

That is how it should look done.

Tags.

Core domain.

All right.

Servers.

Even broker bike share.

Whatever the broker is.

Yeah.

Kafka.

Even those Kafka bindings come out of the example.

That is what I meant.

When you give them a really good example, you really get good answers.

Yeah.

Because for those you won't get when you just put in a zero short prompt.

Yeah.

It's not about prompt engineering.

It's about context engineering, right?

Right.

If you don't provide the right context, it will be horrendous.

So, here we have the bicycle distributed channel for the bicycle distributed thing.

And we have the bicycle book channel for the bicycle.

Books event.

Yeah.

So, it's nice.

So, when you now looked here, we have bicycle distributed, bicycle search and return.

So, we see only you.

Can you go a little bit to the schemas?

Yeah.

Let's see.

Schemas.

We have the right schema.

Fine.

The problem here is what you can see here is we want only to have bicycle distribution.

And in the context map, we had only bicycle locked and bicycle unlocked as event to be received by bicycle distribution.

I think it went overboard with the model.

Exactly.

And that's the point, yeah?

Usually, one must be quite careful with the LLMs because they know too much.

Yes.

And they can't leave out.

It works quite well when you don't have the events inside of the bounded context in the context map anymore.

Then it works really well.

But when you have too much information, then they are too overwhelmed and don't know anything anymore.

And here you have the bicycle.

It's not bad.

ID, serial number is e-bike.

That's good.

Motor, that's the reference to that earlier.

Motor, which was hallucinating, which we don't have modelled.

Yeah.

It's irrelevant.

So, basically, at this point, I would already write a prompt, please remove motor from…

But it's really helpful when you see how much you spare and time to write those things.

Oh, yeah.

And probably you haven't simply not thought of it, yeah?

The view diameter was modelled, so it's nice.

But it's even come up with certain ideas of the enum of the sizes, yeah?

It's really nice.

Yes.

And so far…

It would be nice.

Yeah.

It's really helpful.

I use it meanwhile almost every day.

Mm-hmm.

Yeah.

And then you look into the link, which is now…

This is already nice, because it already provides proper metadata for the communication, which is something a lot of people forget when designing an API.

It's not only about the business payload.

You actually need to provide specific metadata so that it's operatable, and it's a problematic thing later.

That is exactly those meta things you need in an API.

You can really put into your example.

That message header comes out of the example, yeah?

Mm-hmm.

And therefore, you spare so much time just in writing infrastructure in the end.

Mm-hmm.

Yeah?

And there are gold plate things that you can spare much time in it.

All right.

Let me kill my feed, and let's see what did you get from Claude.

Oh, and that is here even in Claude.

What you can see, we have here the bicycle distributed, which means we have all the events inside of the bounded context, which we don't want to publish.

We want only to have that book and look.

And here we have even bicycle picked up that was not modelled, but Claude thinks we wouldn't need it.

Yeah?

That's nice.

And Claude is not wrong, because we would need that event from the rack to start billing somebody if they're on a paper use.

So until you see the Kafka bindings are there, it's fine, yeah?

We have then here the distributed channel, we have the book channel, the search channel, etcétera.

And it's in the same, you see here even the binding version, so that we have already the binding even to Kafka, it's here even more.

That comes out of the example, so it's really nice.

Yeah, but there's a problem here.

You have to put out a lot of things.

Therefore, when you do those pictures and you want to create something out of it, it's always a good idea to put all those things you don't want to have generated.

The usual problem with generative AI, if you tell it not to do something, it'll explicitly do something.

Exactly, exactly.

It doesn't work.

It's like talking to people, don't think about pink elephants.

Yeah, yeah, exactly.

Obviously, now you're thinking about pink elephants, right?

But for me, it's really, really helpful because as a starting point, it's amazing.

You create more than an 80% starting point.

Yes.

For me, as a neuroatypical with ADHD, my biggest problem in writing literally anything is a blank page paralysis.

Exactly.

For me, it's a lot easier if I have something to start with and having generative AI doing even a wrong answer, but just doing something to start with so I can start just editing it instead of writing it from scratch.

That makes it so much easier.

But you can see here, because we said we are not at the code at all.

I only want to show that out of the pictures, you are so fast to the code page.

Yes.

That you don't need to start with it.

You can start in the end, in the discussion, felt quite late with code.

Usually, I want to start quite early with code as well, so I know the stuff.

But it's really helpful to do those discussions.

As I said in the very beginning, you can start with certain things already after the domain storytelling.

Especially for those things where you know they are quite clear, like accounting, like a lock-in, when you need an IDM, you can all set up those things already.

Because it's not to the business core.

But when you want to model the business core, then you need a business and event storming together with your business guys.

Again, this would be picking on semantics.

If you say close to code, not close to code.

It depends how you define what an API specification is.

Because for me, that's not code, that's a specification.

But it's already very close.

Yes, we can often generate some code of an API implementation, etc.

I'm completely with you.

YAML is not code.

But this is a lot closer to code, from that perspective.

And it also gives you another abstraction layer, because you're moving from this abstraction of bounded contexts and their relationships.

So ACLs, conformist, partnership, customer-supplier.

And we're moving towards more details.

So we're basically, through the whole process that we did today, we moved from an abstraction of a story, like a user story, which is the domain storytelling.

We're looking at this from the perspective of a specific actor.

Then going through event storming and visual glossary to outline what happens from our business process perspective and the relationships between different aggregates or objects in our business process.

Down to context map, where we actually define bounded contexts.

And those bounded contexts already can be overlaid to actual application systems, which are implemented or to be designed.

And then we're going even deeper towards actual entities.

So actually defining attributes as if we would be doing a class diagram.

Because might as well, instead of generating an async API, we might as well ask the LLM to generate a class diagram based on this discussion.

Sure, sure.

Here, the class diagram is more or less what we have put in for the visual glossary.

Yeah.

We could have here generated even the OpenAPI.

Then you can work close with the OpenAPI and can generate in a sense of a contract first approach, can generate your controller from it.

Based on that, you can then generate probably your database model.

Yeah.

And then you are really close to the things which make the job interesting.

Because then you have to build up the business logic.

And there it becomes interesting.

There you can't so much generate.

There you have to think.

But my point of view, all those modelling techniques help you to think and helps you always up to the database design in your language and in your thinking to be close to the business.

That's the lovely part because over all of these abstraction levels, we were very consistent about the language.

We kept using exactly the same language.

Just also on the note in terms of generating the class diagram, because there are different types of abstractions for class diagrams.

You have conceptual, logical, physical, right?

Exactly.

So visual glossary is more on a conceptual level of class diagram, right?

And when we go deeper through even storming context map and on the level that we generated the AsyncAPI specification, we could actually generate a class diagram that would be the physical model, which is rich in information such as attributes, enumerations, regular expressions, examples, etc.

Of course, there's examples and even regular expression.

And so you have to work on and you have to think about.

But you get really a good starting point, as I said.

Yes.

And this in terms of modelling of communication, I would say this is a very good start.

If somebody is working on a specific domain system just to get going with proper interoperability from start before we start building.

Exactly.

Because that's a very important aspect that we think about that interoperability beforehand rather than as an afterthought, which is, in my experience, something that happens quite a lot, unfortunately.

But this is just the tip of an iceberg because there's so much more to interoperability than just building a good API.

And then what is a good API?

Because then we need to have a discussion about the purpose.

And we actually had a discussion about that on Loosely Coupled some time ago with your colleagues from CodeCentric, Daniel Kocot and Miriam Greis.

Greis.

Greis, yeah.

And I'm having trouble with that particular sound.

Daniel was laughing at me for mispronunciations earlier.

So then we go into the purpose of it.

And if we align on the purpose and then start using context mapping to properly define that against data interface quadrants, we're already going way further.

And then, and here a little bit of a shameless advertisement, if you want to learn more about looking at interoperability on an ecosystem layer, we're actually running a two-day training with DDD Academy in January about strategic integration design with domain-driven design, which is combining ecosystem architecture.

So integration platforms, message brokers, and all those patterns on the ecosystem level to talk about interoperability at a large, large scale.

So the system that we look at, its API, async API, open API, whatever is the definition there, is just a small component of that conversation then.

So there is a lot more to talk about in that sense, but this is very, this session today and this modelling today is a very important starting point for anybody designing a system, whatever that system may be.

Right.

All right.

Did we miss anything?

Do we need to put anything else here?

Links I'll try to include in the description after.

Of course, the recording is on YouTube always, so this will be visible.

People can find that in QR.

So anybody watching the recording can find the QRs over the whole stream.

One more thing, another book by Annegret here about the topic.

So modelling using domain storytelling, even storming context maps.

That's an older book, right?

Not the one that we showed earlier about crafting APIs.

Crafting APIs we just did a moment ago, but the whole process of the collaborative modelling is in more details explained in this book.

So if anybody would like to have a jump into details, this is where you can find more details on the topic.

All right.

So I think we'll be slowly closing, but before we jump into the actual closing and anything else, a few words of advertisement.

Next week, we're diving into a completely different topic, looking at symptoms and problem solving and identifying the problems.

So my guest next week will be Woody Zuill, coming to us, I believe, from US, as far as I remember, a Lean and Agile guide and coach, and we'll be diving into identifying things, looking at what are the actual problems, what are the actual symptoms, how can we dig into what the problem actually is, instead of just skimming over the surface and putting a Band-Aid on a gaping wound.

So that's next week at 7 p.m. Central European Time.

And if you're new to the stream, if you haven't been with us before, you can find more information.

You can find the recordings of previous streams on bridgingtheGap.eu.com

You can find also all sorts of articles about ecosystem interoperability.

You can also subscribe to our Substack and, of course, subscribe to the YouTube channel to get notifications about the upcoming live streams.

And as far as my memory serves, we already have live streams outlined to January.

So still about four of them coming up this year.

And January is starting to fill up in my pipeline.

So that's going to be interesting.

So more of them will show up soon.

Now, that said, it's been a lovely conversation.

Thank you.

It was really fun with you.

We can definitely do this some more.

If we would dive into edge cases and specifics of different notations, different exercises, we could probably be going for the next two hours.

Yeah, definitely.

Definitely.

We will, I hope.

We will.

All right.

I think we'll discuss this later as to how to put that to good use and have some sessions in more details about specific techniques because all those collaborative techniques are a really good way to start a conversation, especially if we don't have a common language.

So I think Maxim can contact me via...

I'll arrange all of that.

Don't worry.

We'll get that sorted.

So I'll arrange that with Maxim.

Maxim, please ping me on LinkedIn.

If not, I'll ping you tomorrow.

And ladies and gentlemen, for those still watching, and I see on both YouTube and LinkedIn that there are still people watching, so that's amazing.

Oh, great.

Thank you.

Super.

Thank you for being with us and have a lovely, I assume, night being in Europe or afternoon or whatever is the time zone that you're watching us at.

And see you next stream.

Thank you very much, Karol.

Thank you for having me.

Always.