Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven software

"Some things must be told that cannot be written, so that storytelling is deeply, deeply human." Stories are the backbone of our culture as humankind. They can be successfully used as agile, collaborative ways to not only view but understand the various domains that software projects touch upon. Avraham Poupko explores how you can better understand and visualize this, in a domain-driven way, with the authors of the  "Domain Storytelling: A Collaborative, Visual & Agile Way to Build Domain-Driven Software",  Stefan Hofer and Henning Schwentner.

---

Intro

Avraham Poupko: Good evening. I'm a Avraham Poupko. We are here in Berlin at the tail end of the KanDDDinsky Conference, which has graciously been willing to host this interview. And as part of the GOTO Book Club, we are going to discuss today the book, "Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven software" by Stefan Hofer and Henning Schwentner. And we have Stefan and Henning Schwentner over here, and we are going to discuss the book with them. Stefan and Henning Schwentner, thank you for being with us this evening. Thank you to KanDDDinsky for allowing us to host this interview.

So, I'm a storyteller, and I'm fascinated by how people use stories to create a worldview and to create a shared worldview. And I found your book to be interesting, to be fascinating. Stories are one of the most useful tools that we have to create this shared model of understanding. And Stefan and Henning, could you please tell us a bit about yourselves, what you do, how you met, and how you got into the area of storytelling? Stefan.

Stefan Hofer: Sure.  I'm from Austria originally, where I started software engineering, and I started as a developer, then later on decided to do a Ph.D. in modeling. And now my passion is to talk about requirements for business software and business process modeling. And I do that at a company called Workplace Solutions in Hamburg, which is where I met Henning.

Henning Schwentner: I'm Henning Schwentner. And I'm also a storyteller. I'm into books. I like stories, hearing stories, and telling stories. That's one part of me. And another part of me likes computers. And in domain storytelling, we kind of bring that together using storytelling to understand the domain and then bring it into computers. I'm known in the DDD community as the guy with many children.

Demo: What is domain storytelling?

Avraham Poupko: Well, rather than ask you to explain to me what domain storytelling is, Henning, could you show me what domain storytelling is?

Henning Schwentner: Awesome. That would be perfect. Then I would like to give a little demo, and if you'd like to be my domain expert, then I'm going to interview you and hear a little story from you, and then model it.

Avraham Poupko: Let's go.

Stefan Hofer: Okay.

Henning Schwentner: Perfect.

Avraham Poupko: Please come over here. The year is 2021. The world is just coming out of a pandemic and theaters are starting to, once again, open and sell tickets, albeit under certain constraints. So, the theater that asked me to provide a technical solution to them asked me to address the following requirements. So, do you want me to tell you the story before the pandemic or the story with the new requirements, post-pandemic?

Henning Schwentner: Yeah, that's an interesting question. So, if we had infinite time, then I would say both of them. That would both interest me. But now let's say the new story in the pandemic with the new stuff.

Avraham Poupko: So, the new story with a pandemic, we only support online sales. We do not allow in-person sales because we don't want people to start queuing up uncontrollably. So, you only buy a ticket online. And you go to the...

Henning Schwentner: Okay. Sorry, then I understand it right, that we are telling a story about selling tickets or buying tickets for a theater.

Avraham Poupko: Yes. Do you want me to tell you a story about buying a ticket or selling a ticket? That's a good one.

Henning Schwentner: Yes, that's a good one. The question is, for who are we building the software, for the buyers of the tickets, or for...?

Avraham Poupko: For sellers.

Henning Schwentner: For sellers of the tickets. Okay. So, then let's say, sell tickets, oh, sorry, tickets at the theater.

Avraham Poupko: So, I want to open the theater to selling, and I want to meet the constraints, I wanna meet the requirements. So, first of all, I need to know how many tickets there are to sell, and what is the new seating schema. The new seating schema requires one row, yes, one row, no, one row, yes, one row, no, and the distance of at least one empty seat between groups. The year is 2021. The world is just coming out of a pandemic. Theaters are starting to open again, and there are new requirements. And this particular theater, which I have been tasked to model software for, is only selling tickets online now, they still do not have in-person purchases of tickets. And I would like to tell you the story of how a person goes ahead and buys a ticket or tickets to a movie. So, she goes online to the theater's website, and she sees a list of what movies are playing and when, and are there still available seats, and what is the biggest group that can be accommodated in tonight's show, let's say?

Henning Schwentner: Okay. So that person who looks at a list of the movies, you say, on the cinema website. And the name of that person or the role of that person, do we have a domain term for that?

Recommended talk: Principles of Web API Design • James Higginbotham & Mike Amundsen • GOTO 2022

Avraham Poupko: We're gonna call her a customer.

Henning Schwentner: Okay. A customer.

Avraham Poupko: My customer. And...

Henning Schwentner: So, she's looking at the list of movies on the cinema website.

Avraham Poupko: Right. And she finds out what movies are playing, and what biggest group can be accommodated for each hour.

Henning Schwentner: Okay. Finds out the biggest group each hour. Finds out the biggest group that can be accommodated at each hour. Okay.

Avraham Poupko: She reserves the block for that group. She starts buying a ticket, and she goes through the payment procedure.

Henning Schwentner: Okay. So, she reserves a block, and I assume this is all happening on the cinema website. And then you say she buys the tickets, probably for the block, right?

Avraham Poupko: She buys the ticket for the block.

Henning Schwentner: And you say, then she has to pay?

Avraham Poupko: She goes through the payment procedure, which is a procedure that already existed pre-pandemic. It's something that already we know how to do.

Henning Schwentner: Okay. So, she's paying for the tickets. And I assume she pays a price or something like that for a ticket if they are?

Avraham Poupko: She pays the price per ticket. That's correct. And there is a credit card-based interface that is already supported pre-pandemic.

Henning Schwentner: Okay. So, here, I think the credit card interface is another IT system, right?

Avraham Poupko: Right.

Henning Schwentner: Credit card interface. So, she pays the price for the tickets in the credit card interface. Okay.

Avraham Poupko: Now, you wanna interview me and ask me some follow-up questions?

Henning Schwentner: Yeah. So, is that it, the story, or are we missing some steps here?

Avraham Poupko: That is the end of this story. There's another story of canceling a ticket, and there is a story of the theater admin entering a new movie. But I guess those are other stories, is that correct?

Henning Schwentner: Okay. So, I assume then this is the happy path where the movie is not canceled.

Avraham Poupko: Right.

Henning Schwentner: Okay.

Avraham Poupko: Yes. And there will be other alternate stories, like what happens if the customer wants to cancel the ticket and she's within the time allowed by policy. And there is the story of what happens when the theater has to cancel the showing because there was another outbreak.

Henning Schwentner: Okay. I write that down, that there are alternatives, cancellation..

Avraham Poupko: By customer.

Henning Schwentner: ...by customer. And also cancelation by the theater. And I write that down here. Okay.

Avraham Poupko: Henning, what software are you using?

Henning Schwentner: So, the software that we are looking at here, it's called Egon.io. I'm going to open up a new tab here, Egon.io. That's open-source software that was built in the company that Stefan and I are working for, WPS. And it's, as you can see, browser-based and the idea is that it's an easy and lightweight tool to be used for domain stories, but it's not the only tool. We are using it now because we're doing an online video and we want to use something that can be used on computers. We also could have done it on a piece of paper or a whiteboard with sticky notes. So, we don't have to be digital, it can be done in an analog setting just as well.

The challenges of capturing a dynamic domain in a book

Avraham Poupko: Thank you, Henning. I now understand what domain storytelling is. And I think that writing a book about domain storytelling can be quite a unique challenge because the way I experienced it was, as I was talking, as I was telling you the story, you were doing domain storytelling. And how do you capture that in book format? A booking form is a static text. So, could you tell us some of the challenges about writing the book and about bringing that dynamics of storytelling and capturing a story to text form?

Henning Schwentner: That's a very good question. When we started writing the book, we were both used to demoing like we just did, so showing people how it is by doing it. Also, show it at talks where you have slides, and that is dynamic. That was quite a challenge when we were taking that and putting that into the booking form. That's why we chose in the opening chapter to kind of do a replay. 

That's why we wrote a little story with some dialogue where people are interviewing each other. Then we have pictures where step-by-step a story grows. What we did use was grayscale. So, we said, well, we let the story evolve with the new parts, they will always be black, and the old parts that have just been seen in the other pictures before that they turn gray.

Stefan Hofer: So, maybe it reads a little bit like a comic book. So you see the story evolve like you would in a real-domain storytelling workshop.

