Dans DDD, la logique d'application de validation ou la logique de domaine est-elle?
Supposons que nous modélisons un formulaire en utilisant DDD; le formulaire peut être associé à un certain type de règles commerciales - vous devrez peut-être spécifier un revenu si vous n'êtes pas étudiant, et vous devez répertorier vos enfants si vous indiquez que vous êtes marié. Et si vous avez spécifié un pays, il doit avoir un pays valide.
Ce type de validation existe-t-il dans le domaine ou la couche d'application? Quelques autres questions que je considérais:
Certains frameworks, tels que Laravel, fournissent des règles de validation qui peuvent valider l'entrée avant qu'une requête n'atteigne le contrôleur. Est-ce qu'il casse DDD si la validation est effectuée à ce niveau?
Pour des cas comme déterminer si le pays est valide, je vais généralement interroger une table de base de données de tous les pays du monde. Cependant, dans DDD, cela est susceptible (d'après ma compréhension) de se faire sur la couche domaine. La couche de domaine est-elle autorisée à accéder à la base de données ou dois-je utiliser une recherche non SQL pour déterminer un pays valide?
Est-il nécessaire de valider l'entrée à la fois au niveau de l'application et de la couche domaine?
Ce type de validation existe-t-il dans le domaine ou la couche d'application?
Application. Le terme de recherche magique que vous souhaitez est couche anti-corruption
En règle générale, le message reçu par votre application aura une certaine saveur de DTO. Votre couche anti-corruption créera généralement des types de valeur que le domaine reconnaîtra. La commande réelle envoyée au modèle de domaine sera exprimée en termes de types de valeurs validées.
Exemple: une commande DepositMoney comprendrait probablement un montant et un type de devise. La représentation DTO exprimerait probablement le montant sous forme d'entier et le code de devise sous forme de chaîne. La couche anti-corruption convertirait le DTO en un type de valeur de dépôt, qui comprendrait un montant validé (qui doit être non négatif) et un CurrencyCode validé (qui doit être l'un des codes pris en charge dans le domaine).
Après avoir analysé avec succès la commande en types que le modèle de domaine comprend, la commande est exécutée dans le domaine, qui peut toujours rejeter la commande au motif qu'elle violerait l'invariant métier (le compte n'existe pas encore, le compte est bloqué, ce compte particulier n'est pas autorisé à utiliser cette devise? etc.).
En d'autres termes, la validation métier va se produire dans le modèle de domaine, après que la couche anti-corruption aura validé les entrées.
L'implémentation des règles de validation vivra normalement soit dans le constructeur du type de valeur, soit dans la méthode d'usine utilisée pour construire le type de valeur. Fondamentalement, vous limitez la construction des objets afin qu'ils soient garantis valides, en isolant la logique en un seul endroit et en l'invoquant aux limites du processus.
Votre modèle de domaine problématique inclut vos règles commerciales de domaine. Les règles métier sont des contraintes sur les éléments du modèle. Cela signifie qu'un ascenseur ne bouge pas avec la porte ouverte, que les denrées périssables ne sont pas chargées dans un conteneur non réfrigéré et qu'une commande annulée n'est pas expédiée.
Cela ne signifie pas que lorsque votre domaine interagit avec des humains (via des écrans, des formulaires, etc.), il n'y a pas besoin de validation ou d'assistance. Rendez-vous compte que c'est facultatif.
Sachez qu'il existe deux types de règles métier: - les règles de propriété qui contraignent les attributs d'un objet et les règles de collaboration qui contraignent l'ajout et la suppression de collaborations entre les objets.
Les règles métier sont différentes des règles logiques, qui sont liées à votre langage de programmation et vérifient que les valeurs ont été fournies et ne sont pas nulles, etc.
Remarque: il n'y a aucun concept dans DDD de "modélisation" de votre formulaire.
Un état spécifique rendrait-il invalide l'entité modèle? Si oui, le modèle doit empêcher l'entité d'atteindre cet état. Cela signifie que le modèle doit savoir se valider.
Mais il y a un petit problème: la validation du modèle arrive souvent trop tard. Souvent, nous voulons effectuer la validation tôt, afin que l'utilisateur n'ait pas à attendre trop longtemps. C'est pourquoi la validation est souvent placée dans la logique d'application.
Quant au contexte de validation: Il n'y a aucun problème d'entité pouvant demander des données supplémentaires. Mais il ne devrait pas se soucier d'où viennent ces données. Peu importe qu'il provienne de SQL, de fichier ou qu'il soit simplement codé en dur. C'est pourquoi les référentiels existent. Le domaine définit le type de requête dont il a besoin et permet à quelqu'un d'autre de s'occuper de l'implémentation.