2012-08-31 10 views
5

Comprendo i sostenitori del CQRS che separano i modelli di lettura dai modelli di dominio e che dispongono di un modello di lettura specifico per ogni proiezione di modello di dominio necessaria.CQRS: modello di lettura costruito su richiesta?

Dal punto di utilizzo, il modo in cui il modello di lettura viene archiviato e recuperato deve essere trasparente: si invia una query e si ottiene un modello di lettura senza preoccuparsi di come è stato creato.

Molti esempi e articoli utilizzano tabelle separate per l'archiviazione dei modelli di lettura e la rigenerazione in risposta alle modifiche del modello di dominio.

non mi piace molto questo approccio a causa dei seguenti motivi:

  • Non saranno necessari spesso tutti i possibili modelli di lettura;
  • Le modifiche ai requisiti potrebbero invalidare i modelli di lettura esistenti in modo che tutti debbano essere rigenerati;
  • Se per qualche ragione il modello di lettura contiene proprietà che non possono essere memorizzate in generazione ma che devono essere calcolate, si è obbligati a utilizzare stored procedure/funzioni/viste;
  • Poiché i modelli letti sono separati dai modelli di dominio nel caso in cui il caching a livello di applicazione venga utilizzato nella modifica del modello di dominio, è necessario informare tutte le applicazioni che i vecchi modelli di lettura devono essere eliminati dalla cache;
  • A volte non è possibile né desiderabile denormalizzare completamente il grafico di oggetti complessi, pertanto è necessario disporre di modelli di lettura coerenti per la particolare versione di entità di dominio, ovvero devono essere generati nella stessa transazione;
  • Alcune entità di dominio hanno proprietà che cambiano frequentemente ma devono essere incluse in ogni modello letto.

Sulla base di questo sto pensando di avere servizi di query dovrebbe:

  • Per i modelli di lettura che devono essere generati frequentemente e/o che sono semplici proiezioni di entità del dominio: non li memorizzare ma produrli tramite ORM interrogando le entità del modello di dominio nel database;
  • Per i modelli di lettura che non devono essere generati frequentemente e sono complicate proiezioni di entità di dominio, generarli e archiviarli nelle tabelle del database.

Inoltre, alcune persone suggeriscono di memorizzare modelli di lettura come BLOB. Il problema con la memorizzazione di modelli letti come BLOB è che nel caso in cui sia necessario effettuare la ricerca su di essi sarà necessario estrarre le proprietà per l'indicizzazione e se è necessaria la ricerca full-text anche se è necessario memorizzarle in un formato comprensibile per il testo completo utensili.

Come puoi vedere, voglio sostanzialmente avere un modello di lettura che esiste solo dopo l'esecuzione della query e non viene generato in base agli eventi di modifica del dominio. Questa soluzione è accettabile per CQRS? La ragione per cui cerco CQRS è di migliorare l'architettura delle applicazioni separando i modelli di vista memorizzabili dalla gestione delle azioni degli utenti, avere applicazioni Web abilitate AJAX con aggiornamenti asincroni dopo le azioni dell'utente e ridurre la possibilità per gli sviluppatori meno esperti di produrre codice non gestibile mettendo tutte le logiche di business sul posto e persino l'implementazione non fedele di CQRS mi sembra un buon passo nella giusta direzione.

risposta

11

CQRS non richiede che il modello di lettura sia memorizzato in tabelle separate (o documenti se si utilizza un database di documenti), anche se questo spesso è un buon approccio e funziona bene in combinazione con l'event sourcing.Un modello letto può essere supportato da una vista del database o da una query ORM, ad esempio.

Questo potrebbe essere un buon approccio quando si introduce CQRS in parti di un sistema legacy.

L'approccio che stai suggerendo qui è stato suggerito in precedenza, ad esempio vedi this post by Ayende; Penso che sia chiamato "modello di lettura sottile" o simile. Direi di provarci.

potreste essere interessati a leggere

Problemi correlati