Setters dans le modèle de domaine

Question

Dans le cadre de setters DDD sur un modèle de domaine sont une odeur de code. Ils doivent être évités pour la simple raison qu'ils ne sont pas vraiment partie du domaine. Il n'y a pas les noms dans ce domaine qu'un expert peut comprendre et modifier les données doivent passer par des méthodes spécifiques de la place.

Exemple:

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

Alors que la bonne façon de le faire serait d'avoir une méthode customer.ChangeAddress qui pourrait alors publier un événement etc etc .. Au moins je comprends bien tout cela est la théorie du son et je peux tout à fait comprendre pourquoi setters dans un modèle de domaine ne sont pas vraiment appréciable.

MAIS: Sans setters sur votre modèle de domaine, ces méthodes deviennent assez difficiles à tester.

Comment puis-je obtenir une instance de client pour exécuter mes tests contre si je ne peux pas construire un sans avoir soit un constructeur grand-cul qui prend en arguments tous, ou faire un peu de magie de réflexion? J'utilise NHibernate dans le back-end si NHibernate déjà fait un peu de magie de réflexion pour remplir ces champs en premier lieu.

Mais il se sent vraiment mauvais d'avoir un cteur avec 10 arguments .. (Et même serait vrai pour une méthode de fabrication).

Un conseil à ce sujet?

salutations Daniel

Answer 1

classique (non CQRS) DDD est une bonne pratique de facteur toutes les données à la valeur des objets afin que vos entités sont réduits à leur fonction principale: le maintien de l'identité.

vous par exemple si le Client référence une adresse ValueObject et une méthode ChengeAddress qui devrait être aussi simple que:

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

Essayez de déplacer autant de logique que vous pouvez de vos entités à vos objets de valeur. Ils sont par nature plus testable car l'objet de bonne valeur est petite et immuable. Vous utilisez un constructeur pour instancier VO dans un état donné et l'exercice (habituellement en invoquant une méthode qui retourne une autre, transformé, par exemple VO).

Last but not least, de mon expérience, je peux dire que si le test de votre modèle de domaine nécessite des infrastructures supplémentaires (comme la réflexion ou tout autre outil), vous le faites mal (en introduisant un couplage inutile).

Answer 2

Vous pouvez essayer AutoFixture .

Mélanger dans un amour de réflexion bits et domaine devient assez testable:

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;
    }
  }
}

Utilisation:

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

Vous devriez au moins essayer de diviser ces objets « grand-cul » en plus petits. Essayez de faire une hiérarchie (assurez-vous qu'il est compatible avec le langage omniprésent).