L’ho già detto quando ho parlato della distinzione tra Evento ed Evento di Dominio (qui e qui) e quando abbiamo approfondito i “fat event” (qui e qui).

Quando approcciamo SOA e decliniamo l’architettura usandone una basati su messaggi ci troviamo di fronte a tre tipologie di messaggi:

Comandi

I comandi sono diretti ad un destinatario, uno solo (ripetete con me: uno solo), e portano con se tutte le informazioni che permettono al destinatario di portare il sistema in un nuovo stato consistente. I comandi tipicamente sono “fat command” e siccome per loro natura creano forte accoppiamento i comandi vivono all’interno del buonded context (se la pensiamo in termini DDD) o all’interno del servizio (in termini SOA). Un esempio di comando è CreaAnagraficaUtente che porterà con se tutte le informazioni per creare l’utente. Il comando, ad esempio, viene inviato dalla parte di front-end dell’anagrafica utenti e gestito dalla parte di back-end della stessa anagrafica utenti. Stesso BC.

Eventi

Gli eventi a differenza dei comandi sono pubblicati in broadcast, a chi pubblica non interessa assolutamente chi sono i sottoscrittori, si limita a pubblicare. Gli eventi per loro natura travalicano i confini del servizio, questo comporta, a differenza dei comandi, che chi pubblica non ha nessun controllo su chi sottoscrive e diventa quindi cruciale ridurre all’osso l’accoppiamento. L’implementazione tipica di un evento è quindi molto scarna e ridotta ai minimi termini, AnagraficaUtenteCreata che portata con se solo l’ID dell’utente.

Ogni volta che siamo tentati dall’aggiungere informazioni ad un evento dovremmo fermarci e farci qualche domanda.

Messaggi

Ci sono scenari, e tipicamente non sono scenari di business, in cui i due modelli di cui sopra ci vanno stretti. Diciamo che a fronte del fatto che un utente è stato creato vogliamo che sia indicizzato dal motore di ricerca dell’applicazione. Mi aspetterei di implementarlo con messaggio, fat probabilmente, che dall’anagrafica utenti va verso il motore di ricerca. IndicizzaNuovoUtente non è un comando perché per il business non ha significato ma è semplicemente un messaggio grezzo. Mi aspetto inoltre che il motore di ricerca non sappia come gestire il messaggio in arrivo, ma che presso il motore di ricerca ci sia un delegato, componente autonomo per SOA, di anagrafica utenti che riceve il messaggio in ingresso e sa come dialogare con il motore di ricerca.

A questo punto nulla vieta che il delegato di anagrafica utenti sappia collaborare con altri delegati al fine di costruire modelli più complessi  al fine, nel nostro esempio, di generare risultati della ricerca più interessanti per gli utenti. Quest’ultimo scenario viene definito IT/Ops.