Show Menu
Cheatography
  1. Home >
  2. Cheat Sheets >

Domain Storytelling Cheat Sheet (DRAFT) by

Domain Storytelling, as written in the book "Domain Storytelling: A Collaborative, Visual and Agile Way to Build Domain-Driven Software".

This is a draft cheat sheet. It is a work in progress and is not finished yet.

Domain Storyt­elling

A domain story visualize who (actor) does what (activity) with what (work objects) with whom (other actors).
The actors are the subjects of the sentences, they appear once per domain story.
Avoid making implicit assump­tions or drawing premature conclu­sions.

Tips

Invite real expert­s—p­eople from the trench­es—and not proxies who know the domain from hearsay.
When the story seems to be finished, tell the story from the beginning and try to get agreement: Did we miss something? Is something obviously wrong? Do all domain experts agree with the story?

The Pictog­raphic Language

Actors
Domain stories are told from an actor's perspe­ctive. It can be a person, a group of people, or a software system. Usually labeled with their role or function.
Work Objects
Actors create, work with, and exchange work objects (docum­ents, physical things and digital objects). They also exchange inform­ation about work objects. Labeled wih a term from the domain language.
Activities
Activities are shown as arrows and labeled with verbs from the domain language.
Sequence Numbers
A story has multiple sentences, told one after the other. Keep the order by adding a sequence number.
Annota­tions
The pictog­raphic sentences are comple­mented by textual annota­tions. Annotate infomation about variat­ions, or the goal of an activity. Explain terms from the domain language.

A Typical Journey

COARSE-GRAINED
PURE
AS-IS
Explore a New Domain
FINE-GRAINED
PURE
AS-IS
Drill Down into Subdomains
FINE-GRAINED
DIGITALIZED
TO-BE
Introduce New Software

Story Size (rule of thumb)

Flip chart
10 sentences
Large whiteboard
15 sentences
Digital tools
20 sentences
 

Granul­arity

Describes the level of detail, which can vary from story to story. Aim for a consis­tence level of detail. Mixing might be confusing and indicative of a larger problem.
COARSE­-GR­AINED
FINE-G­RAINED

Point in Time

As-Is
The current situation, often called the problem space, the intent of modeling is to improve somthing bad or solve a problem.
To-Be
Possible improved situations can also be explored with domain stories, decribe the solution space.

Domain Purity

PURE
Domain stories without software systems, helpful for building new software systems. Unders­tanding of the domain without the complexity of existing software. Talk about how things would be done if all activities were motivated only by the domain.
DIGITALIZED
When the domain model is hidden within (badly modelled) software systems. Can be used to visualize and talk about the mess.

Workshop Duration

COARSE- or
FINE-GRAINED AS-IS
30-45 minutes
TO-BE
longer
Recomm­ended
60-90 minutes or 2-3 domain stories
Remote
Set a timer for a short modeling session (around 45 minutes) followed by a break.