Un oggetto Value può esistere da solo?

-2

Ho letto questo: link , che dice sì e questo: link , che dice no (" oggetti di valore non possono vivere da soli "). Quindi ho un semplice esempio:

Opzione 1

public class DenominationsRequired
{
    public IEnumerable<System.Collections.Generic.KeyValuePair<decimal, int>> CalculateDenominations(decimal cost, ICurrency currency)
    {

    }
}

Opzione 2

Credo che sia simile al tipo di data in .NET, che ha metodi che restituiscono ogni volta una nuova data:

public sealed class DenominationsRequired
    {
        private readonly decimal _cost;
        private readonly ICurrency _currency;

        public DenominationsRequired(decimal cost, ICurrency currency)
        {
            _cost = cost;
            _currency = currency;
        }

        public IEnumerable<System.Collections.Generic.KeyValuePair<decimal, int>> CalculateDenominations()
        {

        }
    }

L'opzione 1 restituisce le denominazioni richieste per soddisfare un costo in un servizio di dominio e l'opzione 2 fa la stessa cosa di un oggetto valore. Ho pensato ai seguenti criteri per la scelta tra un servizio di dominio e un oggetto valore:

1) Se la classe viene chiamata una volta da un servizio applicativo, un servizio di dominio è appropriato.

2) Se la classe è usata da un'entità o da un altro oggetto valore, allora un oggetto valore è appropriato. Nota che il mio primo link qui sopra sembra contraddire questo.

3) Un'entità non è appropriata qui perché l'oggetto non ha identità e continuità. Credo che potrei creare un GUID e renderlo un'entità, tuttavia questa sembra una cattiva idea.

Credo che questo dovrebbe essere un servizio di dominio basato sulla mia analisi. Ho capito bene? Ci sono dei difetti nei criteri sopra?

    
posta w0051977 09.04.2018 - 09:01
fonte

2 risposte

0

If the class is called once by an application service then a domain service is appropriate.

Normalmente mi aspetto che un dominio venga invocato dal modello di dominio; il modello di dominio viene in genere utilizzato per fornire l'accesso aggregato a informazioni o funzionalità al di fuori del proprio limite.

Can a Value object exist on its own?

Fondamentalmente, "oggetti valore" esistono perché (a) Domain Driven Design è stato prima documentato in un contesto (Java) in cui tutto è un "oggetto", e (b) perché vogliamo una rappresentazione più specifica del dominio primitive agnostiche fornite dal runtime della lingua.

Quindi chiedendo "un oggetto valore può esistere da solo?" è analogo a chiedere "può esistere il numero intero 7?"

Normalmente non avremo un repository per 7 ; caricheremo e archiveremo quel valore come parte della rappresentazione dello stato di qualche entità, tramite il suo repository. Lo stesso vale per gli oggetti valore: non avranno un ciclo di vita proprio.

Detto questo, è abbastanza comune che gli oggetti valore siano passati come argomenti, distaccati da una particolare entità, più o meno allo stesso modo in cui passiamo gli interi come argomenti. Lo facciamo quando il ricevitore non / non si preoccupa del contesto da cui è stato recuperato l'argomento.

Un problema interessante è cosa fare quando un aggregato ha bisogno di accedere ai dati caricati da da qualche altra parte ? Credo che Evans abbia usato l'esempio di una tabella delle tasse nel libro blu; qui potrebbe essere la tua lista di denominazioni. Quindi potresti chiedere "dovrei passare un servizio di dominio, o un oggetto valore immutabile, a questo aggregato che ha bisogno di accedere a questo stato memorizzato esternamente". La mia ipotesi è che, a lungo termine, il passaggio in un servizio di dominio sarà l'opzione più flessibile. Ma non penso di aver visto un buon studio delle alternative.

    
risposta data 09.04.2018 - 16:08
fonte
1

Sembra che tu stia mescolando due problemi diversi. Il titolo della domanda è un problema separato da quello che chiedi nei contenuti.

  • Un oggetto Value può esistere da solo?

Ripeterò ciò che ho scritto nella risposta SO che hai menzionato - per me, un oggetto valore può esistere perfettamente da solo in modo transitorio . Perché una valuta, un paese o un colore dovrebbero essere necessariamente legati a un tipo di entità? Ciò impedirebbe anche ai Servizi di dominio di utilizzare oggetti valore diversi da quelli che ricevono attraverso i riferimenti alle entità, il che è abbastanza strano.

Questa parte dell'articolo a cui ti sei collegato sembra un non-sequitur per me:

Value objects, at the same time, have a zero lifespan. We create and destroy them with ease. That’s a corollary of being interchangeable. If this 1 dollar bill is the same as another one, why bother? We can just replace the existing object with the one we just instantiated and forget about it altogether.

A guideline that flows from this distinction is that value objects cannot live by their own, they should always belong to one or several entities. The data a value object represents has a meaning only in the context of an entity it refers to.

Non riesco a vedere il link qui. Di nuovo, perché agli oggetti non entità sarebbe vietato creare e manipolare oggetti valore nel proprio contesto?

  • Quali sono i buoni criteri per scegliere tra Value Object e Domain Service?

1) If the class is called once by an application service then a domain service is appropriate.

2) If the class is used by an entity or other value object then a value object is appropriate. Note that my first link above seems to contradict this.

Applico criteri diversi. Utilizzare un servizio di dominio per la logica che si trova all'incrocio di più entità. Al contrario, un oggetto valore riguarda solo i propri dati: non conosce quasi mai un'entità.

    
risposta data 09.04.2018 - 11:45
fonte

Leggi altre domande sui tag