Issue 10003
Event-driven: non è il broker a fare l’architettura
Capire quando stai davvero modellando eventi di business e quando stai solo spostando messaggi tecnici
· 5 min
Obiettivo
Distinguere un evento di dominio da una notifica tecnica e capire quando una soluzione è davvero event-driven.
Quando un’architettura è davvero event-driven
La domanda utile non è “abbiamo Kafka o una coda?”, ma “gli eventi rappresentano fatti di business che altri bounded contextGlossarioBounded ContextUn confine entro cui un modello di dominio e il suo linguaggio mantengono un significato coerente.Apri la voce completa possono usare per prendere decisioni?”. Un eventoGlossarioEventoUna dichiarazione durevole che qualcosa di significativo è già accaduto.Apri la voce completa di dominioGlossarioDominioLa parte del mondo reale, del business o dell’organizzazione che un sistema deve supportare.Apri la voce completa come OrderPaid o CustomerRegistered comunica qualcosa che è successo nel dominio, con un significato stabile anche fuori dal sistema che lo ha generato. In questo caso il consumer può reagire senza dover conoscere i dettagli interni del producer. Se invece pubblichi messaggi come RowUpdated, SyncCompleted o PaymentServiceHeartbeat, stai probabilmente facendo integrazione tecnica asincrona. Può essere una scelta valida, ma non è automaticamente event-driven. In pratica, da Solution Architect devi verificare tre cose: il fatto è comprensibile dal business, il consumer può agire in autonomia e il contratto dell’evento è governato come un’interfaccia di dominio, non come un dettaglio di implementazione.
I trade-off da tenere sul tavolo
Il vantaggio di un vero evento di business è il disaccoppiamento semantico: il producer espone fatti, i consumer reagiscono in modo indipendente e i team possono evolvere in parallelo. Ma il costo non è banale. Servono naming chiari, ownership esplicita, versioning degli schemi, politiche di compatibilità e osservabilitàGlossarioOsservabilitàLa capacità di comprendere il comportamento di un sistema a partire dai segnali che produce.Apri la voce completa end-to-end. Se scegli di pubblicare notifiche troppo tecniche, il vantaggio iniziale è la semplicità di implementazione, ma paghi con consumer più fragili, maggiore dipendenza dal producer e discussioni continue sul significato dei payload. Se scegli eventi di dominio ben modellati, accetti più disciplina in cambio di maggiore autonomia architetturale. La regola pratica è semplice: se il consumer deve chiedere “che cosa vuol dire davvero questo messaggio?”, l’evento non è ancora abbastanza buono.
Esempio realistico in un contesto enterprise
Immagina una piattaforma retail con ordering, billing e loyalty gestiti da team diversi. Il team ordini pubblica OrderPaid quando il pagamento è confermato. Billing usa l’evento per generare la fattura, loyalty per assegnare punti e customer care per aggiornare lo stato dell’ordine. Qui il broker è solo il mezzo: il valore sta nel fatto di business condiviso. Ora confrontalo con un caso diverso: il team applicativo pubblica DatabaseRowChanged ogni volta che cambia una tabella. I consumer devono capire quale campo è rilevante, interpretare lo stato interno del servizio e inseguire eccezioni di schema. In quel caso hai messaggistica, ma non una buona architettura event-driven. La differenza si vede subito nelle riunioni: nel primo scenarioGlossarioScenarioUna situazione concreta usata per testare come un design o una decisione si comporta.Apri la voce completa si parla di processi di business e responsabilità; nel secondo si parla di payload, polling e workaround.
Per approfondire
Fonti esterne autorevoli per approfondire il tema e verificare la distinzione tra eventi di dominio e messaggistica tecnica. • Martin Fowler, Event-Driven Architecture - https://martinfowler.com/articles/201701-event-driven.html • Microsoft Azure Architecture Center, Event-driven architecture style - https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven • Martin Fowler, Domain Events - https://martinfowler.com/eaaDev/DomainEvent.html