2011-01-14 13 views
8

Recentemente ho iniziato a studiare CQRS e DDD per un progetto di campo verde che sto per iniziare. Ho studiato una grande quantità di materiale da Udi Dahan, Greg Young, Mark Nijhof e altri. Questi sono stati davvero molto utili e penso di avere una buona comprensione dei concetti. Ma ci sono ancora alcune domande sulla mia mente su come posso applicarle al mio dominio.CQRS - come modellare un sistema di esecuzione di uno scenario

Il mio sistema sarà fondamentalmente un motore di regole complesse - in cui le regole determineranno il prezzo finale di determinati prodotti. Le definizioni e le regole del prodotto saranno inserite nel sistema dagli amministratori. Le regole verranno progettate dagli amministratori utilizzando un insieme predefinito di proprietà che possono avere valori da un set predefinito, ad esempio "Scopo dell'acquisto" (Rivendita, Locazione) o valori di modulo libero, ad esempio Età.

Ogni prodotto avrà un prezzo base e le regole saranno fondamentalmente aggiunte/rimosse dal prezzo base se applicabili.

Una regola di esempio molto semplice potrebbe essere:

Per il prodotto X, IF (Acquisto Scopo = rivendere e Età> 25) aggiungere 25 $ al prezzo base.

Quindi ci sono 2 tipi di utenti che utilizzano il sistema, gli amministratori, che definiscono i prodotti, le regole e i prezzi base; e altri utenti che interrogano i prezzi in base a uno scenario che inseriscono tramite un'interfaccia utente what-if.

La mia confusione è questa: l'esecuzione di uno scenario non cambia affatto lo stato del dominio, nessun altro sistema/persona esterna è interessato al risultato dell'esecuzione dello scenario ma all'utente stesso che esegue - restituisce il risultato di un calcolo del prezzo dopo aver eseguito le regole applicabili per lo scenario indicato. Ad esempio, l'utente potrebbe selezionare Prodotto X e interrogare il prezzo per un determinato scenario, ad esempio (Acquisto scopo = Rivendita e Età = 40). Ancora una volta, dal momento che questa operazione non modifica affatto lo stato del dominio, immagino sia una query. Tuttavia, esiste un motore di regole che opera nello scenario per calcolare il prezzo finale, che immagino possa essere classificato come logica di dominio da eseguire. Quindi - dove questa logica appartiene? Si tratta di una query che funziona appena fuori dal modello di lettura o che sta eseguendo uno scenario un comando che deve essere eseguito nel modello di dominio? Di nuovo, sembra che il dominio sia lo spazio per queste regole, ma come passare il risultato dell'esecuzione dello scenario all'utente (sembra una domanda che ci pensa in questo modo). O forse, CQRS non è la soluzione giusta per questo particolare problema?

+0

+1 per avermi detto che esiste un pattern [cqrs] (http://blog.fossmo.net/post/Command-and-Query-Responsibility-Segregation-%28CQRS%29.aspx) che non ho mai ascoltato prima. – k3b

risposta

4

Ho avuto questo problema esatto nel mio dominio (e-scheduling 4 assistenza sanitaria). Fondamentalmente il sistema è configurato utilizzando un modello di dominio (lato scrittura). Questo sarebbe la definizione di regole, prodotti e prezzi base nel tuo dominio. Cosa esce dal dominio? Eventi, cambiamenti di stato, cose che sono successe e perché è successo. Ora quello che ho fatto è stato consumare questi eventi in un diverso Contesto Limitato, nel mio caso un motore di ricerca complesso che trova spazi liberi negli orari di medici, sale operatorie e apparecchiature costose. Questa potrebbe essere una strada da prendere, consumare il prodotto, il prezzo base e gli eventi relativi alle regole e memorizzarli in modo tale che il motore delle regole, posto sopra a tali dati, possa gestire le richieste degli utenti per gli scenari in modo efficiente come possibile. Molto probabilmente scoprirai che il modello per memorizzare le modifiche (dominio) differisce dal modello ottimizzato per interrogare quegli scenari ipotetici (motore delle regole). Il tuo dominio avrà probabilmente regole come "non puoi specificare lo stesso prodotto due volte" o "questa regola non sarà mai abbinata (età età> 25)". Il dominio riguarda solo le modifiche di stato valide. Questa non è una preoccupazione del motore delle regole. Sarai tentato di riutilizzare concetti/classi nel tuo motore di regole definiti nel dominio. Resistere a quell'urgenza.Domanda se davvero servono allo stesso scopo. Modellarlo due volte per uno scopo diverso non è sporco o una violazione di DRY.

+0

Giusto per chiarire, non c'è niente di sbagliato nell'usare un approccio basato su gestore di query, in cui le query sono modellate come oggetti/messaggi (più o meno come comandi ed eventi) e un gestore gestisce la richiesta di query ed emette una risposta alla query. Questo potrebbe essere il front-end del tuo motore di regole. –

+0

Grazie per la tua risposta, Yves. Ma, non sono ancora al 100% chiaro. Quindi ho qui 3 contesti limitati? 1 - Modello di dominio (stato di gestione lato scrittura), 2 - Contesto contesto esecuzione scenario, 3 - Modello di lettura per UI - 2 e 3 come slave a 1. E tutti e 3 hanno il proprio meccanismo di persistenza? Grazie - Kaan. – KaanK

+0

Risposta breve: Sì. 3 modelli separati che servono a scopi diversi. Basta mordere il proiettile. –

0

CQRS non dice nulla che non ci dovrebbe essere la logica di dominio nella parte di query dell'applicazione. Se è possibile e pratico, allora è ok avere depositi di query denormalizzati separati per ogni aspetto o anche query della tua applicazione, ma ovviamente non è necessario.

In breve, una query è una query, non importa quanto sia complesso il compito di trovare la risposta.

Problemi correlati