Due modelli di integrazione aziendale sono il messaggio di comando e 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 i servizi. Dovrebbe essere un sistema alla fine coerente , e i servizi dovrebbero essere ignoranti l'uno dell'altro (con l'eccezione di una coppia speciale servizi specifici). Come tale, cerchiamo di evitare cose che si sentono come chiamate di procedura remota (RPC o RPI). Abbiamo un sistema di middleware basato su bus e messaggi e tutti i messaggi sono trasmessi.
Tendiamo a dare un nome ai nostri messaggi come eventi, cioè come una frase nel passato perfetto, ad es. %codice%. Tuttavia, gli eventi vengono spesso aggiunti solo quando alcuni altri servizi devono conoscerli e all'inizio, spesso, solo un servizio si prende cura di loro. Inoltre, a volte quel servizio emette un evento come risultato, che viene ascoltato dal primo servizio. Quindi, se dovessi disegnare l'interazione, sembrerebbe molto più simile al diagramma del messaggio di comando nel link sopra (o anche al diagramma RPC) rispetto a quello per il messaggio dell'evento, sebbene, ancora una volta, questo non sia effettivamente implementato con messaggistica diretta ma trasmessa su un bus. Aggiungete a ciò il fatto che di recente ho visto alcuni messaggi aggiunti che sono nominati come comandi, cioè una frase nell'imperativo, ad es. PurchaseOrderShipped .
La cosa strana è che i nomi dei messaggi e il modo in cui fluiscono non cambiano se è denominato 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, oppure esiste una differenza di implementazione effettiva tra i messaggi di comando e di evento? Dato che tutti i nostri messaggi sono trasmessi, vuol dire che nessuno di loro è veramente un messaggio di comando?