DDD Concepts dans le développement N-couche

Question

Après avoir passé deux mois étudier la méthodologie DDD, j'ai maintenant commencé à appliquer ces concepts en produits réels de mon entreprise. En fait, je l'ai été chargé de créer une architecture adaptée et maintenable pour le développement futur.

Nous avons décidé d'utiliser les technologies suivantes: EF4 (vraiment v2), l'unité

La quantité d'informations que j'ai obtenu a été cependant très instructif, je suis parti avec plusieurs questions dans les meilleures pratiques:

Question n ° 1: DTO - Meilleures pratiques

J'ai mes objets de domaine (classes POCO). Il existe plusieurs façons de mettre en œuvre ces classes.

1. Approche traditionnelle: Créer des classes POCO qui contiennent getters publics / setters, la validation, et la logique métier appropriée. Créer DTO et utiliser des techniques de cartographie pour les gérer. (Automapper)
2. traditionnelle - DTO: Créer des classes POCO comme indiqué ci-dessus, cependant, utiliser votre Poços comme des objets de transfert. Je crois comprendre que les objets d'affaires ne devraient jamais quitter le domaine cependant.
3. Hybride: je suis tombé sur un intéressant blog dans lequel l'auteur crée ses objets POCO et DTO. A l'intérieur de son objet de domaine, il crée une instance de la DTO. Cela permet plus facilement maintenabilité que vous n'êtes pas dupliquer vos propriétés comme dans # 1. Comme ceci:

public abstract class POCOBase<T> : ValidationBase, IPOCO where T : DTOBase, new()
{

 public T Data { get; set; }

 public POCOBase()
 {
     Data = new T();
 }

 public POCOBase(T dto)
 {
     Data = dto;
 }
  }

  public class SomePOCO : POCOBase { }

  public class SomeDTO : DTOBase

  {

 public String Name { get; set; }

 public String Description { get; set; }

 public Boolean IsEnabled { get; set; }
}


// EXAMPLES
// POCOBase<SomeDTO> somePOCO = new SomePOCO();
// somePOCO.Data.Name = "blablabla";
// somePOCO.Validate();
// return somePOCO.Data;

Question n ° 2: Quels objets doivent être retournés par l'interface utilisateur / service couche

Ceci est le point de l'ensemble de la DTO. Un très simple, objet léger contenant uniquement les attributs nus. Il est également ne contenant aucun résultat de validation en elle. Si je sérialisation mes DTO au client, il faut supposer que le client a besoin des résultats de validation comme une collection InvalidRules.

Par exemple, disons que je travaille avec l'API d'Amazon. Je voudrais ajouter un livre à mon magasin personnel. Si j'essaie d'ajouter un livre sans envoyer son ISBN, le service retournerait probablement une sorte de groupe de réponse qui contient des erreurs de résultat de validation.

Est-ce que je manque quelque chose? J'avais l'impression (au moins de DDD « puristes ») que DTO ne doivent pas contenir la logique métier. Il me semble DTO ne fournissent pas suffisamment d'informations comme des objets de transfert. Soit ça ou je besoin d'un nouveau type d'objet de réponse qui encapsule la DTO et validation des résultats.

Question n ° 3: Combien est trop IoC

Il me semble évident que je devrais suivre la règle d'or:

  

"Identifier les parties de l'application   qui varient, et séparés de ceux   qui restent les mêmes. "

Pour moi, cela a du sens en termes d'application IoC. Pour réduire les dépendances, ma présentation, Business Logic et des couches d'accès aux données tous communiquent via un conteneur IoC. Ma couche d'application contient des interfaces communes et des abstractions. Il semble exagéré d'utiliser IoC beaucoup plus que cela. J'aime le fait que je peux créer Référentiels de test de simulation - et en changeant simplement la configuration de l'unité, je peux utiliser TDD

.

J'espère que je l'ai dit clairement à ces questions. Merci pour votre aide à l'avance!

Answer 1

Je vais essayer de répondre à vos questions une à la fois.

Réponse 1

DTO sont orthogonales à DDD parce qu'ils servent un but différent dans un endroit différent dans l'architecture d'une application. Cela dit, DTO n'a pas sa place dans un modèle de domaine parce qu'ils ont pas de comportement et conduira donc à Anemic modèles de domaine .

Poços avec la persistance de l'ignorance est la voie à suivre. Jeremy Miller a une bonne qui explique ce concept .

Réponse 2

Les couches qui sont assis sur le dessus du modèle de domaine ont souvent besoin de retourner leurs propres objets qui sont adaptés à cet effet en question.

Pour UIs, le modèle MVVM fonctionne particulièrement bien. Cet article présente MVVM pour WPF, mais le modèle fonctionne aussi comme un charme dans ASP.NET MVC.

Pour les services Web, c'est là le motif DTO applique. WCF données sur les contrats sont DTO, au cas où vous vous demandiez:)

Cela nécessitera beaucoup de cartographie va-et-vient entre l'interface de service et le modèle de domaine, mais c'est le prix que vous devez payer pour Supple design. Vous pouvez trouver AutoMapper utile à cet égard.

Réponse 3

Plus IoC (vraiment: DI) mieux, mais une chose au sujet de votre question m'a frappé: un conteneur DI ne doit câbler le graphe d'objet, puis sortir de la voie. Les objets ne doivent pas compter sur le conteneur DI.

Voir cette réponse SO pour plus de détails.