Event storming brzmi jak srebrna kula – warsztaty, które w jeden dzień mają odkryć całą domenę i wygenerować idealną architekturę zdarzeniową. W teorii piękne, w praktyce często kończy się stertą żółtych karteczek i poczuciem straconego czasu. Dlaczego? Bo popełniamy te same błędy, które zamieniają potężne narzędzie w kosztowną zabawę.
1. Myślenie, że event storming to tylko o zdarzeniach
Najczęstsza pułapka – skupiamy się wyłącznie na definiowaniu zdarzeń domenowych („Zamówienie złożone”, „Płatność potwierdzona”) i zapominamy o komendach, aktorach i regułach biznesowych. Efekt? Po warsztatach mamy listę zdarzeń, ale nie wiemy, co je wywołuje ani jakie są konsekwencje.
Przykład z życia: Firma budująca platformę SaaS do zarządzania subskrypcjami. Po event stormingu mieli 47 zdarzeń, ale brakowało im definicji komendy „Anuluj subskrypcję” – kto może to zrobić? W jakich okolicznościach? Co się dzieje z danymi? Skutek: architektura wymagała poprawek już po pierwszym sprincie.
Jak to robić dobrze: Event storming to cztery kolory: pomarańczowy (komendy), niebieski (zdarzenia), żółty (aktora) i zielony (reguły biznesowe). Musisz mieć je wszystkie. Bez komend nie wiesz, co inicjuje zdarzenia, a bez reguł nie wiesz, dlaczego coś się dzieje.
2. Brak moderacji i dryfowanie w szczegóły
Drugi błąd – zbyt szybkie schodzenie na poziom implementacji. Zamiast mapować proces biznesowy, zespół zaczyna dyskutować o konkretnych technologiach: „Czy użyjemy Kafka czy RabbitMQ?”, „Jak obsłużymy retransmisję?”. To zabija flow i marnuje czas.
Przykład z życia: Startup fintech na warsztacie event stormingu. Po 20 minutach zamiast omawiać zdarzenia, zespół wdał się w dyskusję o formatach wiadomości i gwarancji dostarczenia. Moderator nie zareagował. Efekt: wyszli z warsztatów z listą wymagań technicznych, ale bez mapy procesów.
Jak to robić dobrze: Ustal na początku: najpierw mapujemy domenę, technologię zostawiamy na później. Moderator ma wyciągać kartkę „Parking” dla tematów technicznych i wracać do głównego wątku. Dbaj o czas – 2-3 godziny na sesję, potem podsumowanie.
3. Ignorowanie bounded contextów
Trzeci powód porażek to myślenie, że event storming pokaże jeden uniwersalny model. W rzeczywistości różne części systemu mają różne konteksty – to, co jest zdarzeniem w module zamówień, może być komendą w module płatności.
Przykład z życia: E-commerce próbował zrobić jeden event storming dla całego systemu. Okazało się, że „Zamówienie złożone” w panelu klienta znaczy co innego niż w module logistyki. Ignorowanie granic kontekstów doprowadziło do sprzeczności i konieczności przepisania połowy integracji.
Jak to robić dobrze: Przed warsztatami zdefiniuj wstępne bounded contexty – np. „Zamówienia”, „Płatności”, „Wysyłka”. Każdy kontekst stormuj osobno, potem połącz zdarzeniami granicznymi. To pozwoli zachować spójność bez mieszania znaczeń.
Podsumowanie
Event storming to potężne narzędzie, ale tylko w rękach świadomego zespołu. Unikaj pułapek: pamiętaj o komendach i regułach, pilnuj moderacji i szanuj granice kontekstów. Jeśli zrobisz to dobrze, dostaniesz nie tylko mapę domeny, ale i fundament pod skalowalną architekturę. Jeśli źle – stracisz czas i pieniądze.
A Ty? Robiłeś event storming? Jaki był Twój największy błąd?
