Domain Event Discovery

Purpose

Domain Event Discovery, created by Alberto Brandolini, is a workshop format for exploring complex business domains rapidly. By placing domain events on a timeline, the group builds a shared mental model, discovers bounded contexts, and identifies process pain points — all in a matter of hours.

At a glance

How to run

1. Chaotic exploration (30 min) — Everyone writes domain events on orange sticky notes (past tense: "Order placed," "Payment received"). Place them roughly in chronological order on the wall.
2. Enforce timeline (20 min) — Sort events into a clear left-to-right timeline. Identify parallel flows.
3. Add pain points and questions (15 min) — Use red/hot-pink stickies for problems and open questions.
4. Add commands and actors (20 min) — Blue stickies for commands that trigger events. Yellow stickies for the actors (people or systems) who issue commands.
5. Add policies and read models (20 min) — Purple stickies for automation policies ("When X then Y"). Green stickies for read models / views.
6. Identify aggregates (20 min) — Group events and commands around aggregates (the domain objects that enforce consistency).
7. Discover bounded contexts (15 min) — Draw boundaries around clusters of aggregates that belong together.
8. Debrief and next steps (20 min) — Summarize discoveries. Identify follow-up actions: design sessions, spikes, or process changes.

Materials needed

• Very long wall (8+ meters) or infinite-canvas digital tool (Miro, Mural)
• Sticky notes in 6 colours (orange, blue, yellow, purple, green, red/pink)
• Markers (one per person)
• Legend poster showing sticky colours and their meaning
• Timer

Pitfalls & common mistakes

• Too few domain experts — Developers alone cannot discover the domain. Business people must be in the room.
• Wall too small — Domain event discovery needs space. A cramped wall stifles exploration.
• Getting stuck on notation — The colour system is a guide, not a law. Adapt if needed.
• No follow-up — The wall is a snapshot. Transfer insights to design docs, domain models, or backlog items.

Inclusion & accessibility

• Provide a legend and brief orientation for newcomers.
• Use large sticky notes and thick markers so text is readable from a distance.
• For remote sessions, use an infinite-canvas tool with guided facilitation.
• Allow participants to type instead of handwrite for accessibility.

Variations

• Big Picture domain event discovery — Events, timeline, hotspots, people and external systems only; commands, policies, read models and aggregates belong to Process and Design Level.
• Process-level domain event discovery — Zoom into one bounded context for detailed design.
• Design-level domain event discovery — Focus on aggregates and command handlers for implementation.
• Domain event discovery for existing systems — Map an existing system to identify improvement opportunities.

When NOT to use this

• For simple CRUD applications with no meaningful domain logic.
• If domain experts are unavailable or unwilling — the output will be fiction.
• If the team is looking for a technical architecture exercise — use architecture decision records or C4 modelling.

Source & further reading

• Brandolini, A. (2021). *Event Storming*. Leanpub.
• Vernon, V. (2013). *Implementing Domain-Driven Design*. Addison-Wesley.