1 Lack of preparation

Event storming requires some preparation before the actual workshop. You need to have a clear goal, a facilitator, a diverse and motivated group of participants, and a suitable space and materials. Without these elements, you risk wasting time, losing focus, or missing important insights. To avoid this pitfall, make sure you define the scope and purpose of the event storming session, invite the right people from different perspectives and roles, and arrange a large and comfortable room with enough sticky notes, markers, and tape.

3 Too much consensus

Event storming is a collaborative technique, but that does not mean that everyone has to agree on everything. Trying to reach too much consensus can stifle creativity, diversity, and innovation. It can also lead to groupthink, compromise, or domination by some voices. To avoid this pitfall, encourage constructive feedback, questions, and challenges. Use different colors or shapes to mark different opinions or assumptions. And embrace the conflicts and gaps as opportunities to learn and improve.

4 Too much abstraction

Event storming is a technique for modeling the domain, not the implementation. Trying to abstract too much from the reality, such as using generic or technical terms, ignoring the context or the users, or imposing a predefined structure or pattern, can result in a poor or irrelevant design. To avoid this anti-pattern, use the language and the examples of the domain experts, stakeholders, and customers. Use personas, scenarios, or stories to illustrate the events and commands. And let the domain shape the design, not the other way around.

5 Too much isolation

Event storming is a technique for discovering and aligning the bounded contexts of the domain, not for designing them in isolation. Trying to isolate too much from the rest of the domain, such as ignoring the dependencies, interactions, or integrations between the contexts, can result in a fragmented or inconsistent design. To avoid this pitfall, use different colors or zones to identify and separate the bounded contexts. Use policies, processes, or sagas to describe how they communicate and coordinate. And validate and refine the design with the other contexts and stakeholders.

6 Too much finality

Event storming is a technique for starting and evolving the domain-driven design, not for ending it. Trying to treat the event storming output as a final or fixed design can result in a rigid or outdated design. To avoid this anti-pattern, treat the event storming output as a living and dynamic document. Use feedback loops, experiments, or prototypes to test and validate the design. And revisit and revise the design as the domain changes and grows.