Domain Storytelling a výstup z Event Stormingu
Domain Storytelling jako doplněk Event Stormingu, anti-vzory workshopů a co musí po workshopu jít do repozitáře, aby se slovník z místnosti neztratil.
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
Workshop, který skončil ve Slacku
Modelová situace. Workshop skončí fotkou stěny ve Slacku. Za tři měsíce na něj nikdo nevzpomene a v kódu přibude OrderSavedEvent místo OrderPlaced.
Slovník z místnosti do kódu nedošel a Ubiquitous Language se znovu rozpadl. Přitom by stačilo pár souborů v repozitáři a jeden malý pull request.
Domain Storytelling
Domain Storytelling popsali Stefan Hofer a Henning Schwentner v knize z roku 2021. Místo časové osy událostí se kreslí příběh o tom, jak doménový expert pracuje.
Actor je ten, kdo v doméně něco dělá, v obrázku panáček. V jednom příběhu se objeví jen jednou. Work object je věc, se kterou actor pracuje, a kreslí se u každé aktivity znovu, protože se během příběhu mění jeho stav.
Aktivita je šipka se slovesem a pořadovým číslem. Každý krok se čte jako věta s pevnou stavbou. Kdo dělá co, s čím a s kým. Kniha drží jeden příběh mezi pěti a patnácti kroky, delší se dělí na dva.
Příklad z kapitoly je objednávka v e-shopu v sedmi krocích. Zákazník prochází katalog, přidá produkt do košíku a odešle objednávku. Systém objednávek si vyžádá platbu u platební brány a ta ji potvrdí. Pak pošle zákazníkovi potvrzovací e-mail a skladu příkaz k expedici. Actorem tu jsou i dva systémy.
Před první šipkou se vyplatí určit rozsah. Jde o hrubý přehled, nebo jemný detail? Popisuje příběh dnešek, nebo cílový stav? A figuruje v něm software, nebo jen lidé? Bez téhle dohody se o to skupina pohádá v půlce příběhu.
Event Storming jde do šířky celé domény. Domain Storytelling naopak rozebere jeden proces do hloubky, a to v malé skupině. Autoři doporučují obě techniky spojit. Big Picture dá přehled a příběhy pak odkryjí detail hlavních procesů.
Anti-vzory workshopů a limity techniky
Bez doménových expertů jde jen o brainstorming vývojářů. Výstup vypadá podobně, chybí mu ale skutečné rozpory i hot spoty. Na devadesát minut Big Picture si experti čas najdou skoro vždy. Když opravdu nikdo z nich nemůže, workshop se odkládá.
Druhý anti-vzor přeskočí Big Picture a jde rovnou na Software Design. Výsledkem bývá God Aggregate. Order nese stav platby, údaje o dopravě, fakturační adresu i kupóny, protože nikdo na stěně neoznačil, že jde o různé kontexty.
Třetí anti-vzor je tech lead v roli facilitátora. Události řadí podle toho, co se dobře programuje, a experti začnou svůj jazyk potlačovat. Rozhoduje neutralita, a tak stejně škodí i externista se silným názorem na architekturu.
Pak jsou limity, které má Event Storming sám, i když se vede správně. Happy path vytlačí storna a výpadky. Nefunkční požadavky jako latence nebo GDPR nemají svou barvu. A výsledek závisí na facilitátorovi víc, než je zdrávo.
Proti první slabině stačí jedna otázka. Po dokončení osy ji položte u každé zlomové události. Co se stane, když tohle selže?
Po workshopu a re-storming
Do čtyřiadvaceti hodin po workshopu mají do repozitáře jít čtyři věci. Fotka stěny nebo export z Mira, aktualizovaná Context Map, seznam událostí a hot spoty převedené na tickety.
Ty tickety z hot spotů nedostává vývojář, ale doménový expert. Odpověď na ně totiž zná jen on.
První pull request po workshopu je malý a žádnou doménovou logiku neobsahuje. Jen uloží do repozitáře, na čem jste se shodli, dřív než to všichni zapomenou. První agregát přijde až v dalším.
Adresář s výstupy workshopů je append-only. Staré složky se nemažou a nové přibývají s datem v názvu. Z historie je pak vidět, jak se mapa domény vyvíjela.
Doména se přitom mění. Když firma přejde na předplatné, ústřední událostí už nemusí být OrderPlaced, ale SubscriptionRenewed. Bez nového workshopu se kód a doména rozejdou a nikdo si toho hned nevšimne.
Kniha proto doporučuje velký re-storming jednou za šest měsíců až za rok. A mimo plán po velkém produktovém rozhodnutí, ještě před implementací. Novou mapu pak tým porovná se starou. Kde se liší nejvíc, tam jsou kandidáti na refaktoring.
Otázky a shrnutí
Krátká otázka na rozmyšlenou. Proč se work object kreslí u každé aktivity znovu?
Protože se během příběhu mění jeho stav nebo médium.
A jedna z dílu o Context Mappingu. Ordering může požádat Catalog o nové pole, kdy ho dodá, ale rozhoduje Catalog. O jaký vztah jde?
Customer Supplier. Ordering má hlas, rozhoduje ale Catalog.
Takže v kostce. Domain Storytelling rozebírá jeden proces do hloubky a Event Storming doplňuje.
Bez doménových expertů a neutrálního facilitátora vznikne jen zdání shody. A do čtyřiadvaceti hodin patří do repozitáře fotka, Context Map, seznam událostí a tickety z hot spotů.
Příští díl je o Conwayově zákonu a Team Topologies, tedy o tom, jak spolu souvisí týmy a architektura. Kapitolu najdete v knize na ddd-v-symfony.katuscak.cz.