In tutti gli esempi di bus di servizio e le esercitazioni che ho visto, coprono la pubblicazione di un singolo messaggio in un singolo argomento raccolto da un singolo Sottoscrittore in ascolto. Sebbene ciò sia utile per una semplice panoramica pratica, non spiega in realtà come gli Argomenti dovrebbero essere usati nel mondo reale.
Ho una grande applicazione di e-commerce che si estende su molti sottodomini, come Order, Customer e Product management per nominarne alcuni, e userà un ESB per comunicare eventi tra questi diversi sistemi. Userò Pub-Sub tramite argomenti.
Inizialmente stavo usando un singolo argomento per ogni tipo di messaggio che stavo inviando, tuttavia potevo vedere che questo sarebbe diventato ingestibile in quanto il sistema avrebbe avuto troppi tipi di messaggi da inviare per giustificare un 1- to-1 Tipo di messaggio per argomento. per esempio. ProductCreate Argomento, ProductDelete Argomento.
Poi ho pensato che potevo usare un argomento per aggregato nel sistema. Tuttavia, a causa dei molteplici contesti limitati nel dominio, un aggregato in un sistema potrebbe essere diverso da un aggregato, con lo stesso nome, in un altro sistema. Quindi questa implementazione potrebbe essere abbastanza confusa.
Quindi avere un argomento per modello onnipresente sembra una soluzione migliore, e questo può essere basato sul modello di dati canonico usato per trasformare i messaggi attraverso il bus di servizio. È un approccio comune? O è la divisione degli Argomenti per preoccupazione funzionale un metodo migliore?
Riesco a vedere che ci saranno dei compromessi per qualsiasi implementazione scegliamo, quindi sono alla ricerca di buoni consigli, esempi storici di successi e insidie da evitare.