Na początku uczestnicy umieszczają pomarańczowe karteczki ze zdarzeniami domenowymi na ścianie. Zależy nam tutaj, aby tej wiedzy pojawiło się jak najwięcej, dlatego nie przejmujemy się duplikacją lub chronologią. Aczkolwiek nie naciskajmy, aby pojawiły się tutaj koniecznie wszystkie możliwe zdarzenia – będą one dodawane również sukcesywnie w trakcie kolejnych etapów. Każdy z uczestników w tym momencie będzie najpewniej zajmował się fragmentem, który zna najlepiej. Kiedy dojdzie do konfliktów związanych z tym, że nie wiadomo jak jakiś podsystem ma działać, zaznaczamy to karteczką zwaną hotspotem (z ang. hot spot – gorące miejsce) lub karteczką system zewnętrzny jeśli dotyczy to zewnętrznej integracji. Ważne jest to, abyśmy skupili się na zdarzeniach, które dotyczą naszego systemu, nie na tych, które dzieją się w świecie rzeczywistym lub w systemie towarzyszącym – choć i te warto umieścić na tablicy, aby uzyskać lepszy kontekst. Tę część nazywamy chaotyczną eksploracją [DevStyleStolarczyk]. Czasem można ją potraktować jako właściwą rozgrzewkę przed następnymi etapami mającą na celu zapoznanie się uczestników z ze sobą nawzajem [kolinskaEventStormingGuide].

Następnie na tablicy wprowadzamy oś czasu: układamy karteczki zgodnie z chronologią i wstępnie grupujemy w podsystemy. Przy okazji można usunąć duplikaty i ujednolicić język niektórych karteczek.

Te dwa elementy dają nam część zwaną Big picture. Po czym przechodzimy do Process Level. W tym momencie będziemy wchodzić w szczegóły związane z każdym ze zdarzeń poprzez dodanie karteczek z:

Dopiero mając tak usystematyzowany system zdarzeń, przechodzimy do szczegółowego wyszukiwania możliwości i problemów, które również oznaczamy jako gorące miejsca. Na koniec wybieramy zagadnienie, którym będziemy chcieli się zająć – po krótkiej przerwie lub na osobnym spotkaniu [DevStyleStolarczyk].

Na koniec przechodzimy do etapu Desing Level, na którym tworzymy model, który można przenieść bezpośrednio do kodu.

W tej sekcji pokażę mocno uproszczony i wymyślony przykład w celu zachowania pewnej spójności. Ilustrację bardziej rozbudowanej sesji Event Stormingu planuję pokazać w przyszłości w osobnej serii artykułów.

Jak widać, na początku napisaliśmy możliwie dużo zdarzeń. Pojawiły się przy tym dwie wątpliwości oraz uściśliliśmy słownictwo, które mogło być problematyczne w trakcie warsztatów. Jedyny system, który nam się pojawił to Facebook jako dostawca logowania – został tutaj umieszczony, ponieważ jest systemem zewnętrznym, od którego zależy nasz przepływ.

Następnie postępujemy zgodnie z tym, co zostało napisane wcześniej: dodajemy pozostałe karteczki. Dobrze jest dodać je wszystkie od razu, ponieważ dodawanie ich pojedynczo może stanowczo przedłużyć warsztat i doprowadzić do lekkiej irytacji uczestników ciągłym przekładaniem karteczek.

Rozbudowaliśmy logowanie o rejestrację oraz przypadek, w którym próbował zalogować się użytkownik, który jeszcze nie jest w naszej bazie. Każdą swoją akcję mógł podjąć na podstawie pewnego widoku, z którego wykonywał polecenie na pewnym systemie, co generuje zdarzenia. Każde z nich może wygenerować kolejny widok lub politykę/reakcję, gdzie ta znów może kontynuować ciąg przyczynowo skutkowy.

Opis każdego typu karteczki znajduje się poniżej.

Jak już napisałem we wstępie, zdarzenie domenowe reprezentuje fakt nieodwracalny. Mówiąc, że fakt jest nieodwracalny, znaczy to, że gdy użytkownik kupił produkt – nie może już tego cofnąć (maszyna pakowania i nadawania przesyłki już ruszyła), może on rozpocząć procedurę przeciwną, to znaczy zwrotu zakupionego produktu. Co niezwykle ważne, fakty zapisujemy za pomocą formy przeszłej, czyli „użytkownik zapłacił za produkt”, „użytkownik zgłosił żądanie zwrotu zakupu”. Pozwala to uciąć dywagację na temat tego, co jeśli zdarzenie się nie udało, lub zaszło częściowo – w takim przypadku mamy do czynienia z innym zdarzeniem (na przykład: „użytkownik zapłaci połowę kwoty”). Zdarzenie domenowe musi być zrozumiałe przez ludzi nietechnicznych więc w konsekwencji nie może ono odnosić się do szczegółów implementacyjnych. Mimo iż w przykładach znajduje się kto i co, zrobił, co zwiększa czytelność, jednak nie zapominajmy, że twórca danego zdarzenia zostanie jasno określony w dalszym etapie za pomocą karteczki aktora [DDDNetCore].