Avraham Poupko: As human beings, we are very, very good storytellers. That's a big part of how we communicate is to tell stories. Whenever we hang around and gossip and share experiences, and do tell a joke or advertise, or whatever, we are essentially telling a story. Telling the story has the advantage that it captures an emotion, it captures an experience, and it captures the drama. It's not just about a sequence of events. Many of us can remember the stories that we have heard as adults or as a child and how they made us feel, did they make us laugh, did make us cry? And part of the unique parents that we have, let's say with our parents or our children, are when we tell and hear stories. 

Recommended talk: Is Domain-Driven Design Overrated? • Stefan Tilkov • GOTO 2021

Emotions in domain storytelling 

Avraham Poupko: In any sense, does domain storytelling capture some of that experience, capture some of that drama, capture some of that togetherness that a real story tell might capture?

Stefan Hofer: These emotions, are part of the workshop experience. You don't necessarily see them in the finished model, but it's part of the process of getting there. Domain storytelling is not just an activity, it's also a modeling activity. And models have a purpose. They are determined by the purpose. So, the purpose of a story often is to entertain. So, that's why if I write a novel and I would describe my characters in detail, I would add like, how do we look? How do we behave? And all of that. So, that's fine if I want to entertain.

The purpose of models in the sense of domain storytelling is usually to develop software that enables that business process that we just saw, for example, for the movie theater that you described so well. So, I don't necessarily need those details, like, how does this woman look like that bought the tickets, or what she had for lunch before she bought the tickets? This is not a necessary detail for developing the software. But what I want to know is, like, what kind of movie? How old is she? So, those are the relevant details, and it's a skill, I think, that a moderator needs to have, finding out how much detail goes in the story. So, what are the things that are meaningful for the purpose, that served the purpose, and which I can leave out?

Henning Schwentner: And we're using this storytelling thing because, as you said, that's something that's deeply rooted in human beings. Already children can listen to stories, they hear stories from their parents, from their grandparents sitting on their lap. And we want to have means of communication that all human beings can use because we wanna have communication and a conversation between technical people, developers, that's us, but also from non-technical people, users, or future users of the software system that do not have a formal education. So, that's why we're not using a formal notation like UML or BPMN. That's why domain storytelling has its own very simple, very basic pictographic language.

The drama in domain storytelling

Avraham Poupko: There is a part of the book...even though you said that we don't do it for the dramatic purpose, we do it for the informative or the communicative value, and not for the experiential or dramatic value of the story. You do have, obviously, a flare for drama. And there's a part of the book from the opening chapter that does have some drama to it. And it stuck with me because I could identify with the story. I'm reading your first domain story. "Matthew runs a small movie theater for art house films called Metropolis that enjoys an excellent reputation among cinephiles. Who are these? People that go to the cinemas. Local craft beer and organic snacks round off the cinema experience. One day Matthew meets his school friend, Anna. When he learns that Anna has been developing apps for almost 10 years, he gets an idea." And then you describe how Matthew and Anna tell each other a story and how they collaborate around a story.

And I like, first of all, the cinema, and an art house cinema, brings up images of culture, of youth, of people wanting to go and experience something together. Cinema always has real value. They bring entertainment or they bring drama to our lives. You tell the story, you tell it very, very well. It's almost a story about stories. And then Anna and Matthew start telling stories. And it draws me in. It might be worthwhile honing that skill of storytelling, of real dramatic storytelling, as part of your domain storytelling so that we remember these things better, that we experience the better. They're more etched in our being. Does that resonate with you? Is that something you could relate to?

Stefan Hofer: Yes. So, especially in complicated cases, we often ask people to tell real stories from the past that happened to them, which we then capture in the individual model. So, we've had stories about people stranded on a sandbank in a river when we were modeling a disaster response team, the processes of a disaster response team in a harbor. So, these are the things that highlight complicated relationships, a series of events that happen, and activities that weren't necessary. So, these are the concrete examples that we learned from and that we put in our model. In some other cases where we don't have that drama, like, let's say the movie theater, I don't necessarily need to know the backstory of the moviegoer. I'm fine with her wanting to buy two tickets next to each other. Maybe I need to know how old the moviegoers are because maybe it's the movie rated 16 or older. We are recording this on Halloween, so maybe it's a scary movie. So, these are the decisions we need to make as modelers, how much of the real world are we putting in the model?

Recommended talk: War is Peace, Freedom is Slavery, Ignorance is Strength, Scrum is Agile • Allen Holub • GOTO 2020

