Chapter 7. Relationship to Other Modeling Methods

Domain Storytelling is best perceived as another tool in your modeling toolbox. This chapter covers some other methods that also belong in this toolbox and can be combined with Domain Storytelling. There are situations where you can use them interchangeably, and there are situations where one fits better than the other. And then, there are situations where it makes sense to combine these techniques to tackle specific modeling problems.

Domain-Driven Design

The first method we refer to is actually not a modeling method in the narrower sense of the term but an approach that deals with the development of business software: Domain-Driven Design (DDD) [Evans 2004].

DDD does not describe a single modeling method, but it emphasizes collaborative modeling by domain experts and development teams as the essential part of software development. It is the foundation for the following:

• Strategic design: The more details you learn and model about a domain, the more complex and confusing the models become. To avoid that, DDD suggests to subdivide the domain into bounded contexts. Each bounded context has its own model of the domain and its own domain language. A bounded context is a stable foundation on which to build software. Collaborative modeling helps with finding boundaries between bounded contexts and modeling the details within them.

• Tactical design: Domain experts and development teams work hard to design domain models in their heads and in diagrams. But why stop before the code level? DDD provides technical guidance (so-called building blocks) on how to represent different concepts of a domain in code. Teams use collaborative modeling to figure out which concepts of the domain can best be implemented with which building blocks.

• Ubiquitous language: This language is derived from the domain language and is consistent within a bounded context. This language should be used everywhere (ubiquitously)—from the spoken words of the domain expert to the whiteboard to the code. Keep in mind that there are usually several ubiquitous languages in a company (one per bounded context). It is not a uniform, company-wide language.

If this has sparked your curiosity about DDD, here are some recommended introductory readings:

• Vaughn Vernon’s Domain-Driven Design Distilled is a great and concise introduction to DDD [Vernon 2016].¹

¹ Henning helped to translate the book from English to German: Domain-Driven Design kompakt [Vernon 2017].

• Scott Millet’s The Anatomy of Domain-Driven Design sums up DDD on 24 illustrated pages [Millet 2017].

How to Combine DDD with Domain Storytelling

If you already have experience with DDD, you will have realized by now that the general ideas behind Domain Storytelling fit well into a DDD mindset: It is a concrete way of implementing collaborative modeling by domain experts and development teams.

Furthermore, in Part II of this book we will describe specific purposes of Domain Storytelling that are particularly useful in the context of DDD:

• Learning domain language for developing a ubiquitous language (see Chapter 9).

• Finding boundaries for strategic design (see Chapter 10).

• Modeling in code for tactical design (see Chapter 12).

EventStorming

EventStorming [Brandolini 2021] is a collaborative modeling method that was developed in the context of DDD. During an EventStorming workshop, developers and experts from various departments use sticky notes to create a picture of complex business processes. This picture is created bottom-up by writing domain events on the sticky notes and placing them on a timeline from left to right. After a deliberately chaotic start (hence “storming”), a story emerges, captured as a flow of events that are relevant to the domain experts.

For the Metropolis movie theater, during an EventStorming the modeling space might look like in Figure 7.1—a timeline of domain events on orange sticky notes.²

² For production reasons, while the e-book edition of this book contains colors, the print edition uses grayscale instead.

This style of EventStorming is called big picture. By adding some notational elements, it can be elaborated into a detailed process model and into a software design model. Such modeling works well if software is to be built according to DDD.

Similarities and Differences

Both Domain Storytelling and EventStorming focus on close collaboration with the domain experts. A major difference is that EventStorming places events on a timeline and Domain Storytelling shows the cooperation between actors. While an event storm shows what’s happening, a domain story shows who is doing what with whom.

EventStorming starts with a chaotic storming phase followed by consolidation. In Domain Storytelling, we have much smaller iterations of storming (discussing the next sentence) and consolidation (recording that sentence).

Another difference is that with EventStorming you can visualize several scenarios in one picture (often, the story lines are arranged in lanes so that they do not get mixed up), while a domain story is about only one particular scenario. However, many people use a scenario-based form of EventStorming with a single flow of events, which of course is similar to the Domain Storytelling approach.

The methods differ in how workshops are typically facilitated. With Domain Storytelling, you have a moderator who channels the participants’ input by modeling it. With EventStorming, the participants storm a scenario. However, things are not as black and white as they seem. Domain Storytelling can be used in a cooperative mode (see Chapter 6, “The Workshop Format”), and some EventStorming practitioners switch to a single-modeler mode if needed.

Here are some situations in which we use EventStorming:

• If the domain is not very structured, EventStorming’s brainstorming approach can be preferable to a sentence-by-sentence and beginning-to-end approach.

• If the domain is characterized by time-related processes and status changes, an approach that focuses on a timeline of events seems a natural fit.

• If we want to model a highly detailed scenario using single-flow EventStorming, then the notation scales more easily. Dozens or hundreds of events are easier to handle with EventStorming than the same number of sentences in Domain Storytelling.

Here are some situations in which we prefer Domain Storytelling:

• If the domain involves many actors (people or software).

• If we want to investigate how actors communicate and cooperate with each other.

• When TO-BE processes are to be designed, a common perspective emerges more easily from a moderated, sentence-by-sentence approach.

• If creating documentation is a goal.

• When the corporate culture is more suited to a moderated, structured approach rather than EventStorming’s brainstorming approach.

How to Combine EventStorming with Domain Storytelling

Both EventStorming and Domain Storytelling can be applied at different levels of detail and to AS-IS and TO-BE processes. Hence, there are a lot of possible combinations. We have tried some of them successfully:

From EventStorming to Domain Storytelling

In big-picture EventStorming, you might come across parts of the process that are cooperative, i.e., several people or systems are actively involved. If these parts are critical to your analysis of a domain, you might want to go the extra mile to get another perspective on the process: You can model the cooperative part of the process additionally as a domain story.

From Domain Storytelling to EventStorming

In Chapter 12, “Modeling in Code,” we will show you how to turn FINE-GRAINED domain stories into source code. This task is also addressed by EventStorming at the so-called design level. The notational elements on that level fit very well to the implementation styles Command-Query Responsibility Segregation (CQRS, [Young 2010]) and Event Sourcing [Fowler 2005]. If you are familiar with this flavor of EventStorming, you can use it as a follow-up to COARSE-GRAINED domain stories.

User Story Mapping

User Story Mapping [Patton 2014] comes from the agile community. This simple and versatile method primarily aims to improve product development. It helps you to structure requirements into a coherent story from the users’ perspective. On sticky notes or cards, the participants briefly describe how they imagine interacting with the software. These cards or notes represent user stories [Cohn 2004] and are placed on a wall to form a two-dimensional map (hence the name of the method). The horizontal dimension of a user story map depicts a business process or a user journey. The vertical dimension is used for detailing requirements and prioritization.

At the Metropolis, app developer Anna and movie theater manager Matthew modeled a domain story that shows how cashiers will sell tickets using a new box-office app. Figure 7.2 shows a first, rudimentary user story map for the box-office app.

The user story map is used as a planning instrument for cross-functional agile teams to do the following:

• Talk to a product owner about priorities and increments

• Not lose sight of the context of a user story

• Clarify which requirements need to be worked out in detail next

We have found that a user story map prevents teams from falling into the “flat backlog trap” [Patton 2014]: If a backlog contains dozens or hundreds of requirements, teams lose perspective of how these requirements form a useful product. User story maps provide context to the requirements, thus making it easier to prioritize and slice them.

Similarities and Differences

Both methods are about telling stories. Also, both methods allow you to tell stories at different levels of detail and with different scopes. While a domain story (and similarly a user story) focuses on a particular granularity, a user story map shows different granularities at once. What we call AS-IS and TO-BE in domain stories are called the now story map and the later story map in User Story Mapping.

However, the two methods differ a lot in the way that stories are captured visually. A story map doesn’t show how the actors in a story interact. However, User Story Mapping has its strengths when it comes to planning the implementation of requirements.

If you are familiar with User Story Mapping, please note that both Domain Storytelling and User Story Mapping use the term activity, but they don’t necessarily mean the same thing.

How to Combine User Story Mapping with Domain Storytelling

We have frequently used User Story Mapping as a follow-up to Domain Storytelling. Once the TO-BE processes have reached a certain maturity, we want to derive requirements. User Story Mapping then helps us to transfer the requirements to a structured backlog. In Chapter 11, “Working with Requirements,” we will describe this in detail and give an example.

When a user story is sprint ready and moves on from product backlog to sprint backlog, FINE-GRAINED domain stories are often the right tool for finding out how to implement that user story. They are especially helpful with building the domain model. We will describe how this is done in Chapter 12, “Modeling in Code.”

Example Mapping

Example Mapping [Wynne 2015] facilitates discussions about software requirements. It is used by development teams before they start implementing a requirement to clarify the acceptance criteria of a requirement. The Example Mapping method was developed in the context of BDD [North 2006].

In an Example Mapping workshop, user stories are the starting point for understanding the problem domain in more detail. Concrete instances of a user story serve as examples. Using these examples, representatives of the business department, developers, and testers in particular identify the business rules or boundary conditions of a user story in order to derive acceptance tests. User stories, rules with examples, and open questions are each written down on cards of different colors to capture the conversation.

Figure 7.3 shows an Example Mapping session at the Metropolis. Matthew and Anna are in the progress of clarifying a requirement they had discovered during Domain Storytelling and User Story Mapping (see Figure 7.2). Matthew’s initial rules (second row in Figure 7.3) for the requirement are challenged by concrete examples (third and fourth rows in Figure 7.3).

Similarities and Differences

There is not much overlap between Example Mapping and Domain Storytelling as they focus on different aspects of the domain: A domain story visualizes one concrete path of a business process. Example Mapping is about exploring what is to the left and right of that path. With Example Mapping, you keep asking “What else could happen?” and “What makes this case different from other cases?” Hence, the two techniques complement each other very well.

How to Combine Example Mapping with Domain Storytelling

You can either go directly from domain stories to an example map, or—like in Figure 7.3—use it as third step after Domain Storytelling and User Story Mapping. With Example Mapping, we continue to work on FINE-GRAINED domain stories in the following cases:

• When we need to analyze the business rules that determine process variants

• To detail the requirements to an implementable level

• If it becomes clear during planning that requirements need to be cut into smaller pieces

Storystorming

The goal of Storystorming is to provide a consistent approach from business goals and business strategy to the implementation level [Schimak 2019]. To achieve that, it draws ideas from DDD, BDD, and agile software development. It integrates several existing modeling techniques and aligns their notations; therefore, modelers can move from one technique to the next more easily. Currently, Storystorming features EventStorming, User Story Mapping, Impact Mapping—and Domain Storytelling. However, Storystorming puts a twist on Domain Storytelling: To align with other approaches, the notation is replaced by Storystorming’s color-coded sticky notes notation. This version of Domain Storytelling is simply referred to as storytelling.

Similarities and Differences

We will focus here on the storytelling part of Storystorming. An obvious difference is of course the notation. To give you an idea, we modeled the domain story Metropolis 1 depicted in Figure 1.9 using the Storystorming notation in Figure 7.4.

To understand the notation, please see the legend depicted in Figure 7.5 and following explanation:

• Each lane represents an actor and their actions. The actor sticky is put on the left side, at the beginning of the lane. Human actors are put on a yellow sticky with a stick figure icon (e.g., “moviegoer”). Machine actors are put on a pink sticky with a computer icon.

• The activity (blue sticky with play button icon) is always placed into the lane of the actor. The work object (green sticky with document icon) is placed on the lane of the secondary actor (e.g., activity “buys” with work object “ticket”). If there is no other actor involved, the work object is put on the lane of the actor (e.g., activity “watches” with work object “movie”).

• The sentences of the story are always read from blue/play button icon (verb) to green/document icon (object).

• An assumption (purple sticky with arrow circle icon) that is expressed by a sentence is put above that sentence, e.g., “tickets are available.”

If you read the Storystorming model and the domain story of the Metropolis 1 scenario out loud, they will sound similar. Still, the two alternative notations have their pros and cons:

• To use a textual notation with color-coded sticky notes, all you need is a (virtual) whiteboard and sticky notes. For a pictographic language with numbered arrows, a whiteboard may suffice, but additional tooling speeds up the modeling.

• A domain story’s layout is flexible, enabling modelers to express additional information by rearranging sentences and grouping them together. Storystorming’s layout is based on a grid. On the one hand, this is less flexible. On the other hand, it makes it easier to find the next sentence and renders sequence numbers obsolete.

• The pictographic language can convey additional semantics, and discussing which icon represents a work object can generate interesting insights. However, sometimes finding the right icon can be time-consuming and distracting.

• Using sticky notes may lower the barrier for cooperative modeling (without a designated modeler).

• Storystorming makes it easy to map concepts from other methods (like events and deliverables) to the story.

How to Combine Storystorming with Domain Storytelling

As of the writing of this book, Storystorming is still a relatively new method. We have not had the opportunity to get enough practical experience with it to suggest how it can best be combined with Domain Storytelling (or whether it makes sense to combine them at all). However, we think it is an interesting approach to storytelling and worth a second look.

Use Cases

Basically, a use case is a textual description of a sequence of steps a user of a system takes to reach a certain goal. In other words, a use case describes a scenario. Although use cases are not a visual modeling method, we included them in this chapter because they are relevant to Domain Storytelling and to domain modeling in general.

Originally introduced by Ivar Jacobson at OOPLSA ’87 [Jacobson 1987], several styles of use cases have developed. Alistair Cockburn’s styles from Writing Effective Use Cases [Cockburn 2001] are probably the most influential ones.

