Come determinare se un messaggio deve essere un messaggio di comando o un messaggio di evento?

Due modelli di integrazione aziendale sono il messaggio di comando e il messaggio di evento . Sto lavorando a un sistema in cui utilizziamo la messaggistica non solo per l'integrazione con altri sistemi, ma per la comunicazione interna tra servizi. Dovrebbe essere un sistema eventualmente coerente , e i servizi dovrebbero essere ignoranti l'uno dell'altro (ad eccezione di un paio di servizi speciali). Pertanto, cerchiamo di evitare cose che sembrano chiamate di procedure remote (RPC o RPI). Abbiamo un sistema di middleware orientato ai bus e ai messaggi e tutti i messaggi vengono trasmessi.

Tendiamo a nominare i nostri messaggi come eventi, cioè come una frase del passato perfetta, ad es PurchaseOrderShipped. Tuttavia, gli eventi vengono spesso aggiunti solo quando alcuni altri servizi devono conoscerli e, all'inizio, spesso interessa solo un servizio. Inoltre, a volte quel servizio emette di conseguenza un evento, che viene ascoltato dal primo servizio. Quindi, se dovessi rappresentare l'interazione, sarebbe molto più simile al diagramma per il messaggio di comando nel link sopra (o anche al diagramma RPC) rispetto a quello per il messaggio di evento, sebbene, ancora una volta, questo non sia effettivamente implementato con messaggistica diretta ma trasmessa su un bus. Aggiungete a ciò il fatto che recentemente ho visto l'aggiunta di alcuni messaggi che sono chiamati come comandi, cioè una frase nell'imperativo, ad es BillShippedPurchaseOrder.

La cosa strana è che i nomi dei messaggi e il modo in cui scorrono non cambiano se viene chiamato come evento o come comando. Quindi, come si determina se qualcosa dovrebbe essere un messaggio di comando o un evento? Questa è solo una differenza di semantica e denominazione o esiste una reale differenza di implementazione tra comando e messaggi di evento? Dato che tutti i nostri messaggi vengono trasmessi, significa che nessuno di loro è veramente un messaggio di comando?

C'è una differenza sottile, ma importante tra comandi ed eventi. Un comando ha una presunzione di una risposta mentre un evento non presume una risposta, è semplicemente un'affermazione.

Per essere meno astratto:

ShipOrderè un comando e il mittente ShipOrderprobabilmente si aspetterà una risposta di qualche tipo.
OrderShippedè una dichiarazione e è improbabile che il mittente si aspetti una risposta, come GoodJob!è una risposta inutile in questo esempio.

Se stai progettando i tuoi sistemi in modo che si aspettino solo messaggi di eventi, non importa necessariamente alla progettazione del sistema come li chiami. Gli sviluppatori possono essere confusi dal nome di un messaggio, ma i sistemi risponderanno perfettamente indipendentemente dalla convenzione che segui per nominare le cose.

Ma non sembra che i tuoi colleghi sviluppatori stiano seguendo il modello di messaggi per soli eventi. Se i servizi si aspettano risposte ai "messaggi di evento" che stanno inviando, allora stanno davvero inviando messaggi di comando. Non è un grosso problema, e posso pensare a molti casi in cui sarebbero richiesti comandi come richieste di informazioni. Ma avrai un mal di testa semantico se ti aspettavi di vedere solo i messaggi degli eventi.

La trasmissione di messaggi non ha alcun impatto sul fatto che un messaggio sia un comando o un evento. Generalmente, non si trasmettono comandi in quanto duplica lo sforzo. Ma non c'è niente da dire che non puoi. I primi protocolli di rete trasmettevano ogni pacchetto e i ricevitori dovevano essere abbastanza intelligenti da sapere quando ignorarlimessaggi pacchetti che non appartenevano a loro.

Un messaggio di evento è qualcosa che è appena successo. Stai avvisando dell'evento appena accaduto.

Un messaggio di comando è un messaggio che si aspetta che venga fatto qualcosa. Potrebbe o meno aspettarsi una risposta.

Quando utilizzare ciò che si riduce all'accoppiamento e la differenza emergerà nel tempo man mano che i sistemi evolvono. Favorire gli eventi rispetto ai comandi comporta un minor accoppiamento. L'emittente dell'evento non si preoccupa per il consumatore. In un modello di comando il chiamante conosce ed è quindi dipendente dall'esistenza del provider.

Bill Poole suggerisce di evitare tutti i messaggi di comando: http://bill-poole.blogspot.com.au/2008/04/avoid-command-messages.html

http://bill-poole.blogspot.com.au/