The basic idea behind EventStorming is that it gives a straightforward modeling notation that is used to visualize the behavior of the system in a way that everyone can understand. This approach creates visibility, increases engagement, allows involving people who would otherwise be anxious about any participation in a modeling session at all or putting anything on a whiteboard if they attend.

Taking behavior as the central aspect of the domain knowledge, the whole EventStorming exercise is about finding out how the business works. In general, we could postulate that each system at any given moment of time is found in a particular state. This state can change when actors that interact with the system do something. Actions of those actors cause the system to change state, so we can see that something has happened and now we need to deal with a new situation.

Let's look at a simple example of someone paying their bill using internet banking:

As you can see here, from the person's point of view, the amount of money in her account decreased, the payment is complete, and the bill is considered paid and can be thrown away. From the recipient's point of view, however, the bill is considered paid when they get the money and can match this payment with an open bill by using an invoice number or some magic payment reference that was mentioned on the bill and the payment.

Each action performed by actors in these systems made some state transitions. The payment order was created and signed. The amount was deducted from the payer's account. The amount was then added to the payee's account. The bill was marked as paid. All these operations became facts of life, and unless we got a time machine, we could not reverse them. If the payee discovers that the bill has already been paid, they cannot just reverse everything. They need to send the money back by initiating a new payment.

These facts are known as domain events. It is the most basic and also most important concept that EventStorming is dealing with. It is why it is called the EventStorming. The idea of domain events is not alien to anyone. Facts of life are something that people can quickly grasp. It is something that happened. Not something that someone wanted to do. Not a feature. Not a form or a button. Each domain event represents a fact, a change in the system we are trying to model.

Therefore, the first part of our modeling language would be to make a notion for domain events. Each concept in EventStorming is represented as a sticky note of specific color. The color aspect is essential because as we go along and bring more thoughts to the model, we need to keep colors consistently represent the same ideas across the model to avoid confusion.

The original suggestion of Alberto is to use orange sticky notes to represent domain events. A simplest possible model could look like this:

These are two domain events occurred in sequence—first, a customer paid by using a credit or debit card; then their order was confirmed. We can identify this as some e-commerce domain. There is nothing special about sentences written on sticky notes, except one crucial rule: events must have a subject (noun) and a predicate (verb). The verb must be in the past tense, indicating that something has happened and it became a fact.

If we get back to the bill payment example, we could try figuring out what events we would find there:

There are a couple of things that you might immediately notice. First is that domain events are following the timeline. I am quite logical because facts are representing subsequent changes in the system and therefore happen in particular order. For example, the payment is not approved before it is signed. Some things can happen in parallel, like debiting and crediting accounts can occur at the same time, as soon as the payment order is approved, which might mean that the bank is confident that the payer has enough funds to complete the payment.

The second thing is that we do not have only one system here. Indeed, we are modelling the whole process, but there are at least three parts that we can clearly distinguish the user-facing internet bank, which allows to create and sign payment orders; the baking back-office, which completes the transaction; the payee's own payment-to-bill matching system that, by the way, could be completely manual.