1. #1
    Membre habitué
    Inscrit en
    avril 2003
    Messages
    396
    Détails du profil
    Informations forums :
    Inscription : avril 2003
    Messages : 396
    Points : 134
    Points
    134

    Par défaut Quelle(s) couche(s) doi(ven)t valider les données en D.D.D.

    Bonjour,

    Prérequis pour s'entendre
    La couche User représente un contrôleur.
    La couche User et Application n'échange que des DTO.
    La couche Application expose des services de type Handler, manipule des Entités du Domain, gère la persistance, fait abstraction des services qu'elle utilise (repository, infra, ...), etc.

    Question 1
    Que représente la flèche entre User et Domain ?

    Nom : Domain-Driven-Design-Overview-of-a-Layered-Architecture.png
Affichages : 224
Taille : 47,5 Ko

    Question 2
    Avec le DDD, à quel niveau effectuer ces types de validation différents :
    1/ Le champ est obligatoire ?
    2/ Le champ doit respecter le pattern e-mail ?
    3/ Véritable règle métier : état de l'objet impossible ?
    4/ L'utilisateur n'est pas autorisé à effectuer cette action ?

    Propositions :
    A/ Dans la couche User uniquement ?
    B/ Dans la couche Application uniquement ?
    C/ Dans la couche Model uniquement ?
    D/ Dans plusieurs couches, lesquelles ?

    Merci

  2. #2
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    777
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 777
    Points : 2 833
    Points
    2 833

    Par défaut

    Hello,

    L'architecture en couches décrite dans le livre de 2003 n'est pas la partie de DDD qui a été "retenue par l'Histoire". Il ne faut pas trop la prendre au pied de la lettre. Elle reflétait essentiellement le modèle en couches avec des dépendances assez libres qui prédominait à l'époque mais posait un certain nombre de problèmes. Des nomenclatures plus judicieuses favorisant le couplage faible et tirant parti de l'inversion de dépendance sont apparues depuis, notamment Hexagonal Architecture et Onion Architecture.

    Question 1
    Que représente la flèche entre User et Domain ?
    Ca peut correspondre à un Domain Service qui appelle un Repository ou un système de messaging externe, mais on ne le ferait plus trop avec une architecture DDD typique aujourd'hui. On a tendance à isoler complètement la couche Domaine du reste du monde. A la limite, s'il n'y a vraiment pas d'autre solution, on le fait en utilisant l'injection de dépendances : le DomainService ne connait qu'une interface de Repoistory déclarée à l'intérieur de la couche domaine, et on lui injecte une implémentation de ce Repo de la couche Infrastructure au runtime.

    Question 2
    Avec le DDD, à quel niveau effectuer ces types de validation différents :
    1/ Le champ est obligatoire ?
    2/ Le champ doit respecter le pattern e-mail ?
    3/ Véritable règle métier : état de l'objet impossible ?
    4/ L'utilisateur n'est pas autorisé à effectuer cette action ?
    Réponse bête et méchante : au-delà de "les objets du Domaine doivent rester consistants", DDD ne va pas dans ce détail de préconisation sur des cas aussi particuliers. C'est à chacun de se faire ses bonnes pratiques qui peuvent aussi dépendre de l'état de l'art de sa techno.

    Réponse subjective :

    1/ et 3/ A la fois Domaine et Présentation. En général en web, ce dernier se traduit par une validation côté client (en JS) et côté serveur (à la création de l'objet représentant l'input de l'utilisateur). Le JS peut être auto généré à partir des modèles de présentation dans certaines technos.

    2/ : Au moins Présentation et on peut pousser le vice jusqu'au domaine si on est très strict.

    4/ C'est appelé par la couche Application ou à la rigueur Présentation. Qui plus est, la gestion des droits est une responsabilité transverse qui peut avoir son propre Bounded Context avec éventuellement sa propre couche Domaine, donc éventuellement défini dans un domaine (celui du Bounded Context "gestion des droits").

  3. #3
    Membre habitué
    Inscrit en
    avril 2003
    Messages
    396
    Détails du profil
    Informations forums :
    Inscription : avril 2003
    Messages : 396
    Points : 134
    Points
    134

    Par défaut

    Salut Luckyluke34,

    Citation Envoyé par Luckyluke34 Voir le message
    Hexagonal Architecture et Onion Architecture.
    Oui vu et très intéressant, les interfaces sont déjà au coeur de notre projet mais l'étape d'après sera de définir plusieurs hexagones (selon les Bounded Context).

    Citation Envoyé par Luckyluke34 Voir le message
    On a tendance à isoler complètement la couche Domaine du reste du monde.
    Oui, plutôt d'accord.

    Citation Envoyé par Luckyluke34 Voir le message
    1/ et 3/ A la fois Domaine et Présentation. En général en web, ce dernier se traduit par une validation côté client (en JS) et côté serveur (à la création de l'objet représentant l'input de l'utilisateur). Le JS peut être auto généré à partir des modèles de présentation dans certaines technos.

    2/ : Au moins Présentation et on peut pousser le vice jusqu'au domaine si on est très strict.

    4/ C'est appelé par la couche Application ou à la rigueur Présentation. Qui plus est, la gestion des droits est une responsabilité transverse qui peut avoir son propre Bounded Context avec éventuellement sa propre couche Domaine, donc éventuellement défini dans un domaine (celui du Bounded Context "gestion des droits").
    Voici mon avis :

    1/ et 2/ La couche Présentation (JS ou contrôleur) et surtout Domain.
    Nous ne sommes pas d'accord sur le 2 mais c'est parce que tu validerais le pattern e-mail dans le DTO ? Pourquoi valider différement le point 1 du 2 ?

    3/ Uniquement dans Domain.
    Nous ne sommes pas entièrement d'accord, tout dépend après de l'interprétation.

    4/ Présentation pour gérer les droits d'accès à une vue et Application.
    Nous sommes d'accord.

    Qu'en penses-tu ? D'autres avis ?

    Merci

  4. #4
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    777
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 777
    Points : 2 833
    Points
    2 833

    Par défaut

    Citation Envoyé par dorian53 Voir le message
    Nous ne sommes pas d'accord sur le 2 mais c'est parce que tu validerais le pattern e-mail dans le DTO ? Pourquoi valider différement le point 1 du 2 ?
    Alors, actuellement chez nous on ne valide les éléments de "saisie" (absence de caractères spéciaux, majuscules/minuscules, etc.) que dans la couche présentation, et on considère que le format de l'email en fait partie. C'est un choix. Mais oui dans l'absolu ça serait bien aussi de le valider dans le domaine. Comme je disais, pas de règle universelle.

    Citation Envoyé par dorian53 Voir le message
    3/ Uniquement dans Domain.
    Nous ne sommes pas entièrement d'accord, tout dépend après de l'interprétation.
    Oui, autant pour moi, je voulais dire que par la force des choses il ne devrait jamais être permis de transitionner vers cet état invalide via l'UI. Mais ce n'est pas une validation dans la couche Présentation à proprement parler, tu as raison.

Discussions similaires

  1. Impossible de valider les données
    Par tom974 dans le forum Configuration
    Réponses: 12
    Dernier message: 12/11/2009, 10h03
  2. Impossible de valider les données
    Par tom974 dans le forum SharePoint
    Réponses: 9
    Dernier message: 01/10/2009, 11h11
  3. Valider les données winForm
    Par Msysteme dans le forum C#
    Réponses: 13
    Dernier message: 25/03/2009, 17h16
  4. [2.2.2] Valider les données XML par XSD
    Par Epsilon38 dans le forum BIRT
    Réponses: 3
    Dernier message: 25/03/2009, 15h52
  5. Valider les données d'un formulaire
    Par bdminc dans le forum Formulaires
    Réponses: 3
    Dernier message: 20/09/2007, 17h13

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo