ASFA - Méthodologie - Domain Driven Design

Méthodologie Asfa-mthodologie-ddd-18042014-frv1-150309123627-conversion-gate01
Frédéric Sagez Page 1sur 10 ASFA
Domain Driven Design
Sommaire
1 Introduction..............................................................................................................................................1
2 QU’EST CE QU’UNE BONNE CONCEPTION ?.................................................................................................1
3 QU’EST CE QUE LE DDD ?............................................................................................................................2
4 UN LANGAGE DE COMMUNICATION COMMUN ....................................................................................................3
5 ORGANISATION POUR CONCEVOIR LE MODELE METIER..........................................................................................3
6 LES CONCEPTS D’ÉLABORATION DU DOMAINE .....................................................................................................4
6.1 Architecture en couches .................................................................................................................................................................5
6.2 Entités (Entities)...............................................................................................................................................................................5
6.3 Objets-valeurs (Value Objects)......................................................................................................................................................5
6.4 Services..............................................................................................................................................................................................5
6.5 Modules.............................................................................................................................................................................................6
6.6 Agrégats (Aggregates).....................................................................................................................................................................6
6.7 Fabriques (Factories).......................................................................................................................................................................6
6.8 Entrepôts (Repositories).................................................................................................................................................................6
7 UN EXEMPLE D'ARCHITECTURE ET D’IMPLEMENTATION .........................................................................................6
7.1 Interface Utilisateur.........................................................................................................................................................................7
7.2 Services applicatifs...........................................................................................................................................................................8
7.3 Le Domaine.......................................................................................................................................................................................8
7.4 Infrastructure....................................................................................................................................................................................9
8 LES CHOSES IMPORTANTES A RETENIR ...............................................................................................................9
9 LEXIQUE....................................................................................................................................................10
1 INTRODUCTION
Au fil dutemps,lesprogressionstechnologiquesnousontpermisde construire desprogrammesde mieux en
mieux structurés.Programmesqui d’ailleurseux aussi évoluent versdeslogicielsaufonctionnementde plusen
pluscomplexes.Aujourd’hui,afinde construire desapplicationsde gestion,il estcommund’utiliserunlangage
qui implémente lesconceptsde laprogrammationorientée objet(POO).Concrètement,unobjetestune
structure de données« valuées » etcachéesqui répondàun ensemble de messagesetconstituésd'attributset
de méthodes.
Afinde prendre encompte lacomplexitécroissantedesapplications,il fautavoirunpland’actionsde
développementavecune conception.Le Domain Driven Design(ditvulgairementDDD) veuttoutsimplement
dire : la conceptionpilotéepar le domaine.
2 QU’EST CE QU’UNE BONNECONCEPTION ?
En premierlieu,une bonneconceptionpermetde développerunlogiciel qui répondaux fonctionnalités
demandées.Idéalement,ellepermetl’évolutionetlamaintenance dulogiciel.Lesévolutionsne doiventpas

remettre enquestiontoute laconceptionetl’implémentation.
Une bonne conceptionestunensemble de considérationscomme parexemplelaflexibilité,larobustesse oula
maintenabilitésuiteàdesévolutionsetdescorrections.
Pourtendre versune bonne conception,une stratégie estde découperl’applicationenmodulesensuivantla
règle « diviserpourmieux régner».
Cesmodulessuiventdesrèglesàrespecter:
 Responsabilitésidentifiéesdansdesmodulesnommés,
 Collaborationetinterfacesentre lesmodules(Gestionsdesdépendances),
 Cohésionforte etcouplage faible entrelesmodules.
3 QU’EST CE QUE LE DDD ?
Le Domain DrivenDesign estcentré sur le métierde l’applicationetle code source qui l’implémente:
 Préoccupationdudomaine métieretde salogique,

 La complexité dudomainemétierdevraitse refléterdansle modèle.
