La conception basée sur le métier ou le domain-driven design (DDD) est une façon de développer une application en lien avec le métier. Elle regroupe plusieurs concepts, notamment l’ubiquitous language, un terme définissant la construction d’un langage commun entre les développeurs et le métier (les utilisateurs), ainsi que le modèle de domaine (équivalent à un diagramme de classe UML), qui représente des aspects sur les données et les règles métiers d’un domaine de connaissance.
Pour mettre en pratique le DDD dans un système logiciel, on utilisera une conception basée sur un modèle ou model-driven design en anglais. Il est important que le code de l’application soit le reflet d’un modèle, contrairement à une analyse qui ne va pas modeler la future application. Le meilleur modèle d’Eric Evans, créateur du DDD, est celui-ci :
Principalement pour le DDD, il faut isoler le domaine dans une architecture en couche, et exprimer le modèle avec ces trois termes : services, entities et value objects. La couche domaine est responsable de la logique métier (informations et règles), elle inclut les entities et value objects. Très légers, les services représentent les tâches de l’application, et sont dans une couche à part pour déléguer tout le travail aux différentes couches inférieures. Ils n’ont aucunes règles métiers. La proposition d’architecture en couche d’Eric Evans :
Un système en couche donne accès aux couches du dessous à celles qui sont au-dessus. Équivalent à la couche présentation, l’User interface correspond à l’affichage des informations et à la récupération des actions de l’utilisateur. La couche Application regroupe les services (coordonne les tâches des couches inférieures). L’Infrastructure fournie des techniques génériques pour supporter les couches supérieures, comme envoyer un mail, dessiner un objet d’interface graphique, persister le domaine.
Les entités ou entities en anglais sont des objets définis par une identité. Par exemple, dans un virement bancaire, il y a un montant, un compte débiteur et bénéficiaire, mais aussi une référence unique pour l’identifier. C’est alors une entité. La plupart des tables dans une base de données peuvent être des entités, car elles sont identifiables par une clé unique.
Les objets de valeurs ou value objects sont des objets qui représentent un aspect du domaine, mais sans identité. Pour reprendre l’exemple d’un virement bancaire, il y a le choix entre trois types de virement : classique, différé, ou récurrent. C’est une information essentielle et caractéristique d’un virement bancaire. Il devrait être un objet de valeur, et non être dans une entité. En Java, ça pourrait être une interface avec trois implémentations différentes. Dans une base de données, il faut distinguer les champs qui appartiennent à l’entité ou à un objet de valeur.
Les règles métiers sont rangées dans les entités ou les objets de valeurs. Elles sont facilement trouvables et compréhensibles dans le code de l’application. Le DDD est très évolutif et plus facilement maintenable, si l’application est toujours actualisée par rapport au modèle. Plus long à mettre en place que d’autre conception, son atout principal est de résoudre beaucoup de problèmes dans un métier complexe.
