Discussion :

[dorian53]

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 ?



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

[Luckyluke34]

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").

[dorian53]

Salut Luckyluke34,

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).

On a tendance à isoler complètement la couche Domaine du reste du monde.

Oui, plutôt d'accord.

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

[Luckyluke34]

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.

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.