Les avantagessontlessuivants:
 Créerun modèle commun etintelligibleentre leséquipesfonctionnellesetleséquipestechniques,
 Le modèle estmodulaire,flexibleetmaintenablecaril doitrefléterlaconceptionfonctionnelle,
 Améliorerlatestabilité etlaréutilisationdesobjetsmétiers.
Le DDD estune manière de penseretde communiquerlesproblèmesetleurssolutions,entre leséquipes
techniquesetfonctionnelles:
 En développantdesapplications investissantsurle métierduSI,
 En donnantune expressivitémétieraucode source,
 En faisantcommuniquerlesdéveloppeursetlesexpertsfonctionnels,
 En vousfournissantdes techniquesde conception (patterndu DDD,refactoringcontinu),
 En vousproposantdes solutionspourorganiser une équipe de développementetmême unensemble
d’équipesde développementqui collaborententre elles,
 Et cela conduitaussi leséquipesde développementàinvestirsurle fonctionneldesapplications
d’entreprises.
Le DDD n’impose ni formalismeni méthode pouracquérirce savoir.L’interview d’expertfonctionnel pardes
développeurspeutêtre une solution.Lacommunicationentre cesdeuxentités doitêtre continue toutaulong
du projet.
4 UN LANGAGE DE COMMUNICATION COMMUN
Un développeurparle avecdes termestechniques(algorithmes,objet,méthodes,DesignPatterns,Framework,
libraires,etc.) alorsque l’expertfonctionnel ne connaitpascestermes.Il n’enapas besoinpourréaliserson
travail etil est compétentsurle domaine fonctionnel.
Les développeursdoiventréutiliserle jargondesexpertsfonctionnelsdansleursexplicationsetdansle code
source. Ce langage de communication permet:
 Construire etcultiverunlangage commun:eninterviewantlesexpertsfonctionnelsparexemple,
 Capturerla connaissance dudomaine fonctionnel,
 Produire le code,reboucleraveclesexpertsfonctionnelspourenrichirle modèleavecdestermesqui
ont dûêtre explicitéslorsdudéveloppement.
5 ORGANISATION POUR CONCEVOIR LE MODELE METIER
La conceptiondumodèle métierpeuts’effectueràtraversdesateliersde travail (dit« workshops») réunissant
lesspécialistesmétier,lesarchitectes,lesdéveloppeurs.Cesatelierspeuventêtre dirigésparle ScrumMaster
ou le chef de projetetdoiventêtre organisésrégulièrementafinde résoudre toutproblèmede vocabulaire.

Dans l’organisation, le métier est toujours au centre
Il est importantd’inclure lesdéveloppeursdanstouteslesdécisionsliéesaudomaine métier.Ilsapporterontle
pragmatisme etlesretoursd’expériencenécessairespourque le développementreflète aumieux lesbesoins
métier.Ilsse sentirontégalementgarantsetresponsablesde laqualitédurésultatfinal.
6 LES CONCEPTS D’ÉLABORATION DU DOMAINE
Le développementd’unprojetenconception orientée domaineestunprocessuscyclique qui observe plusieurs
étapes: l’élaborationoul’améliorationde l’architecture,laréalisationd’une première ébauche,le
développementdesfonctionnalités,le retourd’expérience desdéveloppeursetainsi de suite.

