comportamento dell'oggetto del valore di progettazione basato sul dominio

Question

comportamento dell'oggetto del valore di progettazione basato sul dominio

#1 da (0 voti)

0

Ho recentemente terminato l'eccellente corso di Pluralsight di Steve Smith e Julie Lerman su Domain Driven Design e sto applicando la formazione a un progetto. Ho quello che penso sia un buon candidato per un oggetto di valore: MeasurementSpecification. Nel dominio del problema, una specifica di misurazione ha sempre un valore nominale, una tolleranza minima e una tolleranza massima. Un modello può apparire in questo modo:

public class MeasurementSpecification
{
    public Decimal NominalValue { get; private set; }
    public Decimal UpperToleranceLimit { get; private set; }
    public Decimal LowerToleranceLimit { get; private set; }

    ...setters and behaviors...        
}

E entità come segue:

public class WidgetDescription // may be a candidate as another value object, but that's probably another discussion.
{
    public int Id {get; private set;}
    public String Description {get; private set;}
    public MeasurementSpecification Specification {get; private set;}
    ...setters and behaviors... 
}

public class Widget
{
    public int Id {get; private set;}
    public WidgetDescription WidgetDescription {get; private set;}
    public decimal MeasurementValue {get; private set;}
    ...setters and behaviors... 
}

Sto lottando con quale classe dovrebbe avere la responsabilità di convalidare che un valore di misurazione rientra nelle specifiche. La mia prima inclinazione è quella di assegnare il comportamento a MeasurementSpecification poiché anche altre entità potrebbero avere l'oggetto valore MeasurementSpecification come una delle sue proprietà. Un modello aggiornato potrebbe essere simile a:

public class MeasurementSpecification
{
    ...

    public Boolean IsWithinSpec(Decimal measurementValue)
    {
        return (measurementValue >= LowerToleranceLimit && measurementValue <= UpperToleranceLimit) ? true : false;
    }
}

Ma potrei anche capire perché l'entità Widget potrebbe avere il proprio comportamento di convalidare il proprio valore di misurazione rispetto a una specifica:

public class Widget 
{
    ...
    public Boolean IsWithinSpec() 
    {
        return this.WidgetDescription.MeasurementSpecification.IsWithinSpec(this.MeasurementValue)
    }
}

L'approccio di includere il comportamento in entrambi i posti complica le cose? Mi manca qualcosa?

domain-driven-design object-oriented-design value-object

posta tonyapolis 20.02.2015 - 18:32

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design object-oriented-design value-object

Modifica del modello di una direttiva in base allo stato Motivo per cui JavaScript sul lato client non consente l'accesso ai contenuti POST / PUT / etc

score 0 · Accepted Answer

L'IsWithinSpec suggerito in Widget-Class conosce troppi dettagli di implementazione sulla classe WidgetDescription, ad es. che contiene una MeasurementSpecification. Un cosiddetto TrainWreck . Potresti invece creare un metodo nella classe WidgetDescription e delegare lì.

public class Widget 
{
    ...
    public Boolean IsWithinSpec() 
    {
        return this.WidgetDescription.IsWithinSpec(this.MeasurementValue)
    }
}

public class WidgetDesciption
{
    ...
    public Boolean IsWithinSpec(Decimal measurementValue) 
    {
        return this.MeasurementSpecification.IsWithinSpec(measurementValue)
    }
}

Ciò ridurrà le dipendenze non necessarie e renderà il tuo codice più facile da testare e avrai bisogno di meno derisioni durante il test.

hth.