Modeling the typical case vs the exciting exceptions

Avraham Poupko: So, the two questions that come to mind, you write in the book that the main story you want to capture is what you might call the happy flow or the main condition. When we tell stories, they are rarely about the happy flow. Stories that we like to tell are always about the exception, about something exciting, or something different, or something dramatic that happened. It's hard to tell stories about a happy flow. You know, the person got up, had breakfast, went to work, got home, and went to bed. That's not an interesting story. Stories that we tell are always about the exception. And that difference is interesting to me.

So, on the one hand, you take inspiration from storytelling, and storytelling is how we capture experience, how we remember sequences of events, and how we remember dependencies between people and their actions and other people. And yet, one important part of storytelling is the exception. We don't often tell stories about the main flow because that's not the interesting part. Do you find that there's a particular challenge there, at the workshops, let's say when soliciting the stories and you're saying, "Don't tell me the story about the exception, tell me the story about the main flow, the undramatic flow, just the normal part of life?" Is that a challenge that you face, and how do you address it?

Stefan Hofer: Business software must, of course, not just support the exceptions and the dramatic variations of our process, but also the happy path or the 80% case. So, typically, these are the cases that are easier to understand and to tell you a lot about, why are we modeling this process, or what is the goal of this process? And what we do is, as you said, people, they often come with all the stories, "Ah, one time this happened to me and one time that happened to me." And they want to tell you about their exceptions and the special cases that they had. And we need to take a look at those when we want to develop software. But it's probably not the first thing that we want to learn about. So, what we do is we always agree on the storyline, let's say the typical case. So, in the movie theater case, it's probably unrealistic that someone buys a ticket trust for them alone. Yes, it does happen. But if I ask a cinema manager, they probably tell me that 70% of my moviegoers, buy 2 tickets. So, okay, let's start with a person buying two tickets for the movies, what happens next?

We always try to get back to the main story, and if people interrupt the story by, they have just another story that I want to tell, say, "Okay, we'll make a note of this," and we'll collect all those interesting things that could happen or that happened in the past, we collect them on the side. And once we've finished our main story, we say, "Okay, now let's look at these variations, which one we should have a look at, which one will help us learn more about the domain?" So, is it the story about, one time this person didn't buy two tickets, he bought three tickets? Probably not, the process will be the same. But the schoolteacher wanted to buy 100 tickets and come with three school classes and watch the movie. That's interesting. And that's the story that we model next.

Henning Schwentner: Also, I think there's an important point here. I agree with you that for adults, the stories with the exceptions are often the most interesting. But in the situation that we are using domain storytelling, we're usually not in the role of adults who already know what the main flow, the happy path is. But we're like children coming new into the world and we want to know what is happening. And when you look at books for small children, then we have these stories, a man gets up, eats breakfast, goes to kindergarten, and then comes back. And we are, in a way, in this mode because we first have to know what is normal to then see what are the exceptions. So, the exceptions to what is normal are these. That's why we have this challenge that you're asking for, especially with technical people because programmers, of course, like to think about all the exceptions, but we first have to know, what are we doing this thing for? And then we can say, okay, when things go wrong and what things can go wrong.

Storytelling vs domain storytelling

Avraham Poupko: Thank you, Henning. That was very interesting. As I was reading the book, a thought that kept on recurring to me is, how is domain storytelling similar to storytelling, and how is it different? And one of the issues that came to mind again was whether are we talking about the happy flow or the unhappy flow. I think you expressed that well, that when we share experiences with our children, and a lot of storytelling does happen between parents and children, then we often do discuss the happy flow. Thank you for expressing it that way. One of the things that you say in the book is that domain storytelling does not have any conditionals. They're always one path. And that's the way real stories are. Whenever we tell a story about something that happened, we're telling a story about something that happened. And history never has conditional. History could have been one way or the other, but it was only one way.

And since stories are about what did happen and not what could have happened or what should have happened, they lack conditionals. That does allow particular focus. That helped me understand, the fact that there are no conditionals, and the difference between requirements and domain storytelling. The way I understood it from the book, and you explained it, is requirements are what the system should do if properly implemented. And requirements are very future thinking, and they're very prescriptive. And the domain storytelling says, "Let's imagine that the system already exists, and let's tell a story about somebody that did something." And all the stories are written either in the past tense or in the present tense, but they're not written in the future tense, as opposed to requirements that are often written in the future tense.

