ASFA - Méthodologie - Domain Driven Design

Méthodologie document.docx

Domain Driven Design

Sommaire

1 Introduction........................................................................................................................................................12 QU’EST CE QU’UNE BONNE CONCEPTION ?........................................................................................................13 QU’EST CE QUE LE DDD ?....................................................................................................................................24 UN LANGAGE DE COMMUNICATION COMMUN............................................................................................................35 ORGANISATION POUR CONCEVOIR LE MODÈLE MÉTIER.................................................................................................36 LES CONCEPTS D’ÉLABORATION DU DOMAINE.............................................................................................................4

6.1 Architecture en couches..............................................................................................................................................56.2 Entités (Entities)...........................................................................................................................................................56.3 Objets-valeurs (Value Objects).....................................................................................................................................56.4 Services........................................................................................................................................................................56.5 Modules.......................................................................................................................................................................66.6 Agrégats (Aggregates)..................................................................................................................................................66.7 Fabriques (Factories)....................................................................................................................................................66.8 Entrepôts (Repositories)..............................................................................................................................................6

7 UN EXEMPLE D'ARCHITECTURE ET D’IMPLÉMENTATION................................................................................................67.1 Interface Utilisateur.....................................................................................................................................................77.2 Services applicatifs.......................................................................................................................................................87.3 Le Domaine..................................................................................................................................................................87.4 Infrastructure...............................................................................................................................................................9

8 LES CHOSES IMPORTANTES À RETENIR........................................................................................................................99 LEXIQUE..............................................................................................................................................................10

1 INTRODUCTION

Au fil du temps, les progressions technologiques nous ont permis de construire des programmes de mieux en mieux structurés. Programmes qui d’ailleurs eux aussi évoluent vers des logiciels au fonctionnement de plus en plus complexes. Aujourd’hui, afin de construire des applications de gestion, il est commun d’utiliser un langage qui implémente les concepts de la programmation orientée objet (POO). Concrètement, un objet est une structure de données « valuées » et cachées qui répond à un ensemble de messages et constitués d'attributs et de méthodes.

Afin de prendre en compte la complexité croissante des applications, il faut avoir un plan d’actions de développement avec une conception. Le Domain Driven Design (dit vulgairement DDD) veut tout simplement dire : la conception pilotée par le domaine.

2 QU’EST CE QU’UNE BONNE CONCEPTION ?

Frédéric Sagez Page 1 sur 10 ASFA


En premier lieu, une bonne conception permet de développer un logiciel qui répond aux fonctionnalités demandées. Idéalement, elle permet l’évolution et la maintenance du logiciel. Les évolutions ne doivent pas remettre en question toute la conception et l’implémentation.

Une bonne conception est un ensemble de considérations comme par exemple la flexibilité, la robustesse ou la maintenabilité suite à des évolutions et des corrections.

Pour tendre vers une bonne conception, une stratégie est de découper l’application en modules en suivant la règle « diviser pour mieux régner ».

Ces modules suivent des règles à respecter : Responsabilités identifiées dans des modules nommés, Collaboration et interfaces entre les modules (Gestions des dépendances), Cohésion forte et couplage faible entre les modules.

3 QU’EST CE QUE LE DDD ?



Le Domain Driven Design est centré sur le métier de l’application et le code source qui l’implémente : Préoccupation du domaine métier et de sa logique, La complexité du domaine métier devrait se refléter dans le modèle.

Les avantages sont les suivants : Créer un modèle commun et intelligible entre les équipes fonctionnelles et les équipes techniques, Le modèle est modulaire , flexible et maintenable car il doit refléter la conception fonctionnelle, Améliorer la testabilité et la réutilisation des objets métiers.

Le DDD est une manière de penser et de communiquer les problèmes et leurs solutions, entre les équipes techniques et fonctionnelles :

En développant des applications investissant sur le métier du SI, En donnant une expressivité métier au code source, En faisant communiquer les développeurs et les experts fonctionnels, En vous fournissant des techniques de conception (pattern du DDD, refactoring continu), En vous proposant des solutions pour organiser une équipe de développement et même un ensemble

d’équipes de développement qui collaborent entre elles, Et cela conduit aussi les équipes de développement à investir sur le fonctionnel des applications

d’entreprises.

Le DDD n’impose ni formalisme ni méthode pour acquérir ce savoir. L’interview d’expert fonctionnel par des développeurs peut être une solution. La communication entre ces deux entités doit être continue tout au long du projet.

4 UN LANGAGE DE COMMUNICATION COMMUN

Un développeur parle avec des termes techniques (algorithmes, objet, méthodes, Design Patterns, Framework, libraires, etc.) alors que l’expert fonctionnel ne connait pas ces termes. Il n’en a pas besoin pour réaliser son travail et il est compétent sur le domaine fonctionnel.

Les développeurs doivent réutiliser le jargon des experts fonctionnels dans leurs explications et dans le code source. Ce langage de communication permet:

Construire et cultiver un langage commun : en interviewant les experts fonctionnels par exemple, Capturer la connaissance du domaine fonctionnel, Produire le code, reboucler avec les experts fonctionnels pour enrichir le modèle avec des termes qui

ont dû être explicités lors du développement.

5 ORGANISATION POUR CONCEVOIR LE MODÈLE MÉTIER

La conception du modèle métier peut s’effectuer à travers des ateliers de travail (dit « workshops ») réunissant les spécialistes métier, les architectes, les développeurs. Ces ateliers peuvent être dirigés par le Scrum Master ou le chef de projet et doivent être organisés régulièrement afin de résoudre tout problème de vocabulaire.



Dans l’organisation, le métier est toujours au centre

Il est important d’inclure les développeurs dans toutes les décisions liées au domaine métier. Ils apporteront le pragmatisme et les retours d’expérience nécessaires pour que le développement reflète au mieux les besoins métier. Ils se sentiront également garants et responsables de la qualité du résultat final.

6 LES CONCEPTS D’ÉLABORATION DU DOMAINE

Le développement d’un projet en conception orientée domaine est un processus cyclique qui observe plusieurs étapes : l’élaboration ou l’amélioration de l’architecture, la réalisation d’une première ébauche, le développement des fonctionnalités, le retour d’expérience des développeurs et ainsi de suite.



Type d’organisation de travail

6.1 Architecture en couches

Les architectures construites en couches permettent d’obtenir une architecture pérenne et de faciliter la maintenance.

Cependant, le DDD renforce ce paradigme en proposant une couche supplémentaire « Domaine métier » (Domain Layer), qui est interconnectée avec la couche applicative. De ce fait, la couche applicative devient une couche fine qui permet de stocker l’état de l’interface utilisateur et d’en coordonner les interactions avec la couche métier.

6.2 Entités (Entities)

Une entité est un objet ayant une identité métier unique qui reste constante tout au long du cycle de vie de l’application.

Il peut contenir autant d’attributs que nécessaire, ainsi que des comportements (p. ex. validation de règles métiers lors de la modification d’attributs).

6.3 Objets-valeurs (Value Objects)

Les objets-valeurs viennent complémenter les entités, et il est important de bien différencier les deux. Ils découlent de deux concepts importants : ne pas avoir d’identité et être partageable par plusieurs modules métiers.

6.4 Services

Ces services ne contiennent aucun état interne et le seul but est de proposer des fonctionnalités. Il ne faut pas créer un service pour chaque opération, mais simplement les regrouper sous des termes liés au domaine métier.



6.5 Modules

Lorsque le domaine métier est complexe, sa modélisation peut contenir des centaines de Services, Entités et Objets-valeurs. Pour en simplifier l’organisation, le DDD introduit le concept de « modules », permettant de structurer les fonctionnalités en modules logiques, et ainsi de réduire la complexité globale.

6.6 Agrégats (Aggregates)

Ce concept a été établi pour suppléer le cycle de vie des objets, qui bien souvent doit être stocké et récupéré dans une base de données, ou archivé sur le disque dur. La problématique survient lorsqu’il est nécessaire d’assurer l’intégrité d’une entité, et surtout des objets-valeurs qu’elle contient.

Un agrégat est basé sur une entité, et garde le contrôle sur ces objets-valeurs en obligeant les services extérieurs à passer par l’agrégat pour modifier des valeurs ou supprimer l’objet.

6.7 Fabriques (Factories)

Pour faciliter la création d’objets complexes, les Fabriques contiennent la logique métier nécessaire à la création d’un objet propre, c’est-à-dire en ayant tous ses objets-valeurs et attributs instanciés à un état par défaut ou vide. Toutes les dépendances nécessaires à la création d’un objet valide doivent être passées en paramètre. Pour en vérifier l’intégrité, la Fabrique se charge également d’exécuter et de valider les règles métiers (appelées aussi invariants).

6.8 Entrepôts (Repositories)

Afin de distinguer la logique métier de celle d’accès aux données, le système d’entrepôt a été conçu pour contenir le code technique d’acquisition des données. Dans le cas d’une base de données, l’entrepôt contiendra le code SQL nécessaire à obtenir un nouvel objet, à renvoyer une liste d’objets selon certains critères et également à assurer la persistance des objets en base. Dans le cas d’un archivage sur le disque dur, il comportera le code permettant d’ouvrir et de sauvegarder des fichiers au format électronique.

7 UN EXEMPLE D'ARCHITECTURE ET D’IMPLÉMENTATION

Vision du cœur du modèle du domaine de l’application de la vente de légumes

Les éléments qui peuvent constituer un modèle du domaine sont : Des objets ayant une identité et représentant chacun une unité de cohérence (ex: un agriculteur, un

consommateur),



Les services du domaine, représentant des opérations agissant sur plusieurs objets (ex: une opération bancaire),