Mimo iż piszę o tym, że fakt już się stał, to nie należy się bać dodawania zdarzeń, które reprezentują pomysły i funkcje zaplanowane do realizacji w przyszłości. Dobrze jest je odpowiednio oznaczyć, na przykład, poprzez inny kolor karteczki.

Jest to zazwyczaj fioletowa lub jaskraworóżowa karteczka (ważne, aby miała wyróżniający się kolor), która służy do oznaczania miejsc spornych, gdzie znalezienie odpowiedzi w trakcie warsztatów nie jest możliwe [bourgauDetailedAgendaDDD2018].

Początkowo, podczas chaotycznej eksploracji, karteczka ta służy do określania systemów zewnętrznych, które generują zdarzenia dla naszego systemu. Następnie, w trakcie porządkowania, będziemy na niej zapisywać nasze systemy, takie jak „wyszukiwarka”, „użytkownicy”, „zamówienia”. Uzupełnienie tej karteczki pozwoli nam jasno zobaczyć, które zdarzenia i operacje są wykonywane w tym samym miejscu, a które są w jakiś sposób niezależne. Doprowadzi nas to do wyodrębnienia subdomen, które mogą później posłużyć jako punkt zaczepienia dla luźniejszej architektury aplikacji.

Z umieszczeniem słowa domenowego spotkałem się raz ([bourgauDetailedAgendaDDD2018]) i traktuję je jako rozszerzenie podstawowej notacji Event Stormingu. Niemniej, uważam je za ciekawy, acz nieobowiązkowy element, gdyż w niektórych projektach może pojawić się problem ze słownictwem szczegółowym.

Aktor, mimo iż brzmi to ludzko, to nie musi być to człowiek – jest to karteczka, która reprezentuje, kto może wyzwolić daną akcję. Także może to być zarówno człowiek (na przykład poprzez interakcję z aplikacją), jak i na przykład czujka zalania mieszkania może wyzwolić alarm bądź powiadomienie.

Polecenie służy do pokazania zamiaru. Umieszczenie ich na tablicy powoduje, że łatwiej zobaczyć jakie zdarzenia mogą zostać wykonane w przypadku, kiedy zamiar się nie powiedzie, lub powiedzie się częściowo. Doklejanie karteczek z poleceniem może wydawać się czysto mechaniczne, jednak nie musi takie być, dzięki metodzie 0, 50, 100 i 150 (więcej o niej w sekcji W trakcie warsztatów). Dlatego zaczynamy od zdarzeń, a nie od poleceń, ponieważ taka kolejność może prowadzić do zbytniego skupienia się nad nowymi funkcjami [kolinskaEventStormingGuide].

Reakcja (czasem zwana również polityką) pozwala nam zaprezentować to, jak system reaguje automatycznie na pewne zdarzenia. Łatwo rozpoznać reakcję po tym, że zaczynamy używać składki "kiedy, …, to…". Ważne jest to, aby karteczka ta trafiała pomiędzy zdarzeniem, którego jest adresatem, oraz poleceniem, które ma wykonać [EventStormingDomaindriven2019].

W widokach, we wszelkiej literaturze, znalazłem najmniej. Jednak uważam je za tyle ciekawe, że pozwalają nam powiedzieć, czy dany widok istnieje w naszej aplikacji oraz, czy pewne rzeczy są uruchamiane ręcznie, czy też automatycznie (przed widokiem stoi człowiek a za nim polecenie).

Widokowi może towarzyszyć rysunek poglądowy. Dodajemy je wtedy, gdy osoby od doświadczeń użytkownika (z ang. user experience, zapisywane skrótem UX) uznają jakiś element za szalenie istotny. Taki obrazek pozwala na lepszą komunikację pomiędzy UXowcami a osobami odpowiedzialnymi za wygląd aplikacji, gdyż tym drugim pokazano, co jest najważniejsze.

Świat zewnętrzny, podobnie jak rysunek poglądowy znalazł się tylko na notacji. Niemniej uważam, że może być on ważny, zwłaszcza w przypadkach, gdy nasz system silnie operuje na tym, co dzieje się w świecie rzeczywistym. Karteczki, które mogłyby trafić pod ten szyld, powinny reprezentować swojego rodzaju zdarzenia (być sformułowane w przeszłej formie), gdyż to właśnie czasowniki napędzają nasz świat i go zmieniają, rzeczowniki natomiast stoją w miejscu.

W trakcie warsztatów niezwykle problematyczna może być ilość miejsca, której będziesz potrzebować do zaprezentowania wszystkich zdarzeń. Dlatego zawczasu zadbaj o bardzo dużo przestrzeni i odpowiednią przyczepność karteczek do ściany. Jak podaje Zimarev warto kupić rolkę papieru do plotera, którą umocujesz jako podkład, w przypadku, gdy goła ściana nie jest w stanie zapewnić odpowiedniej przyczepności [DDDNetCore].