And do you find that when you conduct your workshops on domain storytelling that that shift between what the system should do to what the system does or even what the system did, is that hard for experienced modelers to understand? Is that a thing that it's hard for people to grasp? Or they get it, they get it quite intuitively, they understand why you're shifting from the future tense to the present and even to the past.

Stefan Hofer: I'd say we kind of ease people into that. So, the way we ask the question is usually, how do you imagine changing this process in the future? Or how do you imagine you will use the system in the future? Often, we start with the current process, so we analyze, we learn from the as it is from how things are today. And then we talk about like, okay, so imagine now instead of this old bad software and enough this new ticketing system, so how do you imagine it works? And they automatically start to tell us the story of how it will be. So, they can imagine working with this new system. So, to me, it feels quite natural, this way of discovering requirements by pretending you already have the system and playing this out.

Avraham Poupko: And do fine.

Henning Schwentner: Sorry. Also, usually, before we are pretending we're having a system, we start with how's the process today? So, let's look at the paper process, with no IT involved, and understand what are people doing. Then we are moving on to this, okay, let's now pretend there is a system, how will the process then change? And how's the story than when the IT system is there? And as you mentioned, I think that's important, in both cases, we tell the story in the present. So, we are going step by step through it in the as-is and also in the to-be, although the to-be, of course, plays in the future.

Avraham Poupko: And you find in your workshops that that works, that people that maybe struggle with requirements the system should do once we transpose them into the system does and you give personas, also you often give names or you give roles. Do you find that people find it easier to express themselves in story form than they do in requirement?

Henning Schwentner: I think it's not an either/or. Let's see if you agree. For me, it's typical that you start with domain stories to understand what's happening in a domain and what you want the system to be in the future. And then from that come requirements. So, it's typical thing that we start with coarse-grain or medium-grain domain stories. And from that, derive user stories. Beware, domain story, user story, and both kinds of stories. But a user story is a requirement, a written requirement. A domain story is a diagram in that sense. And we can come from this domain story to a user story or a couple of user stories. So, looking at the bigger picture, domain storytelling is one method of this collaborative modeling method family. Another method is user story mapping. And if we have a domain story of the right granulation, then we can start with that as a backbone for a user story map, and then derive user stories directly from that. And typically, in those user stories, we will be more detailed than we are in the domain stories.

Recommended talk: Conflict Resolution for Eventual Consistency • Martin Kleppmann • GOTO 2016

Who is the audience for domain storytelling?

Avraham Poupko: Who is the target of a domain story? So, you go through the workshop, you write the story, you tell the story, and there's value happening right there. Because as people are telling the story and creating the artifact, they're being forced to think about particular things, they're being forced to...And then they're done, and then they go home and they're left with a picture on the whiteboard or the computer. Who is the audience? Who's gonna read that story and develop software to it?

Henning Schwentner: Yeah, maybe no one. So, I agree that the most important part happens in the workshop. So, we want this campfire experience of storytelling. Storytelling happens when people gather around a campfire, one tells a story, and the others listen to that. But it can, in some cases, also help as documentation to look at the picture afterward. But the picture alone is only a picture. And the spoken word also helps a lot. So, typically, it is a good idea to, not only take the diagram but to retell the story after the workshop when you want to show somebody what has happened there and what was the knowledge game that happened here.

Avraham Poupko: We're at the tail end of the KanDDDinsky Conference. And one of the things that I've been noticing more and more at the domain-driven design conferences and other conferences is that we take inspiration from other fields of human experience. We take inspiration, perhaps, from the studies of language, from the studies of complexity theory, and studies of communication. And your book about domain storytelling, which is about storytelling, fits neatly into that. Storytelling has very, very ancient human roots. We're a storytelling species from the very early, early days. And when looking at the journey of how storytelling has evolved over the years, initially storytelling was an oral activity. We sat around the campfire, sorry, we sat around the campfire. And one of us would tell a story about something he experienced, something he felt, something he did, or something that happened. We would all listen and remember the story. And then maybe a generation later, somebody who was young at the time of the campfire would tell the story on again.

Recommended talk: Strategic Monoliths & Microservices • Vaughn Vernon & James Higginbotham • GOTO 2022

