Domain Driven Design

La conception pilotée par le domaine métier

Vous avez un projet ? Nous avons le savoir-faire.

Rejoignez notre communauté et venez assister aux Apér'Ops

Le rendez-vous mensuel des Elosiens

Domain Driven Design (en 5min)

Définition

La conception pilotée par le domaine (i.e. Domain-Driven Design ou DDD) est une approche de conception logicielle définie par Eric Evans qui vise à accorder de l’importance au domaine métier.En effet, dans la plupart des logiciels, la logique métier qui est implémentée est ce qui constitue la plus grande valeur ajoutée puisque c’est cette logique qui rend le logiciel fonctionnel.

Pourtant très souvent une grande part des développements se concentrent sur d’autres parties comme l’interface graphique, à la persistance des données ou au partage d’informations avec des systèmes externes.

DDD n’est pas une méthode pour concevoir des logiciels mais juste une approche qui permet d’indiquer comment concevoir un logiciel en prenant davantage en compte le domaine métier.

L’intérêt de DDD est:

Permettre à l’équipe de créer un modèle et de le communiquer aux experts métier mais aussi à d’autres acteurs de l’entreprise avec les spécifications fonctionnelles, les entités du modèle de données et la modélisation de processus.
Le modèle est modulaire et plus facile à maintenir.
Il améliore la testabilité et la généricité des objets du domaine métier.

L’approche DDD vise, dans un premier temps, à isoler un domaine métier. Un domaine métier riche comporte les caractéristiques suivantes:

Il approfondit les règles métier spécifiques et il est en accord avec le modèle d’entreprise, avec la stratégie et les processus métier.
Il doit être isolé des autres domaines métier et des autres couches de l’architecture de l’application.
Le modèle doit être construit avec un couplage faible avec les autres couches de l’application
Il doit être une couche abstraite et assez séparée pour être facilement maintenue, testée et versionnée.
Le modèle doit être concu avec le moins de dépendances possibles avec une technologie ou un framework. Il devrait être constitué par des objets POCO (Plain Old C# Object). Les POCO sont des objets métier disposant de données, de logique de validation et de logiques métier. Il ne doit pas comporter de logique de persistance.
Le domaine métier ne doit pas comporter de détails d’implémentation de la persistance.

Comprendre le domaine et le communiquer

Le domaine est connu par les spécialistes du domaine qui sont des experts. Il faut donc rencontrer ces experts pour comprendre toutes les subtilités du domaine. A terme, le logiciel implémenté modélisera le domaine. Toutefois avant que le logiciel ne devienne le reflet du domaine, il faut le comprendre.

Cette compréhension permettra, dans un premier temps, de modéliser le domaine (c’est-à-dire extraire le modèle). Il n’y a pas de méthode pour modéliser le domaine mais on peut s’aider de dessins, diagrammes, simplement un texte écrit etc… Le plus important est de comprendre le domaine pour le communiquer.

La communication du modèle passe par des entrevues entre experts du domaine, concepteurs logiciels et développeurs.

Ubiquitous language

Un frein à la communication du modèle pourrait être l’utilisation d’un langage spécialisé ou technique de la part des experts ou des développeurs. Ce langage spécialisé tend à rendre la compréhension du domaine compliqué pour chacun des acteurs. Il est donc important de se mettre d’accord sur un vocabulaire commun et compréhensible de tous dont le but ultime est un domaine compréhensible et exploitable.

Ce vocabulaire commun est l’ubiquitous language (i.e. “langage omniprésent”), il permet de:

Trouver les concepts clés qui définissent le domaine et ensuite la conception
Révéler les expressions utilisées dans le domaine
Chercher à résoudre les ambiguités et inconnues

L’ubiquitous language ne s’élabore pas en une seule itération, il est le fruit de plusieurs discutions avec les experts du domaine.

Pour l’élaborer, il faut:

Eviter d’utiliser des termes que les experts n’ont pas prononcés.
Créer un glossaire contenant les termes utilisés par les experts du domaine de façon à les expliquer.
Vérifier qu’un terme est utilisé pour un seul concept.
Eviter d’utiliser des termes trop proches de solutions techniques ou de “design patterns”. Ces termes peuvent diriger les développeurs vers une solution particulière et ils peuvent être incompréhensible par les experts du domaine.
Les termes de l’ubiquitous language doivent se retrouver dans le code pour qualifier des propriétés, des comportements qui implémentent une partie du domaine et surtout les tests. Si l’ubiquitous language est compris, le code sera plus clair.
Les évolutions de l’ubiquitous language peuvent se traduire par des modifications des noms ou comportements utilisés dans le code.
Il n’est pas nécessaire d’élaborer un ubiquitous language pour toute l’application. Il est préférable de réserver cette démarche aux parties complexes du domaine.

Extraire les domain models à partir du domaine

Le domain model (i.e. modèle du domaine) est une version simplifiée et implémentable du domaine. Le domain model ne contient que la partie du domaine pour laquelle le logiciel doit apporté une solution. Le domain model sera utile s’il représente efficacement la logique complexe du domaine pour permettre la résolution du problème tout en étant compréhensible des experts du domaine.

Dans une approche idéale, et dans une première version, le domain model ne doit pas trop prendre en compte la solution technique mise en œuvre pour l’implémentation. Toutefois, lors des phases suivantes de traduction du domain model, l’équipe de développement va probablement lever des incohérences, des ambiguités ou des points techniques bloquants qui vont remettre en cause le domain model. Après des entrevues avec les experts du domaine, des refactorings successifs permettront d’aboutir à un domain model implémentable tout en étant fidèle au domain dont il est censé être la réduction.

Ainsi, l’approche DDD insiste sur 3 points qui sont essentiels à la bonne marche d’un projet:

La connaissance du domaine.
L’ubiquitous language.
La collaboration entre les développeurs et les experts du domaine.

La représentation du domain model peut se faire en utilisant UML.

Plus le domaine est complexe et plus le domain model devra résoudre des problèmes complexes. Dans la pratique, pour un domaine complexe, il faut pas utiliser qu’un seul mais plusieurs domain models qui adresseront chacun un problème différent.

Analysis Model

Le domain model permet d’élaborer le modèle d’analyse (i.e. “analysis model”) qui va aider les développeurs à comprendre les problèmes du domaine.

Code Model

Le modèle du code (i.e. “code model”) est une version du domaine utilisée pour l’implémentation. Il est différent du domain model puisqu’il n’est compréhensible que par les développeurs. Il est le lien entre le domain model qui est loin des considérations d’implémentation et le code.

Lors de la traduction du domain model en code:

Ce sont les développeurs qui effectuent la traduction du modèle en code.

Des défauts peuvent apparaître dans l’implémentation, ces défauts doiven faire l’objet de “refactorings”.

Plus le code est lié au domain model et à l’ubiquitous language et plus les développeurs comprendront facilement le modèle.

Les développeurs doivent faire des feedbacks pouvant mener, éventuellement, à des “refactorings”.

Il faut éviter des trop grandes différences entre le code et le domain model sinon le modèle pourrait ne plus être compréhensible en cas de “refactoring” par les autres acteurs que les développeurs.

Model Driven Design

La conception dirigée par le modèle (i.e. “Model Driven Design”) permet d’assurer le lien entre le modèle d’analyse et le modèle de code. Cette approche se focalise davantage sur l’implémentation par rapport à l’approche DDD qui plus des indications sur l’élaboration de l’ubiquitous language, de la collaboration avec les experts du domaine et la connaissance partagée du domaine.

La conception dirigée par le modèle permet à la connaissance du domaine et de l’ubiquitous language d’être incorporés dans le modèle de code. Il devient alors, une interprétation du langage et du modèle mental des experts du domaine.

L’approche de la conception dirigée par le modèle ne convient pas dans tous les cas

Des problèmes simples ne nécessitent pas forcément l’approche plus complexe de la conception dirigée par le modèle.

Il n’est pas nécessaire de concevoir toute l’application en utilisant la conception dirigée par le modèle.

Cette approche convient davantage pour résoudre les problèmes du domaine les plus complexes.

Patterns permettant d'implémenter un domain model

Quelques patterns peuvent convenir pour implémenter un domain model:

Domain Model: pattern définit par Martin Fowler dans Patterns of Entreprise Application Architecture. Il permet de concevoir un modèle en utilisant la conception dirigée par le modèle en opposition à la conception dirigée par la base de données. En utilisant ce pattern, la persistence des données vient après la conception des objets du domaine. Les objets du domaine sont de type POCO (Plain Old C# Objects). DDD permet d’étoffer ce pattern en préconisant des objets ou des blocs d’objets particuliers. Ce pattern impose que les objets du domaine soient décorélés de l’infrastructure technique avec une architecture en couches.

Transaction Script: ce pattern est beaucoup plus simple que domain model. Il envisage de tout mettre dans un seul objet : workflow métier, règles métier, règles de validation et persistence en base de données. L’accès à l’implémentation de l’objet se fait de façon procédurale. Ce pattern convient pour les cas très simples où la logique métier est très faible. Toutefois il n’apporte pas de solutions génériques pour certaines problématiques techniques comme les accès concurrents, les problèmes de cohérence entre objets ou la logique de persistence. C’est la raison pour laquelle il doit s’appliquer seulement dans le cas où la logique métier est appliquée de façon procédurale.

Table Module: un objet du modèle correspond à un objet en base de données comme une vue ou une table. Chaque objet est responsable de sa persistence en base. Ce pattern ne convient pas forcèment bien dans une approche DDD mais il peut s’avérer facile à implémenter dans le cas simple où un objet métier est très lié à la base de données.

Active Record: un object du modèle correspond à une ligne dans un objet en base de données. Ce pattern convient s’il y a un mapping un à un entre le modèle de données et le modèle métier. Chaque objet est responsable de sa persistence en base.

Anemic Domain Model: ce pattern correspond au cas où l’objet du modèle ne possède aucune logique, il ne contient que des propriétés. Toute la logique de gestion de ces objets (comme la persistence par exemple) se trouve à l’extérieur de l’objet, dans la couche de service. Même si un domain model implémenté suivant Anemic Domain Model n’est que conteneur sans logique métier, il peut incorporer des éléments de l’ubiquitous language par la seule présence de propriétés.

Objets ou bloc d'objets préconisés

Entité

Les objets entités contiennent une identité:

L’identité est identique durant tous les états du logiciel
La référence à l’objet est de préférence unique pour assure une certaine cohérence.
Il ne devrait pas exister 2 entités avec la même identité sous peine d’avoir un logiciel dans un état incohérent.
L’identité peut être un identifiant unique ou une combinaison de plusieurs membres de l’entité.

Value-Object

Ce sont des objets n’ayant pas d’identité:

Les value-objects n’ont pas d’identité car ils sont utilisés principalement pour les valeurs de leurs membres.
Ces objets peuvent facilement créés ou supprimés car il n’y a pas de nécessité de maintenir une identité.
L’absence d’identité permet d’éviter de dégrader les performances durant la création et l’utilisation de ces objets par rapport aux entités.
Les value-objects peuvent être partagés
Dans le cas de partage de value-objects, il faut qu’ils soient immuables c’est-à-dire qu’on ne puisse pas les modifier durant toute leur durée de vie.
Les value-objects peuvent contenir d’autres value-objects.

Service

Lorsqu’on définit l’ubiquitous language, le nom des concept-clés permettent de definir les objets qui seront utilisés. Les verbes utilisés qui sont associés aux noms permettront de définir les comportements de l’objet. Ces comportements seront implémentés directement dans l’objet.

Ainsi, lorsque des comportements ne peuvent être associés à un objet, ils doivent être implémentés en dehors de tout objet, dans un service:

L’opération dans le service fait référence à un concept du domaine qui n’appartient pas à une entité ou à un value-object.
Un service peut effectuer un traitement sur plusieurs entités ou value-objects.
Les opérations n’ont pas d’états.
Les services ne doivent pas casser la séparation en couche, ainsi un service doit être spécifique à une couche.

Module

Permet de regrouper les classes pour assurer une cohésion:

dans les relations entre les objets
dans les fonctionnalités gérées par ces objets.
L’intérêt est d’avoir une vue d’ensemble en regardant les modules, on peut ensuite s’intéresser aux relations entre les modules.

Les modules doivent:

former un ensemble de concepts cohérents, de façon à réduire le couplage entre les modules.
Le couplage faible permet de réduire la complexité et d’avoir des modules sur lesquels on peut réfléchir indépendamment.
Etre capable d’évoluer durant la durée de vie du logiciel.
Etre nommés suivant des termes de l’ubiquitous language.

Aggregate

Les objets du modèle ont une durée de vie:

Ils peuvent être créés, placés en mémoire pour être utilisés puis détruits ensuite.
Ils peuvent aussi être persistés en mémoire ou dans une base de données.

La gestion de cette durée de vie n’est pas facile car:

Les objets peuvent avoir des relations entre eux : 1 à plusieurs, plusieurs à plusieurs.
Il peut exister des contraintes entres les objets au niveau de leur relation : par exemple unidirectionnel ou bidirectionnel.
Il peut être nécessaire de maintenir des invariants c’est-à-dire des règles qui sont maintenues même si les données changent.
Il faut assurer une cohésion du modèle même dans le cas d’association complexe.

Une méthode est d’utiliser un groupe d’objets comme les agrégats (i.e. “aggregate”). Les agrégats sont des groupes d’objets associés qui sont considérés comme un tout unique vis-à-vis des modifications des données, ainsi:

Une frontière sépare l’agrégat du reste des objets du modèle,
Chaque agrégat a une racine qui est une entité qui sera le lien entre les objets à l’intérieur et les objets à l’extérieur de l’agrégat.
Seule la racine possède une référence vers les autres objets de l’agrégat.
L’identité des entités à l’intérieur de l’agrégat doivent être locale et non visible de l’extérieur.
La durée de vie des objets de l’agrégat est liée à celle de la racine.
La gestion des invariants est plus facile car c’est la racine qui le fait.
La racine utilise des références éphémères si elle doit passer des références d’objets internes à des objets externes. L’intégrité de l’agrégat est, ainsi, maintenue.
On peut utiliser des copies des value-objects.

Factory

Les fabriques sont inspirées du “design pattern” pour créer des objets complexes:

Elles permettent d’éviter que toute la logique de création des objets ne se trouve dans l’agrégat.
Permet d’éviter de dupliquer la logique de règles s’appliquant aux relations des objets.
Il est plus facile de déléguer à une fabrique la création d’une agrégat de façon atomique.
La gestion des identités des entités n’est pas forcément triviale car des objets peuvent être créés à partir de rien, ils peuvent aussi avoir déjà existé (il faut être sûr qu’il n’existe pas encore une autre entité avec le même identifiant) ou il peut être nécessaire d’effectuer des traitements pour récupérer les données de l’entité en base de données par exemple.

L’utilisation de fabriques n’est pas indispensables, on peut privilégier un constructeur simple quand:

La construction n’est pas compliquée : pas d’invariants, de contraintes, de relations avec d’autres objets.
La création n’implique pas la création d’autres objets et que toutes les données membres soient passées par le constructeur.
Il n’y a pas de nécessité de choisir parmi plusieurs implémentations concrètes.

Repository

Dans le cas d’utilisation d’agrégats, si un objet externe veut avoir une référence vers un objet à l’intérieur, il doit passer par la racine et ainsi, avoir une référence vers la racine de l’agrégat, ainsi:

Maintenir une liste de références vers des racines d’agrégat peut s’avérer compliqué dans le cas où beaucoup d’objets sont utilisés. Une mise à jour de la référence de la racine auprès de plusieurs objets peut s’avérer couteux.
L’accès à des objets de persistance se fait dans la couche infrastructure, les implémentations permettant d’y accéder peuvent se trouver dans plusieurs objets et ainsi être dupliquées.
Un objet du modèle ne doit contenir que des logiques du modèle et non les logiques permettant d’accéder à une base de persistance.

Utiliser un repository permet:

D’encapsuler la logique permettant d’obtenir des références d’objets.
Stocker des objets
D’utiliser une stratégie particulière à appliquer pour accéder à un objet.

L’implémentation d’un repository peut se faire dans la couche infrastructure toutefois l’interface de ce repository fait partie du modèle.

Le repository et la fabrique permettent, tout deux, de gérer le cycle de vie des objets du domaine:

La fabrique permet de créer les objets
Le repository se charge de gérer des objets déjà existants.

Architectures en couche

DDD préconise de séparer le code en couche pour ne pas diluer la logique métier dans plusieurs endroits. Chaque couche a une fonction particulière qui est utilisable par d’autres couches de façon à:

Mutualiser le code suivant une logique
Éviter la duplication de code métier

Les 4 couches sont:

la couche utilisateur,
la couche application,
la couche domaine,
la couche infrastructure

Couche Utilisateur

Elle présente l’information à l’utilisateur et réceptionne ses commandes. Cette couche peut faire appel à toutes les autres.

Couche Application

La couche application (i.e. “application service layer”) sépare la couche utilisateur de la couche domaine:

Elle ne contient pas de code métier mais peut être amenée à contenir du code permettant de gérer des changements dans la couche utilisateur.
Elle ne doit pas garder l’état des objets métier mais peut stocker l’état d’avancement d’une tâche de l’application.
Elle permet d’effectuer la navigation entre les écrans de l’interface graphique et les interactions avec les couches application d’autres systèmes.
Elle peut effectuer des validations basiques (non liées à des règles métier) sur les entrées de l’utilisateur avant de les transmettre aux autres couches de l’application.
Elle ne doit pas contenir de logique métier ni de logique d’accès aux données.
Cette couche peut faire appel à la couche domaine et à la couche infrastructure.

Cette couche peut permettre d’isoler la couche domaine des aspects techniques nécessaires à son fonctionnement. Elle peut contenir les services applicatifs et servir d’intermédiaire entre la couche domaine et les objets qui y font appels. Elle expose les capacités du système en proposant une abstraction à la logique du domaine contenue dans la couche domaine. Elle tends grandement à préserver le domaine en concentrant de nombreux éléments de logique applicative.

Cette couche de services sert aussi d’implémentation concrête à la frontière du contexte borné, elle peut assurer les échanges avec les autres contextes bornés en utilisant, par exemple, des services REST, des web services ou par l’intermédiaire d’un bus de communication.

Couche Domaine

Elle contient les informations sur le domaine et la logique métier:

Elle détient tous les concepts du modèle métier, les cas d’utilisation et les règles métier.

Elle contient l’état des objets métier toutefois elle n’effectue pas directement la persistance des objets métier.

Elle peut aussi contenir l’état d’un cas d’utilisation métier si celui-ci est formé de plusieurs requêtes de l’utilisateur.

Elle peut contenir des objets de service si leur comportement ne peut être implémenté dans un objet métier. Les services contiennent des comportements métier qui ne peuvent pas faire partie d’un objet du modèle.

Cette couche est le coeur du métier, elle doit être isolée des autres couches et ne peut être dépendantes de framework.

Cette couche ne peut faire appel qu’à la couche infrastructure.

Couche Infrastructure

Elle permet de fournir un lien de communication entre toutes les autres couches. D’autre part, elle contient le code de persistance des objets métier. Cette persistance n’est pas forcément dans une base de données.

Les relations entre les couches peuvent être directes toutefois il est préférable que les relations se fassent des couches hautes (par exemple la couche utilisateur) vers les couches basses (couche infrastructure).

Approche SOA

L’approche SOA (pour “Service-Oriented Architecture”) ne dispense pas d’une réflexion sur le modèle métier. On pourrait croire que cette approche permet d’isoler par construction un modèle métier, pourtant dans le cas où on accorde pas assez d’importance à la conception du modèle, une approche SOA entraînera une implémentation avec les mêmes conséquences que pour architecture classique : une couche de service hypertrophiée (Fat Service Layer) et une modèle métier anémique (Anemic Domain Model).

Dans l’approche SOA, il faut donc accorder le même degré d’effort à la conception d’un domain model:

Avant tout, isoler un domain model qui encapsulera la logique métier et les règles métiers des objets

Implémenter le service en même temps que la couche application de façon à ce que les composants du service puissent consommer les éléments du modèle métier.

Le service deviendra juste un “proxy” pour atteindre le modèle métier.

Comment préserver le modèle ?

Les gros projets sont généralement composés de plusieurs équipes. Pour que le modèle reste cohérent malgré la division en plusieurs équipes séparées:

Chaque partie du projet doit être assignée à une équipe
Une modification dans une partie du modèle maintenue par une équipe ne doit pas déstabiliser le modèle en le rendant incohérent.
Il faut diviser le domaine en plusieurs modèles, définir des frontières entre les modèles et les liaisons entre eux.

Cette partie indique quelques patterns généraux permettant d’organiser une équipe de développement pour préserver le modèle général.

Bounded Context

Un domaine s’applique implicitement à un contexte particulier. Diviser le domaine en plusieurs sous-domaine implique d’appliquer un contexte différent à chaque sous-domaine. Chaque sous-domaine devient donc limité à un contexte d’où le contexte borné (i.e. “bounded context”). La division en contexte borné est une des étapes les plus importantes dans un projet DDD.

Ainsi:

Les sous-modèles doivent être assez petits pour être applicable à une équipe.
Le contexte d’un modèle est l’ensemble des conditions qu’on doit appliquer pour s’assurer que les termes utilisés dans le modèle prennent une sens précis.
Définir les limites du contexte permet de préserver l’unité du modèle.
Il est plus facile de maintenir un modèle quand son périmètre est connu.
Il faut bien délimiter le contexte pour éviter des duplications de logique métier si un sous-modèle empiète sur un autre.
Les échanges entre sous-domaine peuvent se faire avec des value-objects par exemples.
Un contexte englobe la notion de module.

Les divisions en contexte borné peuvent se faire suivant des critères différents:

Si une ambiguité est apparue dans l’ubiquitous language ou dans les concepts métier et qu’elle nécessite d’envisager deux contextes différents.
Pour être plus en phase avec l’organisation de plusieurs équipes ou leur emplacement physique.
Pour qu’un sous-domaine soit lié à sa fonction métier.
Intégrer du code “legacy” ou du code tiers.
Si plusieurs langages de programmation ou plusieurs technologies sont utilisés.

Un sous-domaine ne correspond pas forcément précisement à un contexte borné. En effet, un sous-domaine résulte d’une séparation fonctionnelle du domaine. Idéalement il faudrait un domain model pour chaque sous-domaine toutefois un sous-domaine peut contenir plusieurs domain models. Un contexte borné correspond à une implémentation concrète et à une séparation technique qui applique des frontières aux objets du domain model. Ainsi, un sous-domaine comporte un ou plusieurs contextes bornés et un contexte borné comporte un ou plusieurs domain models.

Partage de données entre contextes bornés

Le partage d’objets entre contextes bornés peut mener à des incohérences dans le domain model. En effet des objets provenant d’autres contextes bornés peuvent avoir été concus avec un ubiquitous language différent. Il faut donc éviter de partager directement des données entre contexte borné. Les échanges de données doivent se faire avec des DTO ou par l’intermédiaire d’une couche anticorruption.