ASFA - Méthodologie - Domain Driven Design

333 vues

Publié le

Présentation de la méthodologie Domain Driven Design.

Ce document est rattaché à la présentation http://fr.slideshare.net/fredericsagez/asfa-mthodologie-organisation

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
333
Sur SlideShare
0
Issues des intégrations
0
Intégrations
5
Actions
Partages
0
Téléchargements
6
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

ASFA - Méthodologie - Domain Driven Design

  1. 1. 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
  2. 2. Méthodologie Asfa-mthodologie-ddd-18042014-frv1-150309123627-conversion-gate01 Frédéric Sagez Page 2sur 10 ASFA 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,
  3. 3. Méthodologie Asfa-mthodologie-ddd-18042014-frv1-150309123627-conversion-gate01 Frédéric Sagez Page 3sur 10 ASFA  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.
  4. 4. Méthodologie Asfa-mthodologie-ddd-18042014-frv1-150309123627-conversion-gate01 Frédéric Sagez Page 4sur 10 ASFA 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.
  5. 5. Méthodologie Asfa-mthodologie-ddd-18042014-frv1-150309123627-conversion-gate01 Frédéric Sagez Page 5sur 10 ASFA 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. 6. Méthodologie Asfa-mthodologie-ddd-18042014-frv1-150309123627-conversion-gate01 Frédéric Sagez Page 6sur 10 ASFA 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),
  7. 7. Méthodologie Asfa-mthodologie-ddd-18042014-frv1-150309123627-conversion-gate01 Frédéric Sagez Page 7sur 10 ASFA  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
  8. 8. Méthodologie Asfa-mthodologie-ddd-18042014-frv1-150309123627-conversion-gate01 Frédéric Sagez Page 8sur 10 ASFA 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
  9. 9. Méthodologie Asfa-mthodologie-ddd-18042014-frv1-150309123627-conversion-gate01 Frédéric Sagez Page 9sur 10 ASFA 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,
  10. 10. Méthodologie Asfa-mthodologie-ddd-18042014-frv1-150309123627-conversion-gate01 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

×