Domain Storytelling models a precise business process as one visual story: a sequence of activities and interactions among people, systems, and other entities. Telling a specific story keeps the group focused on how the domain works—or how it should work—rather than jumping between abstractions and edge cases. It can help identify modernization requirements and improve the shared conceptual domain model. section 8.5 section 8.5.2 section 8.6
A small pictographic vocabulary makes the story readable:
- Actors are people, software systems, or other participating entities; work items are domain concepts they use or communicate. section 8.5.1
- Activities show an actor doing something with a work item, often involving another actor; sequence numbers establish the order. section 8.5.1
- Annotations capture explanations the picture cannot express easily, while groups relate parts of a story, such as a domain boundary. section 8.5.1
Validating a prescription
In a proposed future process, a customer places a medication order on a website, then uploads a prescription. A prescription validation service asks the doctor for confirmation by email. Once it receives confirmation, it informs the orders system so the order can be accepted and fulfilled. Numbered activities let the group follow that one scenario step by step. section 8.5.1
The prescription-validation diagram shows how actors, work items, arrows, and sequence numbers make a future-state process readable as one story. section 8.5.1
Before a workshop, choose the story’s granularity, point in time, and domain purity. Keep each story at one level of detail: a coarse story might span teams and domains, while a fine-grained one might expand a single activity into many steps. Decide whether the group is describing today’s reality (*as-is*) or a desired future (*to-be*), so the conversation does not repeatedly switch between them. Facilitate the single conversation to keep it from splintering or drifting into rabbit holes. section 8.5.2 section 8.5
Use separate stories for alternative scenarios rather than putting conditionals and edge cases into one diagram. Unlike EventStorming’s broad, branching timeline, Domain Storytelling uses sequence numbers without requiring a timeline layout. Choose between the techniques according to the people and situation: Domain Storytelling suits teams that want digital stories they can retain, evolve, and replay, while EventStorming suits capturing many variations in one modeling space. A purpose-built modeling tool can replay a story one step at a time. section 8.5.2 section 8.5.4 section 8.5.3
