Event storming

Big Picture Event Storming to technika warsztatowa służąca do wspólnego mapowania zdarzeń domenowych, zależności i punktów problemowych w całym procesie biznesowym. W praktyce warto zacząć od ustalenia celu sesji, zakresu procesu, składu uczestników i reguł notacji, a następnie uporządkować zdarzenia na osi czasu oraz oznaczyć hotspoty, ryzyka i niejasności. Przykładem może być analiza procesu obsługi zamówień, w której zespół identyfikuje opóźnienia, konflikty odpowiedzialności i kandydatów na granice systemu. Ten temat przerabiamy praktycznie na szkoleniu: Big Picture Event Storming.

Event Storming dostarcza materiału analitycznego, a Domain-Driven Design porządkuje go w postaci języka domenowego, kontekstów i wzorców projektowych. Należy sprawdzić, które zdarzenia, komendy, polityki i aktorzy wskazują na odrębne modele biznesowe, a potem przełożyć te obserwacje na Bounded Contexts, relacje między nimi i decyzje architektoniczne. Dobrym przykładem jest sytuacja, w której jeden warsztat ujawnia potrzebę rozdzielenia obszarów sprzedaży, płatności i logistyki na osobne konteksty. Jeśli chcesz przećwiczyć to krok po kroku, zobacz: Projektowanie modeli domen z wykorzystaniem Domain-Driven Design i Event Storming.

Bounded Contexts wyznaczają granice spójnego modelu domenowego, języka i odpowiedzialności w systemie. Podczas warsztatów trzeba obserwować zmiany znaczenia pojęć, punkty przekazywania odpowiedzialności, różnice w regułach biznesowych oraz miejsca, w których uczestnicy używają odmiennych nazw dla podobnych zjawisk. Przykładowo termin „zamówienie” może oznaczać co innego w sprzedaży, a co innego w realizacji, co zwykle sygnalizuje potrzebę rozdzielenia kontekstów. To jedno z zagadnień omawianych podczas szkolenia: Wzorce strategiczne Domain-Driven Design z wykorzystaniem Big Picture Event Storming.

Process Level Event Storming służą do zrozumienia przebiegu procesu i zależności biznesowych, a Design Level Event Storming schodzą na poziom komend, aktorów, polityk, modeli odczytu i granic implementacyjnych. Wybór zależy od celu pracy: przy odkrywaniu wymagań i problemów lepiej sprawdzają się poziomy procesowe, natomiast przy przygotowaniu architektury i kodu potrzebne są poziomy projektowe. Przykładem jest przejście od mapy obsługi reklamacji do modelu agregatów, komend i reakcji systemu. Wersję warsztatową (z konfiguracją i przykładami) znajdziesz w programie szkolenia: Process i Design Level Event Storming.

Artefakty z Event Storming można przekształcić w elementy modelu domenowego, takie jak agregaty, zdarzenia domenowe, komendy i modele odczytu. Najpierw warto zidentyfikować granice spójności, reguły biznesowe i punkty decyzyjne, a następnie przypisać je do agregatów oraz rozdzielić odpowiedzialność między zapis i odczyt zgodnie z CQRS lub Command Query Separation. Przykładem jest model, w którym komenda inicjuje zmianę stanu agregatu, a wynikowe zdarzenia zasilają osobny model raportowy. Dokładnie ten zestaw narzędzi i workflow ćwiczymy podczas szkolenia: Wzorce taktyczne Domain-Driven Design z wykorzystaniem Process i Design Level Event Storming.

Event Sourcing i CQRS mają uzasadnienie tam, gdzie liczą się audytowalność, odtwarzanie stanu, złożona logika biznesowa i rozdzielenie obciążeń zapisu oraz odczytu. Przed wdrożeniem trzeba ocenić koszty utrzymania zdarzeń, wpływ eventual consistency, wymagania testowe oraz to, czy model domenowy rzeczywiście korzysta z historii zmian jako źródła prawdy. Typowym przykładem są systemy finansowe lub operacyjne, w których trzeba odtworzyć sekwencję decyzji i zmian po wystąpieniu błędu. Ten temat przerabiamy praktycznie na szkoleniu: Event Sourcing i CQRS.