Valuta gli oggetti in CQRS: dove utilizzare

Question

Supponiamo che abbiamo l'architettura ispirata a CQRS, con componenti come comandi, modello di dominio, eventi di dominio, leggi i DTOS del modello.
Naturalmente, possiamo usare gli oggetti di valore nel nostro modello di dominio. La mia domanda è: se dovessero essere usati anche in:

1. Comandi
2. Eventi
3. Dtos

Non ho visto esempi in cui gli oggetti del valore (VO) sono usati nei componenti sopra menzionati. Invece, vengono utilizzati tipi primitivi. Forse sono solo gli esempi semplicistici. Dopotutto, la mia comprensione dell'uso di VOS in DDD è che fungono da colla per l'intera applicazione.

La mia motivazione:

Comandi.
Supponiamo che l'utente presenta un modulo che contiene campi di indirizzo. Abbiamo un valore di valore per rappresentare questo concetto. Quando costruiamo il comando nel client, dovremmo comunque convalidare l'input dell'utente e quando è ben formato, possiamo creare un oggetto indirizzo proprio lì e inizializzare il comando con esso. Non vedo alcuna necessità di delegare la creazione dell'oggetto indirizzo al gestore di comandi.

Eventi di dominio.
Il modello di dominio opera già in termini di oggetti di valore, quindi pubblicando eventi con VOS invece di convertirli in tipi primitivi, possiamo evitare un po 'di codice di mappatura. Sono abbastanza sicuro che vada bene usare VOS in questo caso.

Dtos.
Se i nostri DTO sul lato della query possono contenere oggetti di valore, ciò consente una maggiore flessibilità. Ad esempio, se abbiamo un oggetto monetario, possiamo scegliere se visualizzarlo in EUR o USD, non è necessario modificare il modello di lettura.

Answer 1

Ok, ho cambiato idea. Ultimamente ho cercato di avere a che fare con Vos a Bunch e dopo aver visto questo http://www.infoq.com/presentations/value-objets-dan-bergh-johnsson Mi ha chiarito un paio di cose.

I comandi e gli eventi sono messaggi (e non oggetti, gli oggetti sono comportamenti dati +), per alcuni aspetti molto simili a DTOS, comunicano i dati su un evento e non incapsulano alcun comportamento.

Gli oggetti del valore non sono affatto come DTOS. Sono una rappresentazione del dominio e sono, in generale, ricchi di comportamenti come tutte le altre rappresentazioni del dominio.

I comandi e gli eventi comunicano rispettivamente informazioni sul dominio, ma essi stessi non incapsulano alcun comportamento. Da quella prospettiva sembra sbagliato e forse un contesto di violazione dei confini per passare Vos all'interno di loro.

Per parafrasare Oren (anche se si riferiva a Nhibernate e WCF) "non inviare il tuo dominio attraverso il filo".http://ayende.com/blog/archive/2009/05/14/the-stripper-pattern.aspx

Se si desidera comunicare un oggetto Value, suggerisco invece di passare gli attributi necessari per ricostruire il VO dentro di loro.

Testo originale (per posteri):

Se stai chiedendo se gli oggetti di valore possano essere approvati dal modello di dominio agli eventi o trasmessi dai comandi, non vedo davvero un grosso problema con il primo, sebbene il secondo possa violare alcune delle regole della radice aggregata essendo la "Proprietario" dei valori.

Detto questo, un oggetto di valore rappresenta concetti come ad esempio un colore. Non lo fai avere verde, tu sono verde o no. Sembra che non ci sia nulla di intrinsecamente sbagliato in un comando che ti dice che sei verde passando questo.

Leggere il capitolo di DDD sul modello di radice aggregata spiega abbastanza bene le entità e gli oggetti di valuta e vale la pena leggere per alcune volte.

Answer 2

Dico che è una cattiva idea.

C'è una ragione per cui non facciamo lo stesso con le entità: per evitare di accoppiarsi altre parti del sistema al dominio (nei luoghi sbagliati). Lo stesso vale per gli oggetti di valore, l'unica differenza tra oggetti di valore ed entità è la vita e la proprietà: queste differenze non influiscono su come dovremmo e non dovremmo accoppiarli.

Immagina di fare un evento contenere un VO. Un cambiamento nel tuo dominio richiede di cambiare quel VO. Ora ti sei inscatolato in un angolo dove si trova anche il tuo evento costretto Per cambiare, idem per qualsiasi comando o dto è una parte di.

Questo deve essere evitato.

Usa DTO e/o primitivi. Mappari (Automapper lo rende un accordo a 1 riga).

Answer 3

Simile ad altre risposte, in SOA questo spezzerebbe l'incapsulamento del servizio mentre il dominio sta perdendo.

Answer 4

Secondo Codice pulito I tuoi DTO sono strutture di dati (solo per aggiungere un altro termine), mentre gli oggetti di valore sono oggetti. La differenza che gli oggetti possono avere un comportamento. La miscelazione delle strutture di dati con gli oggetti è generalmente una pessima idea, perché sarà difficile mantenere l'ibrido che ottieni.

Non mi sento bene di mettere gli oggetti di valore anche a DTOS dal punto di vista dell'architettura. Gli oggetti del valore sono all'interno del modello di dominio mentre i DTOS menzionati stanno definendo l'interfaccia del modello. Di solito costruiamo un'interfaccia per disaccoppiare il mondo esterno dall'interno di qualcosa. Quindi, nel caso attuale, abbiamo aggiunto DTOS per disaccoppiare il mondo esterno dagli oggetti di valore (e altre cose relative al modello). Dopodiché aggiungere oggetti di valore all'interfaccia è pazzo.

Quindi non hai ancora incontrato questa soluzione perché è un anti-pattern.