Domain Storytelling

Learn domain language. Talk about requirements. Tell domain stories.

discovery-loop-outcomes loop position

No. People



10-30 min per Domain Story




moderator, domain experts, developers, product owner, business analysts

This practice is part of: Domain Driven Design.

What is it?

A workshop format that helps participants understand how people and/or software systems work together. Both existing or future state business processes can be analysed.

Domain Storytelling is driven by domain experts who share typical examples of how they work. These examples are known as Domain Stories. While listening, the moderator records the domain stories using a pictographic language, so domain experts can see immediately if the moderator understands their story correctly. The moderator guides the domain experts by asking questions, for example whodoes whatwith whatwhy.

A Domain Story covers one concrete example. It shows something that actually happens, rather than all things that could possibly happen. After several stories, the participants are able to talk about the people, activities, tools, work objects, and events in that domain. Often, the conversation that was started with Domain Storytelling is later continued with user stories, example mapping, event storming, etc.

Why use it?

  • learn about a new domain and pick up its language
  • elicit requirements
  • bridge gaps between departments
  • find boundaries for (micro)services or bounded contexts (domain-driven design)
  • show how new software systems will change current business processes

Domain Storytelling is versatile and can facilitation adapted for the purpose, for example:

  • the level of detail (e.g. “big picture” or detailed workflows)
  • the number of participants
  • the tools (e.g pen & paper, sticky notes, digital modeling tools)

Further Information

Improve this practice
View all practices