Type d’organisation de travail
6.1 Architecture en couches
Les architecturesconstruitesencouchespermettentd’obtenirune architecture pérenne etde faciliterla
maintenance.
Cependant,le DDDrenforce ce paradigme enproposantune couche supplémentaire« Domaine métier
» (DomainLayer),qui estinterconnectéeaveclacouche applicative.De ce fait,lacouche applicative
devientune couche fine qui permetde stockerl’étatde l’interface utilisateuretd’encoordonnerles
interactionsaveclacouche métier.
6.2 Entités (Entities)
Une entité estunobjetayantune identité métierunique qui resteconstante toutaulongducycle de vie
de l’application.
Il peutcontenirautantd’attributsque nécessaire,ainsi que descomportements(p.ex.validationde
règlesmétierslorsde lamodificationd’attributs).
6.3 Objets-valeurs (Value Objects)
Les objets-valeursviennentcomplémenterlesentités,etil estimportantde biendifférencierlesdeux.
Ilsdécoulentde deux conceptsimportants:ne pas avoird’identité et être partageableparplusieurs
modulesmétiers.
6.4 Services
Cesservicesne contiennentaucunétatinterne etle seul butestde proposerdesfonctionnalités.Il ne
fautpas créer unservice pourchaque opération,maissimplementlesregroupersousdestermes liésau
domaine métier.

6.5 Modules
Lorsque le domaine métierestcomplexe,samodélisationpeutcontenirdescentainesde Services,
EntitésetObjets-valeurs.Pourensimplifierl’organisation,le DDDintroduitle conceptde « modules»,
permettantde structurerlesfonctionnalitésenmoduleslogiques,etainsi de réduire lacomplexité
globale.
6.6 Agrégats (Aggregates)
Ce concept a été établi poursuppléerle cycle de vie desobjets,qui biensouventdoitêtre stocké et
récupéré dansune base de données,ouarchivé surle disque dur.Laproblématiquesurvientlorsqu’ilest
nécessaire d’assurerl’intégrité d’uneentité,etsurtoutdesobjets-valeursqu’elle contient.
Un agrégat estbasé sur une entité,etgarde le contrôle surcesobjets-valeursenobligeantlesservices
extérieursàpasserpar l’agrégatpourmodifierdesvaleursousupprimerl’objet.
6.7 Fabriques (Factories)
Pourfaciliterlacréationd’objetscomplexes,lesFabriquescontiennentla logique métiernécessaire àla
créationd’unobjetpropre,c’est-à-dire enayanttoussesobjets-valeursetattributsinstanciésàunétat
par défautouvide.Touteslesdépendancesnécessairesàlacréationd’unobjetvalide doiventêtre
passéesenparamètre.Pourenvérifierl’intégrité,laFabrique se charge égalementd’exécuteretde
validerlesrèglesmétiers(appeléesaussi invariants).
6.8 Entrepôts (Repositories)
Afinde distinguerlalogique métierde celled’accèsaux données,le système d’entrepôta été conçu
pour contenirle code techniqued’acquisitiondesdonnées.Dansle casd’une base de données,
l’entrepôtcontiendrale code SQLnécessaire àobtenirunnouvel objet,àrenvoyerune liste d’objets
seloncertainscritèresetégalementàassurerla persistance desobjetsenbase.Dansle cas d’un
archivage surle disque dur,il comporterale code permettantd’ouvriretde sauvegarderdesfichiersau
formatélectronique.
7 UN EXEMPLE D'ARCHITECTURE ET D’IMPLEMENTATION
Vision du cœur du modèle du domaine de l’application de la vente de légumes
Les élémentsqui peuventconstituerunmodèle dudomaine sont:
 Desobjetsayantune identité etreprésentantchacunune unité de cohérence(ex:unagriculteur,un
consommateur),

 Les servicesdudomaine,représentantdesopérationsagissantsurplusieursobjets(ex:une opération
bancaire),
 Les « repositories »,abstractiondumoyende stockage desobjets,
 Les spécifications,qui représententdesensemblesde critèresetpermettentd’exprimerdesrègles
métier(ex:changerle prix d’unlégume),
 Les évènementsdudomaine,qui matérialisentdesévènementsimportantssurvenusdansle domaine
(ex:vendre,acheter,retirer).
Une architecture implémente différentes couches
7.1 Interface Utilisateur

