Esplorare il proprio business con EventStorming

Circa un mese fa, ci siamo riuniti in una due giorni di EventStorming con l’obiettivo di esplorare il dominio Soisy, di definire i bounded context e di cominciare ad implementarli nella nostra codebase.
A facilitare il tutto c’era il nostro caro Gabriele Lana, che ha deciso di aiutarci a raggiungere l’obiettivo. 
In questo post ti racconterò cosa è successo e cosa abbiamo imparato.

Quali erano gli obiettivi?

Dopo circa 3 anni di esplorazione e test sul business, Soisy ha trovato product market fit entrando di fatto nella fase di scale up. Dal punto di vista tecnologico questo significa permettere alla piattaforma di evolvere velocemente, permettere nuove esplorazioni/sperimentazioni e di essere allo stesso tempo solida. Utilizzando il modello 3X abbiamo visto che alcune parti del nostro dominio (e quindi di business) sono ancora in fase di explore, mentre molte, essendo in fase di expand, devono essere il più possibile evolvibili, robuste ed adatte ai crescenti carichi.

Per avere quindi un’idea chiara e condivisa di quali fossero le parti del nostro dominio, le policy che lo regolano, le responsabilità di queste parti e il modo in cui comunicano, abbiamo ritenuto necessario incontrarci per fare un EventStorming al fine di mappare il domino, allinearci e definirne i bounded context.  

Non approfondirò in questo post l’EventStorming e i bounded context, piuttosto il format che abbiamo usato per definirli.

Perché abbiamo deciso di fare un EventStorming? 

EventStorming è un format partecipativo che permette ad un team eterogeneo di persone, di esplorare un dominio (o un problema) raccontando tramite l’utilizzo di eventi (ovvero le cose che sono successe) i processi e le dinamiche che avvengono all’interno del dominio stesso. La forza dell’EventStorming è quella di mettere insieme persone con ruoli differenti che conoscono il domino (o parti di esso)  con il fine di co-creare questa rappresentazione discutendo di ogni problematica o divergenza che può emergere durante il workshop.
Data la sua natura e il problema che volevamo affrontare, è stato immediato pensare all’EventStorming come format che facesse al caso nostro. La decisione è stata presa dal team tech durante un QuEST che rispondeva alla domanda: “Consolidamento: cosa significa? Come vogliamo farlo? Come lo misuriamo?”

Chi ha partecipato e perché? 

Un aspetto fondamentale nella risoluzione di problemi complessi, è quello di utilizzare l’intelligenza collettiva, ovvero mettere insieme un gruppo di persone interessate al problema e che ne hanno conoscenza (anche limitata), fregandosene dei titoli che queste persone hanno, con lo scopo di analizzare il problema trovando una o più soluzioni da sperimentare e validare.

Questa era la nostra situazione e per questo abbiamo deciso che fossero fondamentali le presenze del team tech (interno + collaboratori), dei product owner e del ceo. 

In Soisy qualsiasi incontro/workshop/retrospettiva/ecc è aperta a tutti. Abbiamo definito un principio (non una regola) per permettere alla persone di decidere se partecipare o meno. Questo principio lascia ai singoli la libertà di decidere secondo la propria coscienza se partecipare o meno. Personalmente, se l’argomento mi interessa e se penso di portare valore contribuendo o anche solo assorbendo, decido di partecipare.

Come abbiamo organizzato le due giornate?

La prima giornata

Questa giornata è stata per lo più “generativa”. Guidati dal saggio Gabriele, siamo partiti dalla definizione degli eventi volti a descrivere il nostro intero dominio.

L’evento è rappresentato tramite un post-it arancione che descrive una cosa accaduta all’interno del nostro domino. In questa fase non ci sono particolari vincoli se non quello di usare post-it arancioni o quello di scrivere l’evento al passato (es: “Finanziamento richiesto”). Ognuno può contribuire scrivendo e attaccando alla parete tutti gli eventi che vuole. 

Finita questa fase, dopo una primo giro di lettura e domande volte a chiarire il significato degli eventi, siamo passati alla definizione degli attori e dei comandi.

Il comando è semplicemente l’azione che scatena l’evento e l’attore è  colui che esegue il comando. Per farvi un esempio super semplice, utilizzando “il richiedente” come attore, avremo:

• Comando: “richiedi prestito”
• Evento: “prestito verificato”

Durante questa fase ci sono state moltissime discussioni e allineamenti sul significato dei termini utilizzati e su come effettivamente funzionasse Soisy. 

Alla fine avevamo la mappa, la “big picture”. Non sono emerse grandi novità, il flusso è ormai piuttosto chiaro. Tuttavia il lavoro è stato utile soprattutto per chi, come me, non avevala visione di insieme.

In conclusione del primo giorno abbiamo fatto delle ipotesi di bounded context. La grande sorpresa è stata quella di vedere che i post-it si concentravano principalmente in diversi punti, dandoci una prima idea di quali fossero i nostri bounded context. 

Data questa cosa, abbiamo concluso la giornata ipotizzando l’esistenza dei seguenti BC:

• investitore (permettere al cliente di investire),
• onboarding richiedente (permettere al cliente di richiedere un prestito),
• p2p (abbinamenti tra prestiti e investimenti),
• partner (integrazione del partner e del suo ecommerce). 

La seconda giornata

Il secondo giorno abbiamo lavorato invece più a livello di modellazione per confermare se i bounded context ipotizzati la sera prima fossero effettivamenti reali. 

Per farlo siamo ripartiti dal bounded context investitore, definendone da subito gli eventi pubblici. Questi particolari eventi sono cose che succedono in autonomia all’interno del BC, ma che però sono necessari a prendere decisioni anche in altre parti del sistema. “Pubblico” significa che quell’ evento una volta che accade (tecnicamente che viene salvato sul nostro event store), viene pubblicato, ovvero viene reso noto al resto del sistema che quella cosa è successa. Gli altri BC “in ascolto” possono quindi reagire e compiere le azioni utili ad implementare le loro policy interne. 

Esempio: il fatto che, la richiesta di prestito sia stata verificata (BC richiedente), dice al BC p2p che quello è un prestito che può essere abbinato.  

Su questi eventi pubblici, abbiamo aggiunto aggregati, rivisto i comandi e definito i read model (se non si era capito, utilizziamo CQRS/Event Sourcing come architettura principale). 

La definizione e l’utilizzo degli eventi pubblici ci ha permesso di capire:

• se la comunicazione tra BC era troppo elevata, sintomo di una divisione non proprio azzeccata dato che la ownership del dato è suddivisa tra due o più BC
• se quell’evento fosse veramente un evento di quel BC
• per ogni evento quali fossero i BC in ascolto

Il bounded context Investitore è stato confermato. Viva!

Siamo poi passati sul BC p2p che rappresenta il core del nostro business, ovvero l’abbinamento tra investimenti e richieste. Utilizzando lo stesso approccio degli eventi pubblici, in questo caso sono emersi altri due BC: prestiti e pagamenti. Il primo responsabile della gestione di un prestito dal momento in cui è stato finanziato (stato delle rate, ecc), il secondo responsabile di effettuare i pagamenti tra richiedenti e investitori.

Alla fine della giornata avevamo: investitore, richiedente, p2p, partner, prestito, pagamenti e anagrafica. Quest’ultimo con la responsabilità di gestire l’anagrafica cliente (dati, documenti, ecc).

Qual è stata la cosa più importante nel fare EventStorming? 

Sicuramente il contributo di tutti i partecipanti e la possibilità di discutere, confrontarsi e soprattutto visualizzare continuamente il risultato prodotto. Come dicevo prima, queste sono situazioni complesse e un team tech non dovrebbe affrontarle in isolamento.

“Tutto molto bello”, ma poi dal giorno successivo cosa è cambiato?

In conclusione alla seconda giornata e nei giorni successivi abbiamo discusso di tattiche su come muoversi per estrarre questi bounded context e anche grazie ai consigli di Gabriele abbiamo deciso di: 

• avere unico event store (cosa che già avevamo);
• tenere read model e database interni ai singoli bounded context;
• separare inizialmente a livello di namespace il codice, in modo che ogni BC sia il più possibile isolato;
• definire delle porte di comunicazione dove, tramite adapter, nascondere il fatto che per iniziare, ogni BC farà delle query dirette verso altri BC nel caso in cui serva condividere informazioni;

Ad oggi, dopo circa un mese, abbiamo dato il via all’implementazione dei seguenti BC: richiedente, p2p, investitore, partner, prestito. La codebase è ancora unica (monolite), ma pezzo dopo pezzo stiamo cercando di confinare ogni responsabilità nel giusto BC. 

Andremo verso i microservizi (dovevo usare la buzzword altrimenti non è un vero post)? 

Chi lo sa. Poter “deployare” singole parti autonomamente è un aspetto che ci farebbe comodo, ma questo tema è ancora aperto.

Quindi adesso è tutto scolpito sulla pietra.. ehm sulla carta? 

Ahaha.. ma quando mai. 

Vista la continua evoluzione di Soisy, non vogliamo forzare la mano su questa “mappatura”, ma anzi utilizzare questi primi mesi per capire se effettivamente ci sarà utile oppure no. Qua non si tratta di monolite vs microservizi, piuttosto di avere un software che parli il linguaggio di dominio e che sia il più possibile aderente al business. 

Se hai dubbi o vuoi condividere la tua esperienza, scrivi tutto qua sotto!

Alla prossima.

Rick, Technology