O'Reilly Software Architecture Conference 2019 - Event storming

05 February 2019 // Jesper Holmberg

Ett hett tema på O’Reilly Software Architecture Conference här i New York är relationen mellan mikrotjänst-arkitekturer och verksamhetsmodellering, och Domain driven desigen (DDD) har de senaste åren fått ett renässans som en metod för hitta en hållbar uppdelning av de tjänster man vill använda sig av - genom att grunda sin mikrotjänst-arkitektur i verksamhetens naturliga kontexter, ökar man sannolikheten för att den uppdelning man väljer inte går på tvärs med verksamhetens centrala användningsfall. Callistas egen Andreas Tell höll ett föredrag om detta på förra årets CADEC.

Event storming

En modelleringsmetod som har nämnts av ett flertal talare på konferensen här i New York är Event storming. Det är en sätt för ett projekt att snabbt hitta en fungerande domänmodell i en intensiv workshop som samlar alla intressenter i ett projekt: utvecklare såväl som verksamhetsföreträdare. Målet med aktiviviteten är att effektivt skapa en domänmodell som alla förstår, och genom att arbeta effektivt och öppet under en begränsad tid, kan man hitta eventuella konflikter i domänen tidigt. Samtidigt lär sig utvecklarna det universella språk som verksamheten använder för den domän som det slutliga systemet ska verka inom (såväl universellt språk som domän är väldefinierade termer som används inom DDD). Metoden skapades av Alberto Brandolini, som också arbetar på en bok i ämnet.

Metoden

Kort beskrivet går metoden ut på att man med hjälp av post-it-lappar och vägg-tavlor identifierar de domän-händelser som verksamheten bryr sig om. Det centrala här är att händelserna inte ska beskrivas i ett tekniskt perspektiv, utan ska helt betraktas ur verksamhets-perspektiv. Alla eventuella implementations-frågor är fortfarande långt borta. En efter en går man igenom de händelser man identifierat. En händelse kan t.ex. vara “En beställning läggs för en kund”. Man frågar sig vilka kommandon som kan ha givit upphov till händelsen. Kanske har användaren valt beställningen genom att interagera med webbsidan, eller så har beställningen lagts p.g.a. en redan beställd prenumeration, osv. Man följer också vad händelsen i sin tur ger upphov till, med händelser och kommandon i nya kedjor. Varje kedja diskuteras och inventeras, och lappar som representerar händelser, kommandon och aktörer sätts upp på tavlan. Genom att arbeta intensivt och tillsammans, kan man snabbt hitta konflikter eller motsättningar, och reda ut dem i vidare diskussioner.

Från events till modell

Efter den första inventeringen kan man sedan börja inventera DDD-aggregat, med andra ord de objekt som användare eller andra aggregat kan interagera med, och som i sin tur har underordnade objekt som de representerar gentemot andra aggregat. Detta kan leda vidare till det som i DDD-sammanhang kallas för “bounded contexts”: avskilda domäner inom den övergripande domänen, där begrepp är entydigt definierade och sammanhållna, vilket i sin tur är utgångspunkten för arbetet med att hitta sin uppdelning i tjänster i mikrotjänst-arkitekturen. Men det är fortfarande en bit bort: eftersom syftet med själva event storm-övningen är att hitta ett gemensamt perspektiv och språk mellan utvecklare och verksamhet, ska de tekniksa frågorna inte dryftas här.

Oavsett om man är en erfaren DDD-modellerare eller ej, kan event storming vara ett intressant verktyg för ett team för att tidigt få en djupgående och gemensam syn på problem-ommrådet.

En bra introduktion till tekniken, förutom Alberto Brandolinis bok, finner ni här.