Robert Reppel
Robert Reppel
Mar 10, 2019 2 min read

Event Storming Language: A Five Minute Intro

thumbnail for this post

TL;DR. Go to StoryStream and try the example.

We use a simple and (as it turns out after a year or two of using various versions of it in Real Life) easy to learn convention for representing event stormings as text. We call it ESL (Event Storming Language). It makes diagrams, but it also shows some potential for making nice APIs and assorted tooling.



… is a command. Usually, commands are actions users take, for example by clicking buttons.

Register-> : username,, firstname, lastname

… is a command with parameters. The ‘email’ parameter has an example value (‘’).


Events are what happens as a result of successfully executing a command.

User Registered

… is an event. Events can have properties, including example values:

User Registered : userId, username=joe, email, firstname, lastname


Information from events can be used to populate documents a.k.a. “read models”, a.k.a. (in a narrower sense) “stuff users see on the screen so they can make decisions about the next button to click”:

User Profile* 

Documents can have properties:

User Profile* : userId, username, email, firstname, lastname


For business rules / policies or other worthwhile info, there are comments:

// Users cannot register an email if the email is already in use by somebody else. 


Lastly, event stormings can have multiple workflows. (a.k.a. sequences of actions users or processes can take in a system) For example:

/// User Registration

Another example of a workflow could be …

/// User Deletes Account

And that’s about it.

Next Steps

Go to StoryStream and try some other examples:


You have mastered the ESL event storming language. It may change a bit in the future, but the design goal will remain the same: It can be learned in 10 minutes.