Event Modeling

Our methodology for going from requirements to application are based on the outcomes of event storming during the process of event modeling. Think of event storming as a series of brain storming sessions to help draw out and identify the events and other important components and operations of the system.

During event storming, we will model concepts such as Events, Commands, Queries, Aggregates, and Sagas. Using the Axon Framework design and architecture allows us to drive design in a direction to simplify implementation on top of the platform.

Event Modeling helps to create a transparent system for all departments in a business to be able to view how the system is going to work and what can be easily changed. It helps provide a simple solution to designing and evolving complex systems, and I highly recommend it. Once the design is completed, translating the model into code becomes easily manageable.

Prescriptive Methodology

We closely follow the 7 Step Workshop format outlined by Axon. The following is a high level overview.


  • In this section the user is given the ability to affect/change the system.


  • What events were (notice that events are always in past tense) stored in the system as we move forward in time.


  • The information needs to be available to the user (dates for a lesson are available on the calendar for a student to book them).
  • They can also be retrieved at a later date.


  • This is the visual part of the ‘story-telling’ or the visual of the web page. This part comes at the top of the model.
  • The swim-lanes show different people who are interacting with our system.
  • At this point we have enough information to work on the UI/UX part.

1. Brainstorming

Only state changing events need to be specified using past tense wording

2. The Plot

  • The story line (Events)
  • The concept of TIME is introduced in this step and the events are carefully planned based on the timeline.

3. Storyboard

  • Wireframe (the second moving part) is shown from the user’s perspective on the system that represents the source and destination of the information
  • UI: Wireframes are usually put on top of the blue print

4. Identify Input (Commands)

  • Command is the intent to change the state of a system
  • The transactions are both on the business and technical sides

5. Identify Output (Views or Read-Models)

  • Access to information or data is key
  • We want to know if a payment went through on a certain pay period
  • As stated above, views are passive, and they cannot change the event after it’s been stored in the system

6. Organizing events into swimlanes

  • Allow a system/app to exist as a set of autonomous parts that can be owned and managed by different teams.

7. Elaborate on scenarios

  • Given-When-Then or Given-Then allows for rapid review by various representatives - GIVEN events = current state - WHEN new COMMANDS = new intent - THEN new events are published