6

I recently ran an Event Storming session and a scenario came up where we needed to represent a loop within the process. The events and commands needed to happen iteratively until a condition is meant in order for the process to continue to the next event.

Representing the command and event only once in a linear line alongside everything else looked confusing and misleading.

I can’t find any material on how to represent a loop in Event Storming. This is really surprising to me since it is a concept found in many processes. Makes me think I’m probably looking at the whole thing wrong,

Any insight is appreciated!

3
  • I'm unfamiliar with Event Storming, but found this example on Google which uses arrows to chain events together: contextmapper.org/img/lakeside-mutual-event-storming-result.jpg Given that it seems event storming is intended to be a loose/informal method akin to brainstorming, (the output of the session being attendees' understanding), I would think an appropriate way to represent a loop would be an arrow back to an earlier stage/step in the process. Mar 30, 2021 at 12:31
  • 1
    I guess loops in an Event Storming session are often "modeling smells". A loop in a sequence of business events could be something which means to go back to a previous state - but that is almost always possible, hence not worth modeling. Waiting for a condition, however, can often be modeled without a loop (see link of my former comment), otherwise one would probably be on a too low level of abstraction. If you think in your specific case a loop would make sense, present the case (or a comparable situation) in your question, so we can discuss it if a loop is really required.
    – Doc Brown
    Mar 30, 2021 at 13:21

1 Answer 1

9

Event storming is not a notation

Event storming is not a notation. It's a very interactive team practice based on sticky notes put on a board and rearranged as the modeling progresses.

It starts with the identification of the events, seeks for the commands that cause them, and then looks at the involved aggregates/entities. And a couple of other things not directly relevant for your question.

The event stickers are arranged/rearanged according to an intuitive chronological order. Parrallel events are usually stacked vertically. When commands are added, the narrative gets some flesh and the flows tend after a while to stabilize. That's the moment some arrows can be added to better identify alternatives, parralel flows, and relations between distinct groups.

And the loop?

In event storming, there are no loops and no control flow. The backbone is made only of events. The loop is what emerges when an event is triggered that already appeared upstream, or when the same events repeat successively.

In addition, if you start to draw attention of participants on loops and control flows, you risk to glitch into a flowchart-driven thinking and miss the benefits of event storming.

Fortunately, there are intuitive practices with stickky notes, that help you keep the focus on the events, but yet capture these special loop situation without puting them too much in the fore ground. For example:

  • put a comment note on a command to explain what happens .
  • put a comment note on an event if a single event is repeating successively. Typically a 🔁
  • use duplicate events. To avoid the risk of confusion, put a special symbol on the event sticker. This approach is consistent with the usual ES practices. When a duplicate is introduced or detected, it also highlights an area where care is needed.

If looping consideration appear at a later stage, you can of course simply draw an arrow backwards. But caution: If you start too early with arrows on the board, you might start to freeze the game: it becomes much more difficult to move the stickers. This may lead to less willingness to rearrange and ultimately creates friction in the free flow of ideas.

4
  • 2
    Very good explanation!
    – Rik D
    Mar 30, 2021 at 19:40
  • But ... "if this (koff, koff) old programmer might dare to say," far worse(!) than any "spaghetti code!" Don't design software this way. Your grandchildren will hate you for it. Mar 30, 2021 at 20:04
  • @MikeRobinson :-) I remember having worked with low level event loops, and it was indeed very tricky. Especially as not all the vents were completely independent. But domain events are at a very different level of abstraction. Moreover, in the storming workshop, the events are unrolled to make a chronological perspective that is really easy to understand. I don't think that it's a fatality to have unreadable code with event processing ;-) By the way, some CEP gurus pretend that every company is just an efficient distributed event processing engine.
    – Christophe
    Mar 30, 2021 at 21:24
  • Wow, great answer thank you! So as an example: for every item in an order, a warehouse picker needs to locate and scan that item then load it on a rack. If I needed to model that process but show that it loops, perhaps I could model it once with the 🔁 next to it, then have an event that says "All items picked" or something? Mar 31, 2021 at 23:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.