Les « repositories », abstraction du moyen de stockage des objets, Les spécifications, qui représentent des ensembles de critères et permettent d’exprimer des règles

métier (ex: changer le prix d’un légume), Les évènements du domaine, qui matérialisent des évènements importants survenus dans le domaine

(ex: vendre, acheter, retirer).

Une architecture implémente différentes couches

7.1 Interface Utilisateur



C’est la présentation des informations observables du système à l’utilisateur, cela permet d'interpréter les actions de l’utilisateur pour interagir avec le système.

7.2 Services applicatifs

C'est une couche qui a pour responsabilité de coordonner les activités de l’application. Elle ne contient pas de logique métier et ne maintient aucun état des objets du domaine. Elle peut cependant maintenir un état de la session applicative. Elle porte la gestion des transactions et de la sécurité. Sa responsabilité est également de récupérer les objets du domaine via le repository pour “injecter” la dynamique dans le domaine. Enfin, elle est également en charge de l’ajout ou la suppression d’objets dans le repository.

7.3 Le Domaine

Cette couche comporte toutes les classes correspondant aux éléments du modèle du domaine.

Dans notre exemple, l’entité Agriculteur n’est couplée à aucun mécanisme technique. Elle utilise une spécification afin de savoir si l’action de mise en vente est valide ou pas. Evidemment, plus les règles



sont nombreuses, complexes ou utilisées à différents endroits du modèle, plus l’emploi d’une spécification se justifie !

Une fois le traitement métier de mise en vente réalisé, un évènement du domaine est produit pour notifier tous les composants intéressés. Le bus exploité dans notre exemple est un bus synchrone, le but étant simplement ici de réaliser une séparation de responsabilités. Ainsi, un composant métier pourra s’occuper de l’envoi d’un e-mail à tous les consommateurs pour les notifier de cette mise en vente : c’est une conséquence de l’évènement de mise en vente, et cette conséquence n’est pas sous la responsabilité de l’objet Agriculteur.

7.4 Infrastructure

Cette couche sert les autres couches : L’anti-corruption (Sert à éviter la pollution du domaine par un modèle externe), L’isolation de la complexité technique de l’application, La persistance des données du modèle, La communication entre les différentes couches.

8 LES CHOSES IMPORTANTES À RETENIR

1. Le DDD n’est ni une méthode ni une technologie , c’est une manière de penser la conception autour du code source,

2. C'est une approche de conception non intrusive, mais ne résout pas tous les problèmes,3. Elle est composée d’un langage de communication, d’une conception et de son implémentation. Elle peut

être associée à d'autres méthodologies (UML et/ou TDD) sans que cela soit une obligation,



4. Ce langage de communication doit être intelligible, partagé, adopté et enrichi par les développeurs et les fonctionnels,

5. De plus, le DDD ne nécessite pas d’atelier logiciel particulier, n’impose pas de formalisme et n’impose pas non plus de méthode de développement,

6. Enfin, le DDD encourage les équipes techniques et fonctionnelles à travailler ensemble et à s’améliorer ensemble. Ces équipes seront un atout plus tard sur les autres projets.

9 LEXIQUE

Terme Description Informations

DDD DOMAIN-DRIVEN DESIGN, CONCEPTION PILOTÉE PAR LE DOMAINE

http://en.wikipedia.org/wiki/Domain-driven_design

POO PROGRAMMATION ORIENTÉE OBJET

http://fr.wikipedia.org/wiki/Programmation_orient%C3%A9e_objet

REFACTORING RÉ-USINAGE DE CODE http://fr.wikipedia.org/wiki/R%C3%A9usinage_de_code

ARCHITECTURE STRUCTURE GÉNÉRALE INHÉRENTE À UN SYSTÈME INFORMATIQUE

http://fr.wikipedia.org/wiki/Architecture_(informatique)

REPOSITORY DÉPÔT OU RÉFÉRENTIEL http://fr.wikipedia.org/wiki/D%C3%A9p%C3%B4t_(informatique)

UML UNIFIED MODELING LANGUAGE, LANGAGE DE MODÉLISATION GRAPHIQUE À BASE DE PICTOGRAMMES

http://fr.wikipedia.org/wiki/UML_(informatique)

TDD TEST DRIVEN DEVELOPMENT, DÉVELOPPEMENT PILOTÉ PAR LES TESTS

http://fr.wikipedia.org/wiki/Test_Driven_Development


http://fr.wikipedia.org/wiki/Test_Driven_Development

http://fr.wikipedia.org/wiki/UML_(informatique)

http://fr.wikipedia.org/wiki/D%C3%A9p%C3%B4t_(informatique)

http://fr.wikipedia.org/wiki/Architecture_(informatique)

http://fr.wikipedia.org/wiki/R%C3%A9usinage_de_code

http://fr.wikipedia.org/wiki/Programmation_orient%C3%A9e_objet

http://en.wikipedia.org/wiki/Domain-driven_design

Technology

ASFA - Méthodologie - Domain Driven Design