Qu'est-ce que la conception par domaine (DDD)?
Je continue de voir que DDD (Domain Driven Design) est beaucoup utilisé dans les articles - j'ai lu l'entrée de Wikipédia sur DDD, mais je ne peux toujours pas comprendre ce que c'est réellement et comment je procéderais pour l'implémenter dans la création de mes sites?
Premièrement, si vous ne savez pas que vous en avez besoin, il est possible que vous n'en ayez pas besoin. Si vous ne reconnaissez pas les problèmes que DDD résout, vous n’avez peut-être pas ces problèmes. Même les défenseurs de DDD souligneront fréquemment que DDD est uniquement destiné aux grands projets (> 6 mois).
En supposant que vous lisiez encore à ce stade, voici mon point de vue sur DDD:
DDD consiste à essayer de faire de votre logiciel un modèle de système ou de processus réel. En utilisant DDD, vous êtes censé travailler en étroite collaboration avec un expert de domaine qui peut expliquer le fonctionnement du système réel. Par exemple, si vous développez un système permettant de placer des paris sur des courses de chevaux, votre expert en domaines peut être un bookmaker expérimenté.
Entre vous et l'expert du domaine, vous construisez un langage omniprésent (UL), qui est essentiellement une description conceptuelle du système. L'idée est que vous devriez être capable d'écrire ce que le système fait de manière à ce que l'expert du domaine puisse le lire et vérifier qu'il est correct. Dans notre exemple de pari, le langage omniprésent inclurait la définition de mots tels que "race", "pari", "cote", etc.
Les concepts décrits par l'UL constitueront la base de votre conception orientée objet. DDD fournit des indications claires sur la manière dont vos objets doivent interagir et vous aide à les diviser dans les catégories suivantes:
- Les objets de valeur, qui représentent une valeur pouvant comporter des sous-parties (par exemple, une date peut avoir un jour, un mois et une année)
- Entités, qui sont des objets avec identité . Par exemple, chaque objet Client a sa propre identité. Nous savons donc que deux clients du même nom ne sont pas le même client.
- Les racines agrégées sont des objets qui possèdent d'autres objets. Ceci est un concept complexe et fonctionne sur la base qu'il existe certains objets qui n'ont de sens que s'ils ont un propriétaire. Par exemple, un objet "Ligne de commande" n'a pas de sens sans l'appartenance à "Ordre". Nous disons donc que l'ordre est la racine de l'agrégat et que les objets Ligne de commande ne peuvent être manipulés que via des méthodes de l'objet Ordre.
DDD recommande également plusieurs modèles:
- Repository , un modèle de persistance (sauvegarde et chargement de vos données, généralement depuis/vers une base de données)
- Factory , un motif pour la création d'objet
- Service, un modèle pour créer des objets qui manipulent vos objets de domaine principaux sans faire partie du domaine eux-mêmes
À ce stade, je dois dire que si vous n’avez jamais entendu parler de ces choses auparavant, vous ne devriez pas essayer d’utiliser DDD pour les projets pour lesquels vous avez une échéance. Avant d’essayer de DDD, vous devez vous familiariser avec modèles de conception et modèles de conception d’entreprise . Sachant cela, DDD est beaucoup plus facile à comprendre. Et, comme mentionné ci-dessus, il existe une introduction gratuite à DDD disponible auprès d’InfoQ (où vous pouvez également trouver des conférences sur DDD).
Prenons StackOverflow comme exemple. Au lieu de commencer à concevoir des formulaires Web, vous vous concentrez d'abord sur la modélisation orientée objet des entités de votre domaine de problèmes, par exemple Utilisateurs, Questions, Réponses, Votes, Commentaires, etc. La conception étant guidée par les détails du problème domaine il est appelé conception axée sur le domaine .
Vous pouvez en lire plus dans livre d'Eric Evans .