Setter in Domain Model

Question

Nel contesto di setter DDD su un modello di dominio sono un odore di codice. Essi dovrebbero essere evitati per la semplice ragione che in realtà non sono parte del dominio. Non ci sono nomi in esso che un esperto di dominio può capire e modifiche ai dati dovrebbe passare attraverso metodi specifici, invece.

Esempio:

customer.StreetName = ...
customer.City = ...

Mentre il modo giusto per farlo sarebbe quello di avere un metodo customer.ChangeAddress che potrebbe quindi pubblicare un evento ecc ecc .. almeno dalla mia comprensione di tutto questo è la teoria del suono e posso assolutamente capire perché setter in un modello di dominio non sono davvero desiderabile.

MA: Senza setter sul modello di dominio, quei metodi ottengono piuttosto difficile da test.

Come faccio a ottenere un'istanza di Customer per eseguire le mie prove contro se non riesco a costruire uno senza avere né un costruttore big-ass che abbraccia argomenti tutti, o fare un po 'di magia di riflessione? Io uso NHibernate nel backend così NHibernate già fa qualche magia riflessione per compilare questi campi, in primo luogo.

Ma ci si sente davvero male per avere un ctor con 10 argomenti .. (E lo stesso sarebbe vero per un metodo di fabbrica).

Qualche consiglio su questo?

saluti Daniel

Answer 1

Nel classico (non CQRS) DDD è una buona pratica per fattore di tutti i dati di valore oggetti in modo che le entità sono ridotti alla loro funzione primaria: il mantenimento di identità.

In ti esempio Cliente deve fare riferimento a un indirizzo ValueObject e avere un metodo che dovrebbe essere ChengeAddress sarebbe semplice come:

public void ChangeAddress(Address address)
{
   //Consistency rules are here
   _address = address;
}

Provare a spostare il più logica possibile dai vostri soggetti agli oggetti di valore. Essi sono intrinsecamente più verificabili dal valore oggetto buono è piccolo e immutabile. Si utilizza un costruttore per VO instantiate in un determinato stato e lo esercitano (di solito invocando un metodo che restituisce un altro, trasformato, esempio VO).

Ultimo ma non meno importante, dalla mia esperienza posso dire che se testare il modello di dominio richiede ulteriori infrastrutture (come riflesso o qualsiasi altro strumento), si sta facendo male (con l'introduzione di accoppiamento non necessaria).

Answer 2

Si potrebbe desiderare di provare AutoFixture .

Mix in un amore po 'di riflessione e di dominio diventa piuttosto testabili:

namespace Unit{
  using System;
  using System.Linq.Expressions;
  public static class ObjectExtensions{
    public static T Set<T,TProp>(this T o,
      Expression<Func<T,TProp>> field,TProp value){

      var fn=((MemberExpression)field.Body).Member.Name;
      o.GetType().GetProperty(fn).SetValue(o,value,null);
      return o;
    }
  }
}

Utilizzo:

myUberComplexObject.Set(x=>x.PropertyOfIt, newValueOfIt);

e si dovrebbe almeno cercare di dividere gli oggetti "big-ass" in quelle più piccole. Provate a fare una gerarchia (basta assicurarsi che sia compatibile con il linguaggio onnipresente).