2015-05-25 12 views
7

~ TLDR: Sto implementando una soluzione CQRS + DDD per uno dei miei progetti più grandi e, mi chiedo se ci sia un motivo reale per cui i miei gestori di comandi non possono inviare direttamente il comando obietta ai miei aggregati, in una manciata di casi, in cui l'oggetto comando è ricco di dati? Non riesco a trovare alcun motivo specifico per cui questo sarebbe un qualsiasi tipo di anti-modello, e non riesco a trovare alcuna opinione che vada nei dettagli di questo tipo di design.Passare i comandi CQRS direttamente agli oggetti Dominio

Background: I sistemi CQRS sono stati implementati in precedenza e ho implementato le applicazioni DDD, ma mai CQRS + DDD in una corretta applicazione basata su domini di stile Eric Evans. Quindi chiedo perché non voglio abusare dei miei Aggregati e danneggiare la mia domanda a lungo termine.

Un esempio del mio oggetto comando che ha un bel po 'di dati sarebbe un comando di registrazione che accetta più di 8 campi (nome, cognome, nome preferito, dob, titolo, nome utente, password, reparto ecc.). Sembra molto imbarazzante creare un metodo sul mio Aggregate che abbia 8 parametri, e la soluzione alternativa di usare una sorta di dto, e avere il mio gestore mappare il comando al dto - automagicamente usando automapper, o inline - sembra un inutile e non valore aggiungendo astrazione.

Posso anche vedere casi di utilizzo futuri in cui i comandi potrebbero essere ricchi di dati (non sarebbe una grande percentuale di comandi, ma ce ne sarebbero ancora alcuni), quindi mi piacerebbe ottenere questo aspetto apparentemente banale corretto dall'inizio.

+0

Per quanto mi ricordo, DDD non dice esattamente come implementare il modello di dominio ma CQRS lo fa. Nessun conflitto qui. Per quanto riguarda gli oggetti di comando semplici, come li hai passati ad Aggregati? Immagino tu abbia un'astrazione/un'interfaccia da cui entrambi dipendono. – neleus

+0

Ho passato i dati di comando (non l'oggetto comando effettivo) all'aggregato tramite parametri. Il comando viene ricevuto da un gestore che carica l'aggregato e passa semplicemente ciò di cui ha bisogno tramite un metodo progettato in modo appropriato. Normalmente è solo uno o pochi parametri, che è il modo in cui mi piace, perché credo che un aggregato ben progettato dovrebbe avere metodi che richiedono pochissimi parametri. Altrimenti probabilmente sta violando SRP in qualche modo. Ma ci sono * alcuni casi limite in cui possono essere richiesti molti parametri. – AaronHS

+0

Hai considerato di passare l'intero oggetto comando ad Aggregate? Sembra semplice, senza problemi qui. – neleus

risposta

10

Gli oggetti di comando sono in genere espressi in tipi primitivi mentre le firme di metodo aggregate saranno espresse in concetti di dominio.

Il fatto che non l'abbia immediatamente riconosciuto significa probabilmente che hai perso molte opportunità per rendere espliciti concetti impliciti nel tuo dominio.

"un comando di registrazione che prende in 8+ campi (nome, cognome, nome preferito, data di nascita, titolo, nome utente, password, ecc)" grandi

Quale dovrebbe colpire voi è che firstname e lastname potrebbe sicuramente formare un intero significativo, come ad esempio new FullName(firstname, lastname) e sono sicuro che ci sono molti altri casi in cui Value Objects (VO) potrebbe o dovrebbe essere usato nel tuo dominio ... Username, Password, ecc.? Usare i VO per modellare cose che cambiano insieme descriverà meglio il tuo modello e ridurrà il numero di argomenti che devi passare.

Pertanto, ciò rende gli oggetti di comando candidati poveri come argomenti di metodo aggregati. Se vai su quella strada, perderai sicuramente opportunità di modellazione.

+0

Questo ha perfettamente senso. Grazie per la risposta, oltre a una chiara spiegazione del * perché * – AaronHS

2

Accetto con @plalx.

Prendere i comandi come argomenti di metodo aggregati possono portare ad avere troppi codici di mappatura all'interno di aggregati: Mappatura di tipi primitivi a oggetti di dominio, che è meglio posizionare all'esterno degli oggetti di dominio.

Ma per progetti più semplici, penso che sia un buon inizio.

Nel caso di registrazione, il contesto limitato è in genere un dominio di supporto e la complessità di solito deriva dall'integrazione esterna (notifica e-mail, registrazione con account social, ecc.). In questo caso, penso che l'integrazione del contesto limitata sia più importante dei modelli interni. Quindi prendi i comandi come argomenti di metodo aggregati possono essere un rapido inizio per fare le cose e risparmia il tuo tempo per concentrarti sul tuo dominio principale.