Event Storming Language: A Five Minute Intro
(Updated: )
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.
Commands
Register->
… is a command. Usually, commands are actions users take, for example by clicking buttons.
Register-> : username, email=joe@somemail.com, firstname, lastname
… is a command with parameters. The ‘email’ parameter has an example value (‘joe@somemail.com’).
Events
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
Documents
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
Comments
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.
Workflows
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: