At which moment should event storming be used?

Question

I've recently seem event storming as a quite reasonable way to get understanding form a domain, in order to build a domain model. We understand the events in the domain, which for the domain experts ends up boiling down to just telling the business processes they are used to in their everyday life, then we find out the commands that might rise these events, and finally the aggregates.

By everything I've read it seems a very viable way to understand the bussines rules and business logic.

But there are many points that I still don't understand. The first would be: when should event storming be used in the course of the project?

My doubt seems to be mainly regarding event storming and requirements gathering. Should it be done just after requirements gathering, or it should be viewed also as a technique of requirements gathering?

In summary, in what stage of the project should we use the technique of event storming?

Whoever downvoted this without a comment: this question clearly shows research effort, it is well written and 100% on-topic. Please consider to retract. — Doc Brown, Jun 03 '18 at 17:39

score 3 · Answer 1 · answered Jun 06 '18 at 09:12

It depends on the context and on the results you want to achieve. A typical Big Picture EventStorming usually happens at project kickoff, and involves many domain experts in a collaborative learning and modelling effort.

Smaller, more focused, formats require fewer domain experts but they go deeper in modelling process and/or software mechanics. They may typically happen at the beginning of an iteration or when exploring critical features.

score 2 · Accepted Answer · edited Jun 03 '18 at 19:27

Event storming is a technique to reach a common understanding of the current situation in a domain, or a part of it. Steps in an event flow do not necessarily correspond to new software to be created, they could also include steps which are already supported by existing software, or purely manual steps.

This kind of understanding is necessary before it makes sense to start gathering requirements (which does not mean you cannot start with the latter within the same meeting). It helps to answer questions like

which steps in an event flow shall become supported by some software or automation?
which steps are currently supported by some software, but shall be handled differently, maybe in a more efficient manner?
where can the event flow be changed to make things more efficient?

We have often done such kind of brainstorming over the last decade in our company, whenever we needed to discuss where in a workflow a change should or could happen, before making decisions for taking further actions.

However we never called it "event storming" (actually I am not sure if I ever heard this term before). We typically put the focus on the data flow in our processing pipelines, or workflows, but it is essentially the same what Wikipedia describes under "event storming". You don't need Post-It notes for this, an erasable whiteboard works as well.

As a side note: if you want your to get your domain experts on it, I recommend to avoid fancy brand names and too much formal rules you read in some DDD book - brainstormings like this were not invented by those DDD guys, these techniques are probably older than you and me together.

"Older than you and me together". A team working a whiteboard aways did remind me of cave paintings. — candied_orange, Jun 03 '18 at 19:29
@candied_orange: so you think Post-Its are more modern than a white board, and thus clearly superior ? ;-) — Doc Brown, Jun 04 '18 at 05:21
I don't want to be pedantic here, but if you're thinking EventStorming then the sentence: _"You don't need Post-It notes for this, an erasable whiteboard works as well."_ does not compute. :-) Parallel modelling is quintessential to EventStorming and cannot be achieved on a whiteboard. (So ...yes post-its ARE superior!) You can have really good collective modelling sessions with a whiteboard, and brainstormings too. They're just not EventStorming. :-) — ZioBrando, Jun 08 '18 at 13:20

score 1 · Answer 3 · edited Jun 03 '18 at 16:50

Seems exactly like requirements gathering to me. Just done with post it notes. I've advocated something similar without bothering to give it a marketing name.

when should event storming be used in the course of the project?

When the underlying business changes.

A domain event is just something the domain expert cares about. When their cares change you need to address them.

Of course you also have to do this when you first start your project. You learn most of these events then.

At which moment should event storming be used?

3 Answers3