The level of detail and degree of formality vary from style to style. For example, Cockburn’s fully dressed style consists of a main success scenario, preconditions, triggers, scope, primary actors, and so on.

Similarities and Differences

Jacobson made storytelling one of the main principles of use cases (“Keep it simple by telling stories” [Jacobson et al. 2011]). Domain Storytelling is a great way to implement this principle in order to identify the main success scenario (also called the basic flow) and collect alternative flows. Once the story is told and visualized, a use cases template can be used to write down the flows as text and add important additional information. Hence, use cases and domain stories complement each other very well.

How to Combine Use Cases with Domain Storytelling

The origins of Domain Storytelling go back to the heyday of use cases, so it is not surprising that the use case format was used to document the results of a Domain Storytelling workshop. We still recommend it when domain stories are shared as text and pictures rather than as a conversation, e.g., as part of a tender. Further on, we will show the transition from business processes to requirements with user stories and User Story Mapping.

Even if you do not intend to document your domain stories, take a look at some use case templates. They are quite useful as a checklist for a Domain Storytelling conversation.

UML

The Unified Modeling Language (UML) is a primarily graphical notation used to support object-oriented modeling [Rumbaugh et al. 2005]. It has become groundbreaking for modeling and software development. We assume that our readers are at least somewhat familiar with it.

Similarities and Differences

For us, UML is first of all a medium for communication between developers. Domain Storytelling, on the other hand, is mostly a medium for communication between developer and domain expert.

There are some similarities between domain stories and UML behavior diagrams. Activity diagrams and sequence diagrams define a notation for processes. Sequence diagrams are also scenario-based, like domain stories.

How to Combine UML with Domain Storytelling

When we are dealing with many domain stories, we sometimes use UML use case diagrams as an overview. The notation of use case diagrams contains actors, so there is a direct connection to domain stories. In a use case diagram, you can collect all actors that play a role in your domain stories. The use cases in the diagram then show which scenarios are modeled as domain stories. In Chapter 3, “Scenario-Based Modeling,” you have seen an example of a use case diagram that provided an overview of the Metropolis cinema in Figure 3.5.

From FINE-GRAINED domain stories a domain model can be extracted. A good way to express this model is as a UML class diagram. We will show how this is done in Chapter 12, “Modeling in Code.”

BPMN

Business Process Model and Notation (BPMN) is a graphical representation for modeling business processes [OMG 2013]. Like UML, it can be used in a formal way to describe processes that are then executed by a process engine. It is also widely used in a nonexecutable way to document and analyze business processes.

Similarities and Differences

While Domain Storytelling is scenario-based, which means that each domain story focuses on one instance of a business process, a BPMN model can contain all possible different cases in one diagram (see Chapter 3). This difference can be seen by comparing Figure 2.13 and Figure 3.1.

For us, BPMN is primarily a medium of communication between developers (and even between developers and machines). There is no defined method to accompany this notation, though some practitioners try to fill this gap. For example, Jakob Freund and Bernd Rücker recommend in Real-Life BPMN that you start with a scenario-based approach that omits gateways (BPMN’s way of modeling alternatives) [Freund/Rücker 2019]. Many practitioners slim down the extensive notation. Even if BPMN is used that way, we think that it is an approach aimed at expert modelers and that Domain Storytelling is a better way to have conversations between developers and domain experts.

How to Combine BPMN with Domain Storytelling

We have successfully used Domain Storytelling as the first step in implementing a semi-automated business process with a workflow engine. Domain Storytelling helps to design suitable TO-BE processes domain experts can agree on. Once the main scenarios have been identified and possible alternatives and error cases have been collected, the happy-path scenario is translated into formal BPMN. Piece by piece, the alternatives and error cases are integrated into the BPMN model.

Summary

In this chapter we showed you what else is in our toolbox besides Domain Storytelling. We are constantly expanding our toolbox and also keep finding new and useful ways of combining modeling approaches. We hope we could encourage you to try different modeling approaches out for yourself and figure out what works best for you.

We see Domain Storytelling as a member of the family of collaborative modeling methods. If you are interested in learning more about collaborative and visual modeling, you might want to look at the following:

• Visual Collaboration Tools for Teams Building Software—a book written by a community of practitioners (including us) [Baas-Schwegler/Rosa 2020].

• The CoMoCamp—a conference series dedicated to that topic [CoMoCamp Website].

With this we’re coming to the end of Part I, in which we explained what Domain Storytelling is. Let’s move on to Part II and see for which purposes it can be used.