PIA Blog / Productivity by Design

Le Domain Driven Design pour quoi faire ?

Le Domaine Driven Design est une méthode de conception développée par Eric Evans. Il en pose les principes dans « Domain-Driven Design: Tackling Complexity in the Heart of Software » publié en 2003. Des extraits de cet ouvrage sont disponibles sous Google Books.

Le DDD a pour but de faciliter la modélisation et l’implémentation de problématiques métier dans une application.

En mettant le domaine métier au centre de l’application, il nous aide à concevoir des applications répondant mieux aux besoins et surtout plus maintenables et évolutives. Pour cela, il propose un ensemble de pratiques de conception et de développement en insistant sur l’importance de la communication et de la collaboration entre experts techniques et experts métier.

Comment nous mettons en pratique le DDD

Nous avons mis en œuvre le DDD dans le cadre de projets agiles (Scrum). Les acteurs en présence sont donc :

• Le client : Il a une problématique métier qu’il souhaite résoudre par la réalisation d’une application informatique. Derrière le terme de client, on retrouve un chef de projet MOA et souvent des représentants des utilisateurs.
• Le Product Owner (P.O.) : Membre de l’équipe projet PIA, il est en contact avec le client et l’aide à formaliser son besoin. Il est notre champion fonctionnel, présent aux côtés de l’équipe technique pour répondre à ses questions. Il est fréquemment assisté d’un ergonome et d’un designer.
• L’équipe technique : Elle est composée d’architectes techniques et de développeurs. Elle va devoir s’approprier le métier pour le restituer au sein de l’application.

Recueil du besoin et apprentissage du domaine

Dans un premier temps notre P.O. rencontre le client et l’aide à exprimer ses besoins par le biais de cas d’utilisation (use case). Avec la première version des cas d’utilisation, les concepts métier vont commencer à émerger ainsi que les relations mises en œuvre. Pour en savoir plus sur les cas d’utilisation, vous pouvez consulter le site d’Alistair Cockburn (le créateur des cas d’utilisation).

Les concepts, la complexité ainsi que la mécanique du métier doivent se retrouver dans l’application. Cela est fait par l’intermédiaire du modèle du domaine. Ce modèle sera l’un des supports de communication, pendant la conception et pendant les développements entre l’équipe technique et les experts métier. L’expression de ce modèle peut dans un premier temps se faire par le biais de cartes CRC ou de diagrammes UML, l’important est de pouvoir le partager.

Une erreur souvent commise, est de vouloir faire un modèle exhaustif qui prend en compte toutes les problématiques du domaine. Notre modèle doit être restreint au problème que l’on souhaite résoudre. Il y a toujours plusieurs modèles pour un domaine. Il est important de définir et de délimiter le contexte dans lequel on souhaite l’exprimer. Ce contexte est bien entendu lié à la problématique à résoudre.

Eric Evans prend l’exemple d’une ancienne carte du monde chinoise. La Chine y est représentée au centre, le reste du monde n’y est pas très détaillé, les distances non respectées… même si elle représente le monde, cette carte n’est qu’une représentation mettant en avant une réalité. Quelque soit la réalité du domaine, sa modélisation n’est qu’une projection qui apporte nécessairement une déformation liée à la nature du problème à résoudre.

L’avantage des cas d’utilisation est de rester concentré sur la problématique client. Les concepts domaine qui vont émerger sont alors exclusivement liés au contexte de notre application.

Sur la base des cas d’utilisation et des concepts du domaine identifiés, le P.O et l’équipe technique pourront établir une première version du modèle. Il faut construire le modèle en gardant à l’esprit les problématiques de l’architecture logicielle. Il est donc important que les développeurs participent à son élaboration, cela permet d’identifier en amont les problèmes et il est alors plus facile d’y remédier.

La mise au point du modèle de domaine est itérative. Au fur et à mesure de l’avancement des développements, des questions vont être soulevées par les développeurs. Les réponses du P.O. et/ ou des représentants des utilisateurs vont permettre de compléter et d’affiner le modèle.

Un langage partagé

Un des fondements du Domain Driven Design est d’utiliser un langage partagé à la fois par les experts du technique et ceux du métier. Le modèle du domaine étant issu de leur collaboration, le langage qui y est employé est idéal.

Il faut que l’équipe utilise ce langage dans tous les échanges, et aussi dans le code. Il faut s’assurer qu’il est présent dans toutes les formes de communication (spécifications, diagramme, discussion, code …), on parle alors d’un langage omniprésent (ubiquitous language).

La définition du langage n’est pas une chose facile et va se faire tout au long de la conception et de la réalisation de l’application. Il faut trouver les concepts clés qui définissent le domaine et la conception, trouver les mots justes et utilisés par le métier.

Prenons l’exemple d’un projet de suivi des indicateurs de performance clés (K.P.I), réalisé pour un grand institut d’étude marketing. L’application permet la récupération d’informations servant à connaître l’évolution de l’activité des différents sites du groupe à travers le monde. L’un des indicateurs clés qui a été le plus rapidement identifié est le nombre d’interviews réalisées. L’application permet donc à chaque responsable de pays de saisir ce nombre chaque mois. Nous avons donc implémenté ces concepts dans le code de l’application sous la forme d’objets « Collect » et « Interview ». Lors de notre première démonstration de l’application au client, nous nous sommes rendus compte que contrairement à nous, il n’employait pas ces termes. Il utilisait « Harvest » en lieu et place de Collect ; et surtout « Complete » qui fait bien mieux apparaître le fait que l’interview a été intégralement complétée. Ces deux concepts étant essentiels et structurant, nous avons donc choisi de refactorer le code de sorte à les reprendre tels quels dans l’application. Lors de la démonstration suivante, nous parlions tous de « Complete ». Le métier avait été assimilé par l’équipe !

S’il y a des choses que les experts métier ne comprennent pas dans le modèle ou le langage, il y a de fortes chances que quelque chose soit mal modélisé et ne corresponde pas à la réalité métier.

Au final, le modèle et le langage sont fortement liés. Un changement dans le langage doit devenir un changement dans le modèle et donc dans le code. Ceux qui écrivent le code doivent connaître parfaitement le modèle et sa logique. Ils sont les garants de son intégrité.

Organisation de l’application

L’utilisation du DDD implique la mise en place de certains patterns ayant pour but de mettre le modèle au cœur de l’application.

L’avantage de cette organisation est d’isoler la logique métier du code dit « technique » et « applicatif ». Cela permet d’éviter le syndrome du modèle anémique (ce qui se produit lorsque nos objets du modèle ne sont qu’une succession de propriété sans comportement). De cette façon, le code est plus compréhensible, plus maintenable et le métier est plus facilement testable.

Nous allons ici voir un aperçu de ces patterns, nous rentrerons dans le détail au cours d’un prochain article.

L’architecture en couches

Interface utilisateur (couche de présentation) : Responsable de la présentation de l’information et de l’interprétation des commandes de l’utilisateur.

Couche application : Elle ne contient pas de logique métier. C’est un peu le chef d’orchestre de l’application. Elle sait quand et comment solliciter les autres couches pour répondre aux commandes des utilisateurs.

Couche domaine : C’est le cœur de l’application. Elle contient le modèle du domaine et donc la connaissance du métier.

Couche infrastructure : Tout ce qui technique et bas niveau se retrouve ici, comme la persistance objet, les processus de sécurisation de l’application, l’encapsulation de l’utilisation d’un serveur smtp pour l’envoi de mail…

L’organisation en couches doit permettre aux objets du domaine de se concentrer sur l’expression du modèle, loin des considérations techniques tels que le stockage, l’affichage… Cela permet au modèle d’évoluer jusqu’à être suffisamment riche et suffisamment clair pour capturer la connaissance essentielle du métier.

Les Patterns

Les Entités (Entity) : Sont des objets qui possèdent une identité invariante. Par exemple, dans le cas de l’Assurance vie, un contrat est identifié par une référence qui ne change pas et qui est unique tout au long de la vie de l’objet. Donc, implémenter des entités revient à créer de l’identité.

Les Objets valeur (Value Object) : A l’inverse des entités, ces objets n’ont pas d’identité propre. Ce qui est important, c’est la « valeur » qu’ils représentent. Prenons l’exemple d’un souscripteur de contrat d’assurance. Il possède une adresse postale composée d’une rue, d’un numéro, d’un code postal, d’une localité. Cette adresse peut être représentée par un Value Object. Ce qui nous intéresse n’est pas de savoir de quel objet il s’agit, mais quelle valeur il représente. Les attributs choisis pour constituer un Value Object forment un tout conceptuel.

Les Services : Les services sont présents dans les 3 couches (applicative, domaine et infrastructure). Ils sont utilisés lorsque des comportements du domaine ne sont pas directement liés à une Entité ou à un Value Object. Le service n’a pas d’état et son interface fait référence au langage du modèle.

Les Agrégats (Aggregate): Il arrive fréquemment que des objets soient liés entre eux par une relation logique. Prenons les objets suivants, la « facture » et les « lignes de facturation ». Le second n’a aucune raison d’être sans le premier. Dans ce cas, la facture et la ligne de facturation forment un agrégat dont la racine est la facture. L’agrégat contient aussi bien des entités que des value objects.  La racine doit être une Entité, et c’est le seul objet accessible de l’extérieur. Si les objets d’un Agrégat sont stockés en base de données, seule la racine doit pouvoir être obtenue par un entrepôt.

Les Fabriques (Factory) : C’est un pattern connu, utilisé pour la création d’objets complexes. Il est important pour la construction d’agrégats qui sont parfois trop complexes pour être créés dans le constructeur de l’entité racine. Les Fabriques sont utilisées pour encapsuler la connaissance nécessaire à la création des objets.

Les Entrepôts (Repository) : Les entrepôts servent à stocker et à récupérer les entités. Ce pattern se rapproche de celui plus connu du DAO.  Le but est d’encapsuler toute la logique nécessaire à l’obtention de références d’objets.

Ce que le Domain Driven Design nous a apporté

Sur le sujet du recueil du besoin et de sa compréhension, PIA avait déjà des pratiques avancées sur le sujet (réalisation de use cases avec le client, interview d’utilisateurs, mockups, story board hifi…). De même, nous avons toujours fait en sorte d’utiliser un langage partagé avec le client, et plus précisément le langage du métier. Nos pratiques se sont très bien intégrées avec le DDD qui insiste sur la forte collaboration entre experts techniques et experts métier.  Le DDD nous a amené un nouveau support de communication : le modèle du domaine.

Le DDD n’impose ni formalisme ni méthode pour acquérir la connaissance métier, il insiste simplement sur l’importance d’une communication continue entre technique et métier tout au long du projet.

Sur l’architecture de l’application, l’isolation du domaine au sein d’une couche rend le code plus maintenable et évolutif. Ceci ajouté à la forte présence du langage métier dans le code, permet d’obtenir un code plus lisible, décrivant de manière claire le domaine. Une personne ne connaissant pas l’application est capable assez rapidement de comprendre le métier et le problème adressé simplement en lisant le code.

Dernier point important, l’isolation du code métier facilite l’écriture des tests unitaires et se marie donc très bien avec la pratique du Test Driven Development (TDD).

En conclusion, le DDD est une approche de conception qui pose un cadre mais n’impose rien. Cela a facilité son appropriation par nos équipes. Le DDD permet également de répondre en partie à un éternel problème dans le domaine informatique : qu’est-ce qu’une bonne conception ? C’est avant tout une conception qui reflète le métier et qui le place au centre de l’application.

Pour aller plus loin

• Le livre d’Eric Evans, Domain-driven design: tackling complexity in the heart of software
• Site officiel sur le Domain Driven Design
• Un exemple de code issu du livre d’Eric Evans, le cargo
• DDD yahou Group
• DDD Vite Fait, traduction du DDD quickly d’InfoQ
• Article d’InfoQ – DDD in practice