A domain event records a significant occurrence in a business scenario that stakeholders consider relevant. Phrase it in the past tense: it names something that has already happened, rather than an action that may happen next. section 2.3.2
Domain events give a group a shared way to explore business activity before technical concerns take over. In EventStorming, participants first capture every relevant event they can identify, then use those events to make the scenario visible and discussable. section 2.3.2 section 2.6
Use domain events to turn a business conversation into a timeline:
- Choose a scenario or set of scenarios to explore; several scenarios can be organized separately later. section 2.3.2
- Have every participant write the business-relevant occurrences they recognize, without waiting for perfect wording. section 2.3.2
- Distinguish completed events from present or future actions; refine wording after ideas are visible. section 2.3.2
- Merge individual views into a shared timeline and decide which events belong inside the storyline. section 2.3.2
- Defer technical occurrences, such as a lost database connection, until the business scenario is understood well enough. section 2.3.2
Cinema ticketing
For a cinema scenario, “Tickets are Purchased,” “Ticket are Paid,” and “Seats are Reserved” are domain events because they matter to stakeholders. “Database Connection Lost” and “DDOS Attacked” are technical occurrences, not initial business events for the scenario. section 2.3.2
A simple facilitation rule helps distribute authorship: “You think it, you write it.” In refinement or requirements conversations, let people place domain events on a timeline so their mental models become visible to the group. section 2.4
Figure 2.16 Example of how to proceed with enforcing the timeline in EventStorming where the groups merge all of their own models into one timeline of the scenario. We added a pivotal domain event where we can now decide what is inside our storyline and what happened before.
Use the timeline view to compare separate event lists, merge them into one scenario, and identify a pivotal event that sets the boundary of the story. section 2.3.2