And these stories only lived in the memories of people. That's the way stories were. And some of these stories may be lived for a thousand years, but only as an oral, verbal experience. Then we started writing the stories, but we only wrote them down as an aid to our memories. We wrote them down, let's say Greek theater. So, when stories like "Homer" were written, they were written so that the actors could remember what to say, but the story was still told at the time of the play. Now, we have already stories where you could go pick up a paperback and read the story. And the author tells the story when he writes the paperback, but he tells it again when I read the paperback. And I'm experiencing the story just by reading the novel that was provided to me by an author with an imagination. And it's not telling anymore. And I feel when reading domain storytelling that there's some return back to our roots. We're getting back to the art of domain storytelling, we are telling the story and creating visual artifacts as we are speaking, artifacts that capture the story in some way.

Stefan Hofer: Exactly. That's exactly what we wanted to achieve with this technique. So, the ideas we need to bring together the people that, for example, if you develop software, well, please, in your storytelling workshops include the people who will actually develop the software, at least some of them. Tossing open artifacts is not enough. So, let's imagine that the story that Henning models that you told him if Henning is the business analyst, and I am the developer, I was not at a workshop and he emails me the final diagram and writes, "Well, here's the picture, it's all in there. Just develop the software, develop the ticketing system." It won't work that way because there's always more to the picture than meets the eye.

In my experience, when people retell the story, they always add information that is not in the picture, but they remember that from the workshop because they were there. If you missed that campfire experience, if you were not at the workshop, then the picture doesn't mean as much to you as if you were there. And if you were immersed in this experience, then it's an aid to memory and you can transfer that to other people. We call it domain storytelling for a reason. We didn't call it domain story writing or domain story reading. So, that's the idea. Bring people together and have those conversations. The conversation is more important than the model.

Henning Schwentner: I like a metaphor. So, domain stories are not novels. They can be used as plays sometimes, yeah, but first of all, they're stories that are told.

Avraham Poupko: One of the things that I like about stories, stories are very often not limited by the possible. They open our imagination. And the stories that I read my children, we have animals that talk, we have people that stay young forever, we have people that know things that nobody told them, we have people that...there are poisoned apples and all kinds of...well, maybe that can exist for real, but there are many other things that can't exist.

Henning Schwentner: But maybe not poison from witches, right?

Avraham Poupko: Right, right. Exactly. You're right, there are witches and fairies and ghosts. The stories allow that imaginary universe. That's a wonderful thing and you could experience all kinds of new things that are not bound by reality. That's why we love going to movies because life could sometimes get a little boring. But when you go to a movie and you see things that have...especially, you know, the action movies or the fantasy movies. 

Key characteristics of domain storytelling

Avraham Poupko: We love telling stories and we love listening to stories. And do you find that that ability to detach and not be limited by reality, or not be limited by time...? I could tell you a story about a lifetime of a man from the time he was an infant until the time he grew into an old, wise man, I can tell it to you in 10 minutes. It'll be a very compelling story about growing up and discovering the world. Do you find that those abilities can be harnessed in the art of domain storytelling? Is that something you're able to bring through that value of storytelling?

Henning Schwentner: Yes. So, the second thing, yes. We can tell very short domain stories. So, we're talking about this thing that we call granularity. So, we can take a long story and tell it only in three steps, in three sentences, or we can go to a more fine-grain level where we can take and call and tell several steps. And for the first thing, I think that's where the storytelling or the story metaphor comes to an end because usually, we do not want to hear what's not possible. Because in the end, there has to be software to be built and that has to be built in real life for what's possible. So, what we are always saying to our users, to our domain experts, is we want to hear real stories, we don't want to hear fairy tales because we wanna build in-the-end software that helps our users. So, maybe that's different from real stories to domain stories that we have here. You kind of disagree.

Stefan Hofer: I kind of disagree, not completely. But some things are easier to imagine in story form that is still rooted in reality and not complete fairy tales, but that helps you to overcome certain challenges that people have become so used to, they cannot perceive a different reality. For example, if you're used to working strictly within the boundaries of your department, or if you are limited by, well, you have some old piece of software that does not support your business process very well. Sometimes people then become so accustomed to this bad business process that they cannot imagine doing things differently. Putting this in story form helps them to break loose of these chains that this bad piece of software has put on them for years, for decades maybe. Then they start to rediscover their domain and, "Ah, yeah, we could do things differently, and ah, let's do it like this, let's do it like that." So that helps to break free from these constraints. So, these are not fairy tales, but still, I think they're not real yet. But...

