Sto prendendo in considerazione un processo di refactoring CQRS. È più un esercizio di apprendimento nel mio tempo libero. Il caso d'uso è simile a un sito web di comparazione dei prezzi in cui un utente inserisce i propri dati per un mutuo e viene presentato con opzioni di mutuo dai fornitori di servizi. Ad esempio, un utente inserisce il deposito minimo; termine; valore della casa e quindi sono presentati con opzioni, ad es. mutuo 1 di HSBC; mutuo 2 da NatWest ecc. Un utente potrebbe fare più di una richiesta; aggiustando i criteri ogni volta. Ad esempio:
1) Criteria 1: 25 year term, £23,000 deposit, £150,000 value
2) Criteria 2: 30 years term, £20,000 deposit, £180,000 value
etc
Credo di avere due opzioni:
1) Event Sourcing using event store.
2) Message Queue/service bus
Riguardo all'opzione 1 - questo caso d'uso è adatto anche per il sourcing di eventi? Il classico esempio di event sourcing è un conto bancario in cui è possibile vedere quale era il saldo in quel momento: x o data: y ripetendo gli eventi. Tuttavia, nel mio caso; l'azienda non vorrebbe sapere quale fosse il valore del "deposito" in data: x. Ogni ricerca utente è nuova e indipendente dall'ultima.
Per quanto riguarda l'opzione 2 - credo che le code di messaggi (e i bus di servizio) siano adatte quando c'è bisogno di comunicare con un altro microservizio. Nel mio caso; l'editore e il sottoscrittore dell'evento sarebbero lo stesso microservizio.
La mia analisi mi dice che nessuna delle due opzioni è adatta a causa delle ragioni esposte nei due paragrafi precedenti. Sono corretto in questa analisi?
