Event Storming Language: A Five Minute Intro
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@example.org, firstname, lastname
… is a command with parameters. The ‘email’ parameter has an example value (‘email@example.com’).
Events are what happens as a result of successfully executing a command.
… 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”:
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.
Go to StoryStream and try some other examples: