DDD Concepts dans le développement N-Layer

Question

Après avoir passé quelques mois à étudier la méthodologie DDD, j'ai maintenant commencé à appliquer ces concepts dans des produits réels dans mon entreprise. En fait, j'ai été chargé de créer une architecture approprié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 le meilleur pratique:

question n ° 1:DTO - Meilleures pratiques

J'ai mes objets de domaine (classes POCO). Il existe plusieurs façons d'implémenter ces classes.

1. Approche traditionnelle: Créer des classes POCO qui contiennent getters public/setters, validation, & logique commerciale appropriée. Créez également des DTO et utilisez des techniques de cartographie pour les gérer. (Automapper)
2. Traditionnel - DTO: Créez des classes POCO comme indiqué ci-dessus, cependant, utilisez vos objets POCO comme objets de transfert. Je crois comprendre que les objets métier ne doivent jamais quitter le domaine.
3. Hybride: Je suis tombé sur un intéressant blog post dans lequel l'auteur crée ses objets POCO et DTO. À l'intérieur de son objet domaine, il crée une instance du DTO. Cela permet une maintenabilité plus facile car vous ne dupliquez pas vos propriétés comme dans # 1. Comme si:

 
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 renvoyés par l'interface utilisateur/service de couche?

Ceci est le point entier du DTO. Un objet très simple et léger contenant juste les attributs nus. Il ne contient également aucun résultat de validation. Si je remets en série mes DTO au client, il faut supposer que le client a besoin de tous les résultats de Validation comme une collection InvalidRules. Par exemple, disons que je travaille avec l'API d'Amazon. Par exemple,

Je voudrais ajouter un livre à mon magasin personnel. Si j'essaie d'ajouter un livre sans envoyer son ISBN, le service renverra probablement un type de groupe de réponses contenant des erreurs de résultat de validation.

Ai-je raté quelque chose? J'étais sous l'impression (du moins de "puristes" de DDD) que les DTO ne devraient pas contenir de logique métier. Il me semble que les DTO ne fournissent pas suffisamment d'informations en tant qu'objets de transfert. Soit cela ou j'ai besoin d'un nouveau type d'objet Response qui encapsule les résultats DTO et Validation.

Question 3:Combien d'IoC est trop?

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 communiquent tous par un conteneur IoC. Ma couche d'application contient des interfaces communes et des abstractions. Il semble J'adore le fait que je puisse créer des référentiels de tests fictifs - et en changeant simplement la configuration d'Unity, je peux utiliser TDD

J'espère avoir clairement posé ces questions. 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, les DTO n'ont pas leur place dans un modèle de domaine car ils n'ont aucun comportement et conduiront ainsi à Anemic Domain Models.

POCOs avec persistance L'ignorance est la voie à suivre. Jeremy Miller a un bon article that explains this concept.

Réponse 2

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 les interfaces utilisateur, le modèle MVVM fonctionne particulièrement bien. This article introduit MVVM pour WPF, mais le modèle fonctionne également comme un charme dans ASP.NET MVC.

Pour les services Web, c'est là que le modèle DTO s'applique. Les contrats de données WCF sont des DTO, au cas où vous vous le demanderiez :)

Cela nécessitera beaucoup de mappage entre l'interface de service et le modèle de domaine, mais c'est le prix à 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 dépendre du conteneur DI.

Voir this SO answer pour plus de détails.