EventStorming at Aardling

EventStorming at Aardling

EventStorming is a very popular modelling technique first introduced by Alberto Brandolini. At Aardling, we use a somewhat different approach to the “Brandolini” style of EventStorming. Let me explain our style and why we prefer to use it.

This blog is not a tutorial, but rather an explanation of how we practice EventStorming. Watch our modelling video series for a more in-depth look at how we model.

To begin with, these are the basic building blocks we use in EventStorming:

💡 Tip: Whiteboard tools, like Miro or Lucid, allow you to use a stack of sticky notes, making it easier for participants to add new ones.

Domain Events

👉 A domain event is something relevant to the domain, expressed in the past tense. Events represent facts, things that have happened. For example, "Invoice Was Paid", "Subscription Renewed".

When we start modelling, we use events to represent the problem space. Once we are in a workshop with domain experts, we visualise the events to tell a coherent story. Modelling always begins with lots of uncertainty. Stick with the process, and what will soon emerge is a rich, shared understanding of the problem space.

Once we’re happy with what we’ve learned and want to explore it further, we add commands and constraints.

Adding commands and constraints

👉 Commands, sometimes referred to as actions, express an intent to do something. Expressed in the imperative. A user or a system wants to do something. Examples: “Pay invoice”, “Renew Subscription”.

👉 Constraints express a decision, condition, or anything that influences the outcome of a command or an event.

To start with, our EventStorm will look something like this. Orange stickies here represent the events.

Now let's introduce the following pattern:

First, we capture the action (command) someone, or something, wants to trigger. But in order to proceed, we need to consider the business constraints. If they pass, a decision is made (event).

For example, reserve table → table must be available → table reserved

Of course, there might be multiple constraints which we will represent like this:

Or, if we don’t care about the order of the constraints, like this:

When we think that there are no constraints between the trigger and the outcome, we make that explicit by introducing the Always constraint. So document that a conversation was had and no constraints were found like this:

Conversations tend to iron out misunderstandings. Often in modelling sessions, you'll have conversations like this:

"Always, when this happens, then that happens …”

”Is that really always what happens?”

“Yes”

”Oh, and what about when this happens, then that happens…?”

"Ah, you’re correct, in that case, it should actually fail”

We've found that removing the always constraint often removes the conversation altogether, which results in missing constraints.

One final pattern that to consider adding is this:

• event → constraint → event

  or

• event → constraint → command

The definition of a constraint says it is anything that influences the outcome of a trigger. A trigger can be an event as well, so you could have examples like this:

What happens if the constraint fails? In that case, we model both paths:

This is a very high-level overview of our EventStorming process, but it includes the fundamental building blocks you will need to start. Try it out in your next session and see how it goes. The best way to improve your EventStorming skills is to practice and to incorporate what you learned into your next session.

One final tip would be to add your own visual language to express things that are important in your context, for example, maybe you want to use different colours for different systems emitting the event, or for a different colour for summary events.

Don’t overthink it, but go for it.

If you have questions or feedback, find me on LinkedIn/BlueSky, or you can write to us.