Henning Schwentner: What I think is the main point is they are exploring the possibilities. And we typically want to stay always or most of the time in the possible, not in the impossible because, well, the impossible will be a model that doesn't help anybody in the real world in the end.

Recommended talk: Expert Talk: Continuous Architecture • Pierre Pureur & Kurt Bittner • GOTO 2022

Domain storytelling in practice

Avraham Poupko: Okay. We're approaching the end of this very interesting interview. And it's been very educational to me. Stefan or Henning, could one of you tell me a story, a story about domain storytelling, or about anything else?

Stefan Hofer: You recently told me an interesting story about carbon footprints and reducing them...to share that.

Henning Schwentner: Maybe I like to share that I had a client a couple of months ago which was a newly founded company, founded during the pandemic, a worldwide organization. They hired people from everywhere, and their goal is to help other companies reduce their carbon footprint. So, they're kind of the good guys, saving the world. I was invited to moderate a session where, for the first time, they all came together, all the good people from different kinds of the world. And it was a great session because, first, they were very nice and very smart people that have great ideas. On the other hand, they had a problem, they had never met in real life. And also they do come from very different fields, from science, but also from consulting, from IT, and what was missing was a common understanding.

I was invited to be a facilitator or a moderator in that situation and we modeled some domain stories, starting course grain, then going into more detail to understand what is it that we're doing. And in a two-day workshop, we came to a great result. Because in the end, they had a common understanding of, okay, this is what we are doing and this is what we are. And that's the kind of experience I like to have with methods like that. So that was awesome.

Avraham Poupko: Thank you. That's a good story. Thank you. Thank you much. Stefan Hofer, do you have a story you could tell us?

Stefan Hofer: So many good stories. So, one recent experience, and this was rather new for me, is I was invited by a company, they are kind of shifting its business model. I cannot go into the details here, of course, but it was one of the few times where the storytellers were the top management. So, members of the board shared their vision for this new business model that they had. And listeners in this workshop, there were only a few storytellers, the board, and the listeners were software architects, department heads, and middle and top management people who needed to understand this new vision, this new business model that they were working on. And the listeners, also asked questions like, "Ah, how do you mean that? And how do you see that?" And this was interesting to see this kind of high-level conversation leading to a better understanding of the future of this company and what they want to do in the future.

So, it was not really about software yet. Yes, of course, they will need to adapt all the software systems. And now, actually, I'm still working with them. And now we are breaking things down into, okay, what does it mean for this system? What will it mean for that system? There are organizational changes. There will be for legal reasons, they need to found new companies that they...for example, one needs to get a bank license, all of that stuff. And it all started with this handful of course-grain domain stories giving this overview of how we want to work in the future. What do we want to enable? So, this was fascinating to see this happening.

Avraham Poupko: That's interesting. And one of the observations that I have as you're telling me these stories is that sometimes there's a perception that stories are for leisure, for fun, for spare time, or for children. At the workplace, we're serious people. We don't tell stories, we do work. We have requirements, we have spreadsheets, we have charts, we have graphs, and we have deadlines. We don't have time for that stories. Maybe in a round of golf, we'll tell each other some stories. And stories are one of the most effective ways we know to communicate. It's maybe the most effective way we know to communicate and to share an experience or to share a vision, or to share a worldview.

What your book is describing is bringing that amazing ability, as human beings, we are storytellers. Every culture that we know is a storyteller. And people that are not comfortable with writing requirements are probably good storytellers. We're all storytellers. And your book very artistically brings that ability to tell stories to the workplace. And let's harness that. Let's harness that ability, that human ability to tell and listen to a story to develop better software. So, Stefan and Henning, thank you, thank you very, very much. And thank you to KanDDDinsky Conference for allowing us to have this interview here. And this is the book. The book is "Domain Storytelling: A Collaborative, Visual and Agile Way to Build Domain-Driven Software" by Stefan Hofer Hofer and Henning Schwentner Schwentner. Thank you. Thank you very much. Have a good evening.

Stefan Hofer: Thank you, Avraham, for your time. It's been a pleasure being interviewed by you. And maybe I can share that we are especially happy because the very first sentence in our book is a quote by you where you say, "Some things must be told that cannot be written, so that storytelling is deeply, deeply human." So, thank you, again, for interviewing us and borrowing your time from us.

Avraham Poupko: Thank you, Stefan. Thank you, Henning.

Henning Schwentner: Thank you.