Dlaczego to takie ważne? Ponieważ jak się okazuje, gdy ludziom zacznie brakować miejsca, to zaczną się ograniczać ze swoją kreatywnością. Może się to skończyć tym, że część systemu w ogóle nie zostanie za modelowana, gdyż zostanie uznana za nieważną, a z racji ograniczonego miejsca, pominięta.

Dlatego sala wybrana do warsztatów Event Storming powinna być jak największa. W skrajnym przypadku można do tego wykorzystać korytarz, jednak upewnij się, że w trakcie, gdy będziesz go wykorzystywać, nie będzie przechodzić tamtędy duża ilość osób, co może rozpraszać uczestników.

Innym pomysłem może być działanie hybrydowe – uczestnicy siadają w jednej sali z własnymi komputerami, na których będą pracować. Dobrze, aby znajdował się w niej też jeden duży wyświetlacz dla prowadzącego. Następnie wszyscy równocześnie działają na jednej tablicy, na przykład przy pomocy oprogramowania https://miro.com/. Dlaczego mówię o siedzeniu w jednej sali? W trakcie warsztatów jest niesamowita ilość dyskusji, która wydaje się niemożliwa przy użyciu tradycyjnych form pracy i komunikacji zdalnej, gdzie jedna osoba mówi, a reszta musi słuchać.

W celu uprzedniego przygotowania sali warto przyjść do niej nawet 30 minut przed planowanym startem. Rzeczy, które trzeba zrobić to:

Kiedy wszyscy już się zbiorą i warsztaty się zaczną nie zapomnij o:

Zauważyłem, że niezwykle ważne jest, aby przedstawić całość notacji uczestnikom warsztatów. Nie próbuj „chować” przed nimi tego, co będą robić w późniejszych etapach – pozwoli im to od razu układać karteczki w większych odstępach oraz załapać kontekst tego, co będą robić. Jedną z formą przedstawienia notacji, z którą się spotkałem, jest poproszenie jednego z uczestników o to, aby przedstawił, co widzi na rysunku. Jeśli czegoś nie rozumie, może zadawać pytania prowadzącemu.

Z racji, że Event Storming to warsztat grupowy, gdzie wszyscy powinni brać udział, należy zachęcić ludzi do tego, aby sami zapisywali zdarzenia na ścianie. Aby to osiągnąć, należy zacząć od siebie – zapisz karteczkę jednym zdarzeniem, które znajduje się gdzieś w środku systemu, np. „użytkownik dodał przedmiot do koszyka”. Jest to niezwykle ważne, aby nie próbować zaczynać od początku lub od końca, gdyż zawsze będzie coś wcześniej i później. Dzięki takiemu podejściu można próbować zachęcić uczestników, aby zapisali zdarzenia, które następują lub są przed twoim [DDDNetCore][bourgauHowPrepareDDD2018].

Jak zostało to powiedziane we wstępie, zajmiemy dwoma zasadniczymi częściami warsztatów Event Stormign: Big Picture i Process Level. W warsztatach niezwykle ważne jest to, aby udział brali wszyscy uczestnicy, przez to prowadzący powinien ich obserwować i dawać wskazówki, a nie próbować kierować całością dyskusji.

W trakcie warsztatów, niezależnie od etapu, zwróć szczególną uwagę na to, że:

Jeśli natomiast widzisz, że dyskusja powoli się wypala, to możesz spróbować dwóch sposobów:

Podczas porządkowania tablicy po pierwszym etapie burzy mózgów może pojawic się wątpliwość, czy dane zdarzenie należy do naszego systemu, czy też nie. Wcześniej już wspomniany Mateusz Gil zaprezentował podział na 4 poziomy (więcej na YouTube) [DevStyleStolarczyk]:

Podobno ludzki mózg uwielbia historię, dlatego w celu utrwalenia treści, które pojawiły się w trakcie warsztatów, warto poprosić któregoś z uczestników (lub wspólnie całą grupą), aby opowiedział historię, która dzieje się od początku do końca, od lewej do prawej [bourgauDetailedAgendaDDD2019c]. W przypadku gdy idzie to dość niemrawo, warto zaproponować zmianę opowiadającego.

Jak wskazuje Zimarev, najważniejsze jest to, aby programiści zadawali pytania. Jeśli na twoich warsztatach nie było dyskusji to możliwe, że problem był zbyt prosty lub zaproszeni byli nieodpowiedni ludzie [DDDNetCore].

Nie obawiaj się również rozszerzać notacji warsztatów. Na przykład, gdy domena mocno operuje na bazach danych można spróbować zaprezentować je w trakcie warsztatów za pomocą osobnych karteczek, gdzie każda z operacji, jak SELECT czy UPDATE, ma swój własny kolor [DevStyleStolarczyk].