Blog Arolla

Domain Driven Design en 5 minutes

Qu’est-ce que cela signifie ?

À la différence des approches xDD,  test-driven-design (TDD) et behaviour-driven-design (BDD), qui fournissent un cadre pour l’implémentation du bon comportement du logiciel, le DDD s’intéresse au design du logiciel. Une traduction possible est « conception guidée par le domaine ». Par « domaine », il faut entendre « métier» et par « conception guidée », « un état d’esprit à adopter» plutôt qu’une liste de patrons de conception à appliquer. Vous avez sûrement déjà observé dans une équipe de développement une séparation nette des métiers : le fonctionnel est le maître du domaine, l’architecte est l’expert de la conception globale et le développeur l’expert de la technique. Chacun parle du logiciel dans sa langue et le voit avec le biais de son domaine. Dans ce contexte, s’il est largement admis que les développeurs sont les experts du code, il est parfois difficile de faire accepter l’idée que le domaine métier les concerne aussi. Pourtant, ce code qui part en production et constitue le logiciel, est le reflet de ce que les développeurs ont compris du métier. La mauvaise qualité des échanges entre les protagonistes du projet est donc bien un risque pour le logiciel. Un autre fait très souvent observé, est la volonté de cadrer la conception du logiciel très en amont du projet. Si cela peut servir à se projeter sur le produit à concevoir, cela se révèle souvent à terme peu efficace à servir les besoins des utilisateurs, dont l’avis n’est sollicité que lorsque des livrables ont été fournis.  Pourtant, il serait intéressant de s’appuyer de façon continue sur les acteurs du cœur de métier pour définir le logiciel. En écho à ces observations, l’approche DDD est définie par les trois points suivants :

  • Une attention particulière portée sur le langage avec pour objectif l’émergence d’un vocabulaire commun aux fonctionnels et aux techniques
  • Une connexion très forte entre modèle et implémentation qui se construit au fil des propositions successives élaborées à partir des échanges entre experts métier et experts techniques,  sans plan de conception en amont
  • Une focalisation sur le cœur de métier, autrement dit, ce qui fait la particularité et la compétitivité d’une entreprise face à ses concurrents, cette activité stratégique où elle est meilleure que les autres.

 

Comment comprendre le métier quand on est développeur-se ?

Voici quelques approches possibles pour y parvenir :

  • Se renseigner sur le domaine. Lire des documents (articles, présentations de produits,…), regarder des vidéos internes ou externes à la société cliente. La limite de cette approche est qu’il faut pour cela disposer de sources et être capable de les interpréter.
  • Questionner directement un expert métier. Bien qu’il détienne beaucoup de réponses, parler de façon limpide de son domaine à un non-initié ne coule pas de source. De plus, il peut n’avoir que peu de disponibilités. Le développeur devra donc minutieusement préparer son interview. Il peut par exemple, orienter rapidement les réponses vers ses points d’intérêts, avec des questions-types telles que : « Est-ce-que c’est vrai tout le temps ? Donnez-moi des exemples ? Pouvez-vous définir ce terme ? Pouvez-vous me rappeler ce terme ?  ».
  • Observer un expert métier. Vous pouvez proposer à un fonctionnel, futur utilisateur, de rester à côté de lui pendant qu’il fait son travail, en échangeant parfois sur ce qu’il est en train de faire. Passé les (possibles) moments de gêne du début, l’observation peut permettre d’avoir une idée du domaine et des exemples qui ne sont pas toujours formulés explicitement.
  • Analyser un logiciel du domaine existant. Lorsqu’aucun expert n’est disponible, une lecture du code existant peut amener une première découverte du domaine, et des questions à poser à l’expert. Mais il faut néanmoins garder à l’esprit que le code parcouru peut être trompeur et ne pas représenter fidèlement le domaine.

Comment modéliser le domaine du métier ?

Une fois que les développeurs ont suffisamment ingéré d’information, il est temps d’en extraire un modèle. Eric Evans (Domain-Driven Design: Tackling Complexity in the Heart of Software ) parle de knowledge crunching ou de distillation : prendre un problème dans tous les sens tout en demandant du feedback métier. La construction d’un modèle demande des essais, des erreurs, des observations et des mises à jour. Un modèle est une représentation du monde mais il ne contient pas tout l’univers, il se contente de ce qui est jugé pertinent, c’est-à-dire utile à la résolution des problèmes. De la donnée peut être supprimée. Il ne doit pas contenir de bruit parasite gênant la réflexion. Il doit être prédictif sans être fidèle à la vérité. Le lexique du projet est borné lui aussi : un mot n’a de signification donnée que dans un contexte donné (zone linguistique). Dans une même entreprise, le service marketing, le service comptabilité et le service livraison n’ont pas le même point de vue sur le client. Dans le contexte marketing, un client est un profil alimenté par ses fréquences de visite ou son type d’achats, dans le contexte du service comptabilité, c’est un compte en banque, et pour un service de livraison, c’est une adresse postale. Le modèle, le code et le lexique du projet sont étroitement liés. Le code contient le vocabulaire des conversations. Tout changement dans le code est un changement dans le modèle, qui doit se retrouver aussi dans les conversations et vice versa. Ainsi en évitant le besoin de traduction entre le code et le domaine, la complexité du logiciel se trouve réduite. En DDD, on appelle ce vocabulaire commun l’«ubiquitous language».

Comment implémenter le modèle ?

Pour implémenter au mieux le modèle, il faudrait adopter à la fois une approche strategic design (conception stratégique) et une approche tactical design (conception tactique)  Le strategic design ambitionne de se connecter à la stratégie d’entreprise dans le but d’améliorer sa compétitivité et de favoriser l’innovation. Parmi les patrons de conception qui servent ce but, on trouve :

  • Bounded context : un ensemble cohérent de concepts décrivant un domaine formant un lexique sans ambiguïtés
  • Context mapping : un outil pour faire émerger des bounded contexts et identifier les relations entre eux à partir des connaissances du métier.

Il fait émerger une meilleure compréhension du métier. Il faut commencer par cette étape afin de partir dans la bonne direction. Le tactical design vise à construire son modèle à l’aide de patrons de modélisation dont les plus communs sont :

  • value-object : un concept immuable, sans cycle de vie tel que la valeur d’ « un billet de 5 euros » toujours identique quel que soit le billet et sans identité propre.
  • entity : un concept qui a un état, un cycle de vie et une identité, mutable tel que le numéro de billet d’un billet de 5 euros différent d’un billet à un autre.
  • aggregate : ensemble indissociable d’entity et/ou de value object, évoluant ensemble. Il est mis à jour par le biais d’un l’élément racine dans une même transaction et demeure ainsi toujours cohérent.
  • factory : pour créer de nouveaux agrégats de la manière appropriée
  • event : pour notifier les composants d’un programme de la survenue d’un événement. Par exemple : tracer les évolutions de l’état d’un objet pour le sauvegarder dans un log d’événements. (cf. event sourcing)

C’est une approche incrémentale qui fait émerger le bon design après plusieurs expérimentations. Certaines architectures sont particulièrement associées au DDD telles que :

  • L’architecture hexagonale : découpage en une couche intérieure contenant la représentation du métier, épuré de tout détail technique,  et une couche extérieure fournissant des adaptateurs pour les interactions avec la couche intérieure. Les contraintes du domaine et de l’infrastructure technique (système de stockage…) sont ainsi complètement dissociées.
  • Les micro-services: découpage d’une application en services, chaque service ayant son propre modèle, son propre stockage, sa propre technologie et représentant un domaine métier.
  • Command-Query Responsibility Segregation CQRS : découpage entre les composants chargé de l’écriture (commandes) et de la lecture (requêtes) des données. Le modèle optimal pour la lecture et celui pour l’écriture peuvent ainsi diverger.

Dans quels cas avoir recours au DDD ?

La connaissance métier  contenue dans le code, autrement dit  le métier compréhensible à la lecture du code est un atout pour le logiciel. Cela limite la perte de connaissance dûe au départ d’un développeur et accélère la montée en compétence lors d’une arrivée par exemple. C’est aussi un moyen de s’assurer de la bonne adéquation entre la demande et le produit livré. DDD apporte un bon axe pour atteindre cet objectif. Il peut être mis en place aux côtés du TDD, qui  fait apparaître les règles métier dans les tests, et du BDD, qui challenge le métier. Cependant, il est particulièrement intéressant d’y avoir recours quand il y a une problématique métier sans risque technique, comme dans les cas suivants :

  • Risque dans le domaine : c’est le cas par exemple d’une banque face à la détection de fraude.
  • Valeur ajoutée dans le domaine : c’est la situation d’une entreprise innovante qui cherche à se différencier de ces concurrents

Pour aller plus loin

 

2 comments for “Domain Driven Design en 5 minutes

  1. 15 février 2020 at 9 h 04 min

    Nice work

  2. 17 février 2020 at 23 h 57 min

    goood

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *