DDD: Come fare riferimento / selezionare un oggetto valore all'interno dell'aggregato?

A seconda del grado di collaborazione della tua applicazione, potresti trovarti nei guai se 2 o più utenti cercano di incrementare contemporaneamente lo stesso Choice . Questo accadrà se si tratta di un VO o di un'entità nello stesso aggregato di Poll .

Per me il confine di consistenza naturale implicito nell'azione di dominio del voto include l'utente. Quindi suggerirei una vera radice di aggregazione PollChoice con un collegamento all'Utente, o se ci sono più scelte per sondaggio, un PollResponse AR contenente tutte le scelte (che possono essere VO) fatte da un particolare utente ad un sondaggio specifico.

Modifica : qualcosa in questo senso

class PollResponse {

  int pollId;
  int userId;
  Choice choice;
  Datetime dateResponded;
}

Credo che un oggetto valore dovrebbe essere riferito al suo valore perché è questo che lo rende unico, né un GUID né un ID locale.

Considera un esempio del mondo reale

1) What web browser do you use at work?

• A) Chrome
• B) Firefox
• C) Internet Explorer
• D) Opera
• E) Safari

2) What web browser do you use at home?

• A) Chrome
• B) Firefox
• C) Internet Explorer
• D) Opera
• E) Safari

Come voteresti nel mondo reale? Probabilmente diresti qualcosa del tipo "Per il primo sondaggio, voto per 'Firefox'" o "Per il secondo sondaggio, scelgo 'A'". Quindi, ci sono alcuni modi per modellare il comportamento di voto

// 1st poll (GUID = 1)
Poll poll1 = pollRepo.find(1);

// 2nd poll (GUID = 2)
Poll poll2 = pollRepo.find(2);

poll1.voteForChoice("Firefox");
poll2.voteForChoice("Chrome");

D'altra parte, non c'è niente di sbagliato nel creare un'istanza di un oggetto valore al di fuori dell'ambito del suo aggregato senza usare un repository

poll1.voteForChoice(new Choice("Firefox"));
poll2.voteForChoice(new Choice("Chrome"));

Quindi, sembra che tu possa utilizzare la seconda opzione per il metodo voteForChoice . Il primo usa ID che suggerisce che Choice s sia modellato come entità. Il terzo si sente sbagliato come un'astrazione che perde e una violazione dell'incapsulamento. Quella precedente è sbagliata a causa dell'utilizzo di un repository per un oggetto valore.

Aggiorna

Punto importante. Non esiste una singola ricetta su come modellare il tuo dominio anche se è un caso comune nel mondo reale. Puoi progettare Choice s come oggetti valore e avere una proprietà Map<Choice, Counter> choices nel tuo Poll s. Oppure puoi progettarlo come entità e avere il contatore come parte di un Choice . Inoltre, potresti voler avere una raccolta List<User> users nell'entità Choice per tenere traccia degli utenti che hanno votato per un particolare Choice .

So di aver reso ancora più confuso per te, ma la cosa che voglio sottolineare è che devi decidere da solo di quale tipo di modello di dominio hai bisogno. La mia risposta si basava sull'ipotesi derivata dalla tua domanda secondo cui gli oggetti valore sono ciò di cui hai bisogno.

UPDATE 2

Si scopre che, secondo Eric Evans, quando si è tentati di creare una sorta di identificatore per un oggetto valore anche se è locale, si dovrebbe considerare di farlo diventare un'entità.