C’estlaprésentationdesinformationsobservablesdusystèmeàl’utilisateur,celapermetd'interpréter
lesactionsde l’utilisateurpourinteragiravecle système.
7.2 Services applicatifs
C'estune couche qui a pour responsabilité de coordonnerlesactivitésde l’application.Ellene contient
pas de logique métieretne maintientaucunétatdesobjetsdudomaine.Elle peutcependantmaintenir
un étatde lasessionapplicative.Elle porte lagestiondestransactionsetde lasécurité.Saresponsabilité
estégalementde récupérerlesobjetsdudomaineviale repositorypour“injecter”ladynamique dansle
domaine.Enfin,elle estégalementencharge de l’ajoutoulasuppressiond’objetsdansle repository.
7.3 Le Domaine
Cette couche comporte touteslesclassescorrespondantaux élémentsdumodèle dudomaine.
Dans notre exemple,l’entité Agriculteurn’estcouplée àaucunmécanisme technique.Elle utilise une

spécificationafinde savoirsi l’actionde mise envente estvalide oupas.Evidemment,pluslesrègles
sontnombreuses,complexesouutiliséesàdifférentsendroitsdumodèle,plusl’emploi d’une
spécificationse justifie !
Une foisle traitementmétierde mise enventeréalisé,unévènementdudomaine estproduitpour
notifiertouslescomposantsintéressés.Le busexploité dansnotre exemple estunbussynchrone,le but
étantsimplementici de réaliserune séparationde responsabilités.Ainsi,uncomposantmétierpourra
s’occuperde l’envoi d’une-mail àtouslesconsommateurspourlesnotifierde cette mise envente :
c’estune conséquence de l’évènementde mise envente,etcette conséquence n’estpassousla
responsabilitéde l’objetAgriculteur.
7.4 Infrastructure
Cette couche sertlesautrescouches:
 L’anti-corruption(Sertàéviterlapollutiondudomaineparun modèle externe),
 L’isolationde lacomplexitétechnique de l’application,
 La persistance desdonnéesdumodèle,
 La communicationentre lesdifférentescouches.
8 LES CHOSES IMPORTANTES A RETENIR
1. Le DDD n’estni une méthode ni une technologie,c’estune manièrede penserlaconceptionautourducode
source,
2. C'estune approche de conceptionnonintrusive,maisne résoutpastouslesproblèmes,

Frédéric Sagez Page 10 sur 10 ASFA
3. Elle estcomposée d’unlangage de communication,d’une conceptionetde sonimplémentation.Elle peut
être associée àd'autresméthodologies(UMLet/ouTDD) sansque celasoitune obligation,
4. Ce langage de communicationdoitêtre intelligible,partagé,adopté etenrichi parlesdéveloppeursetles
fonctionnels,
5. De plus,le DDD ne nécessitepasd’atelierlogicielparticulier,n’impose pasde formalisme etn’impose pas
nonplusde méthode de développement,
6. Enfin,le DDD encourage leséquipestechniquesetfonctionnellesàtravaillerensemble etàs’améliorer
ensemble.Ceséquipesserontunatoutplustard sur lesautres projets.
9 LEXIQUE
Terme Description Informations
DDD DOMAIN-DRIVEN DESIGN,
CONCEPTION PILOTEE 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 GENERALE
INHERENTE A UN SYSTEME
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
MODELISATION
GRAPHIQUE A BASE DE
PICTOGRAMMES
http://fr.wikipedia.org/wiki/UML_(informatique)
TDD TEST DRIVEN
DEVELOPMENT,
DEVELOPPEMENT PILOTE
PAR LES TESTS
http://fr.wikipedia.org/wiki/Test_Driven_Development

ASFA - Méthodologie - Domain Driven Design

Recommandé

Recommandé

Contenu connexe

Similaire à ASFA - Méthodologie - Domain Driven Design

Similaire à ASFA - Méthodologie - Domain Driven Design (20)

Plus de Frédéric Sagez

Plus de Frédéric Sagez (15)

ASFA - Méthodologie - Domain Driven Design