Event Storming: workshop od stěny k agregátu
Event Storming prakticky: notace, Big Picture krok za krokem, Process Modelling a Software Design. A jak se lepicí papírky promítnou do tříd a testů v Symfony.
Přehrávač YouTube se načte až po kliknutí · otevřít na YouTube (nové okno) ↗
Přepis dílu komentář tak, jak zazní ve videu
Specifikace, která neexistuje
Dejte nám specifikaci a my to naprogramujeme. Jenže použitelná specifikace typicky neexistuje. Místo ní je tu wiki stará tři roky, issue tracker s osmnácti sty tickety a čtyři lidé, kteří to vědí.
Doménu jako knihu přečíst nejde, žije v hlavách lidí, kteří ji provozují. Event Storming ji z těch hlav dostane na stěnu.
Proč workshop a jak číst stěnu
Když se obchodní ředitel a šéf logistiky rozcházejí v tom, co znamená odeslaná objednávka, je to signál. Existují dva pohledy, a tedy nejspíš i dva Bounded Contexty.
Na workshopu se takový rozpor ukáže hned. Wiki ho neodhalí, protože vždycky zachytí pohled toho, kdo ji psal.
Techniku vymyslel Alberto Brandolini. Poprvé ji předvedl v roce 2012 a jméno Event Storming jí dal o rok později.
Dnes má tři formáty. Big Picture hledá, co se v doméně vůbec děje. Process Modelling rozebírá jeden proces a Software Design míří ke třídám.
Základem je oranžový papírek s doménovou událostí v minulém čase. Modrý je command, malý žlutý actor a růžový hot spot, tedy otevřená otázka.
Barvy se mezi facilitátory liší, a proto legenda patří na stěnu. Když si u papírku nejste jistí, přečtěte ho nahlas. Minulý čas znamená událost a imperativ command. Pravidlo typu když se stane tohle, udělej tamto, je policy.
Big Picture krok za krokem
Big Picture je podle Brandoliniho celodenní workshop pro patnáct až třicet lidí. Kniha k tomu nabízí zkrácenou variantu na dvě až čtyři hodiny, když je doména menší.
U stěny musí stát aspoň dva doménoví experti. Tedy lidé, kteří tu práci opravdu dělají, ne projektoví manažeři.
Začíná se chaoticky. Každý lepí kamkoli události, které ho napadnou. Teprve potom je facilitátor začne řadit do časové osy.
Pak se hledají zlomové události, kolem kterých se ostatní sdružují. V e-shopu třeba zadaná objednávka, úspěšná platba nebo odeslaná zásilka.
Když padne otázka, na kterou v místnosti nikdo nezná odpověď, nediskutuje se o ní. Napíše se na růžový papírek a nalepí přesně tam, kde vznikla. Právě tyhle papírky bývají to nejcennější, co si tým z Big Picture odnese.
Nakonec se na stěně hledají hranice kontextů. První vodítko je stejné slovo s jiným významem. Objednávka je pro prodej košík se slevami, pro sklad seznam položek k vychystání a pro účtárnu podklad faktury. Tři významy nejspíš znamenají tři kontexty.
Další vodítka jsou zlomové události, hranice oddělení a vlastnictví dat. Samo o sobě žádné nerozhoduje. Hranice leží tam, kde se jich protne víc najednou.
Process Modelling
Process Modelling se soustředí na jeden kontext. Ke každé události tým zpětně doplní, jaký command k ní vedl a kdo ho spustil.
Pak se postupuje dopředu. Přibývají policies, tedy reakce na událost. K nim externí systémy a read modely, podle kterých se actor rozhoduje.
Pro objednávku v e-shopu vyjde tahle sekvence. Zákazník zadá PlaceOrder a vznikne OrderPlaced. Na tu reagují tři policies: rezervovat zboží, poslat potvrzení a zahájit platbu.
Z mapy už je vidět, co bude potřeba. Každý command typicky dostane handler a každý externí systém vlastní ACL. Policy, která překračuje hranici kontextu, je kandidát na ságu. Ta pak řídí kroky ve více kontextech.
Software Design: ze stěny do kódu a testů
Software Design je ze tří formátů nejblíž kódu. Ke každému commandu přibude velký žlutý papírek s agregátem, který ho obsluhuje. Pod něj se vypíšou invarianty, tedy pravidla, která agregát nesmí porušit.
V kódu má každý papírek protějšek. Command je třída PlaceOrder a agregát třída Order. Invariant se stane výjimkou v doménové metodě a událost se zaznamená přes record.
Tři rozhodnutí ale padají mimo místnost a na stěně pro ně barva není. Kdy se události publikují, jestli command něco vrací a na jakou sběrnici jde.
Holá kontrola bez kontextu je ale křehká. Za půl roku ji nový vývojář v dobré víře smaže jako divnou validaci. Komentář s odkazem na invariant a hot spot z workshopu mu řekne, odkud pravidlo pochází.
Každý invariant ze stěny je zároveň jeden test. Objednávku bez položek nejde potvrdit a test to říká už svým jménem.
Otázky a shrnutí
Krátká otázka na rozmyšlenou. DispatchShipment, je to událost, nebo command?
Command, je to imperativ. Událost by se jmenovala ShipmentDispatched.
A jedna z dílu o subdoménách. Prodej existoval dřív než IT systém, Checkout Service vznikl kvůli oddělení modelů. Co je co?
Prodej je subdoména, Checkout Service je Bounded Context.
Takže v kostce. Události se píšou v minulém čase a hot spoty se jen zaznamenávají.
Big Picture hledá hranice kontextů. Process Modelling doplní commands a policies, Software Design agregáty s invarianty. Každý invariant pak skončí jako výjimka v agregátu a jako jeden test.
Příští díl je o Domain Storytellingu a o tom, co musí jít do repozitáře do čtyřiadvaceti hodin po workshopu. Kapitolu najdete v knize na ddd-v-symfony.katuscak.cz.