Sto creando un'applicazione web CRUD che, dopo l'elaborazione della logica interna, pubblicherà eventi su altri sistemi per aggiornare i propri dati.CQRS intento comando evento
Sono al primo passaggio per implementare CQRS e sembra strano che io debba creare comandi specifici per tutte le possibili intenzioni dell'utente in un modulo in cui ho solo un pulsante 'salva'. Ciò significa che molti comandi (per ogni proprietà o oggetto valore) per catturare un'intenzione non sono necessari nei miei requisiti ma sono necessari nei progetti imminenti che li sottoscriveranno. Sono un fan di SOLO quello che richiede il mio contesto limitato.
Un'altra cosa da tenere in considerazione: Devo utilizzare la sessione per confrontare se i dati sono stati modificati o meno. Faking dei dati dopo averlo salvato nasconderà situazioni di concorrenza che mostrano dati errati nell'interfaccia utente.
EDIT: Ho appena trovatothis thread dove Greg Young suggerisce che alcune schermate sono solo CRUD e non c'è nulla di male nel fare l'aggiornamento come comportamento predefinito.
Lo sto facendo in questo modo. Il mio progetto CRUD è uno 'strumento di configurazione' interno per mostrare i dati corretti in un sito Web a traffico elevato, quindi ho bisogno di pubblicare eventi. La mia soluzione perfetta sarebbe quella di realizzare questo progetto con solo DDD, senza CQRS e pubblicare un evento per ogni reale intenzione nel mio ambito. Il sito Web dovrebbe essere raggiunto utilizzando CQRS poiché avrà migliaia di utenti. Non vedo perché devo creare tanti comandi quando i miei requisiti dicono semplicemente 'creare un modulo con un pulsante di salvataggio' – Cesar
Se l'unica ragione di CQRS è la scalabilità, è sufficiente provare qualcosa di più semplice. I.e: utilizzo di una sorta di cache di memoria per ridurre il carico sui siti Web (o pubblicare visualizzazioni Web in modo da non stressare il DB - i.e .: JSON su CDN), o semplicemente modificare la memorizzazione nella cache predefinita del server. Di solito, CQRS entra in gioco quando il progetto deve occuparsi di alcuni di questi aspetti: gestire uno scenario aziendale complesso, scalare, avere ricche funzionalità di BI, adattarsi a requisiti in rapida evoluzione. –
lo scenario è complesso ei sistemi sono già in esecuzione con memcache. Possiamo ottenere molti benefici dalle pratiche CQRS, non c'è dubbio su questa decisione, il sito Web verrà ricostruito con CQRS. Il dubbio si riferisce principalmente a quei piccoli progetti che circondano il sito web e se invece dovessero inviare un grande comando o piccoli comandi (lo stesso sugli eventi). Tutti questi pensieri provengono da uno sviluppatore con un forte background di DDD, contesti limitati e successo. Ora devo codificare tutti gli intenti e gestire la sessione per mantenere la versione dei dati. (A proposito, adoro leggere il tuo blog) – Cesar