EventStorming On An Infinite Canvas
EventStorming is a collaborative way to explore a business domain by modelling the important things that happen, the actions that cause them, and the rules that connect them.
Why Code Genie Starts With Events
Events are shared facts. People from different roles can usually agree that Payment Received, Claim Approved, or Vehicle Assigned happened, even if they disagree about implementation. That makes events a strong starting point for discovery.
On a Code Genie canvas, event modelling is not disposable workshop output. It becomes input to generated software, documentation, test cases, and hosted workflows.
Typical Flow
- Place domain events in rough timeline order.
- Add hotspots where the team has questions, disagreements, risk, or missing knowledge.
- Add commands that cause events.
- Add actors and user interfaces that issue commands.
- Add aggregates that decide whether commands are valid.
- Add policies that react to events and trigger more commands.
- Add read models and queries that provide decision-making information.
- Group related model areas into bounded contexts.
Common Block Colours
Teams often use colours from EventStorming practice, such as orange for events, blue for commands, yellow for aggregates, purple for policies, pink for external systems, and green for read models or information. Code Genie may let a workspace customize colours, but the meaning of each block is more important than the colour.
Big Picture, Process, and Software Design
Use the same canvas at different levels of detail.
- Big picture explores a wide business area, discovers major events, and reveals boundaries.
- Process modelling follows one workflow in more detail, including actors, decisions, and handoffs.
- Software design refines commands, aggregates, policies, read models, integration events, and generation settings.
Workshop Habits That Improve Generation
- Name events in the past tense.
- Name commands as imperative actions.
- Keep business language visible; do not let technical labels take over too early.
- Mark unknowns as hotspots instead of silently guessing.
- Connect every generated command to an actor, interface, policy, or integration source.
- Review aggregate boundaries before code generation.