View
672
Download
1
Category
Preview:
DESCRIPTION
Citation preview
Pôle ConseilOffre de conseil et d’expertise du Groupe Sodifrance
Aider nos clients à répondre aux problématiques soulevées par les enjeux des technologies de l’information autour du développement et de la maintenance de leurs Systèmes d’Information :
AMOA : Optimiser le cycle logiciel entre les besoins exprimés par une MOA et sa réalisation par la MOE
Pilotage des projets
Accompagner nos clients dans la production de leurs projets à l’aide de méthodes traditionnelles ou agiles
Architecture technique J2EE /.Net
S'aligner sur les nouvelles architectures et bénéficier de leurs avantages
Industrialisation & MDA :
Accélérer et pérenniser les approches et les développements
Accompagnement & Formation :
Assurer le transfert de compétences, à travers notre organisme de formation agréé disposant de formateurs issus du monde « opérationnel ».
Domain Driven Designou « Comment tacler la complexité au
cœur du logiciel ? »
But de la présentation
Présenter l’idée centrale du DDDDDD est vraiment très riche
Cette présentation est vraiment très courte
4
Origine
Eric Evans
2003
5
Définition : le domaine
Sujet auquel un utilisateur applique un programme
sphère de connaissances, d’influences et d’activités
=~ Métier / Business / Fonctionnel / Marché
Focalisé sur
la valeur ajoutée
l’avantage concurrentiel
6
Exemple de domaine
Application de fret de marchandise longue distance
Avantage concurrentiel
• Rapidité de livraison• Optimisation du fret
• Suivi en direct des marchandises• Traçabilité
• Etc.
7
Définition : Complexité(s) d’un système logiciel
Complexité inhérenterelié au problème qu’il essaye de résoudre
Complexité réelle relié à la taille et à la structure du système réellement construit
=> différenceune mesure de l’incapacité à faire correspondre la solution au problème
8
- Kevlin Henney, “For the sake of simplicity” (1999)
DDD : Quel objectif ?
Minimiser cette différenceTacler la complexité réelle
Clarifier la complexité inhérente
FocaliserLe logiciel sur l’avantage concurrentiel
L’entreprise sur sa stratégie
9
Quels moyens ?
Aspects techniques
Techniques de modélisation
Stratégies d’entreprise
Principes et bonnes pratiques
10http://www.flickr.com/photos/phploveme/2746295460
Quels acteurs ?
Toute partie prenante
L’équipe créatrice du logiciel
Les experts du domaines
Les utilisateurs
La direction• Stratégie
11
Pré-requis
Processus itératif
Accès aux experts du domaine
ÞAgilité
12
Modéliser le domainevers une compréhension accrue
13
Définition : le modèle
Représentation / vue
du domaine
pour un but particulier : contexte borné
sous-jacente• Pas
• « un » document UML• Mais exprimé dans
• Le code• Les discussions et le vocabulaire• Des diagrammes « type-UML »
14
Le modèle est vivant
Apprentissage permanent
Brainstorming
Expérimentation
Récupération de connaissances• Livres• Utilisateurs• Modèles déjà publiés• …
Collaboration avec les experts du domaine
15
16
Expression purifiée de l’éléctromagnétismeJames Clerk Maxwell, A Treatise on Electricity and Magnetism, 1873
Un langage omniprésent(ubiquitous language)
Bruegel
17
18
Des analystes de terrain,des hommes de terrains analystes
Distiller le domaineExtraire l’essence du domaine
19
Cœur du domaine
Y mettre
Ce qui a le plus de valeur• Avantage concurrentiel
Le faire
Petit
L’attribuer
aux développeurs • Talentueux
• Tendances contraires !
• Pérennes • internes
20
Sous-domaines génériques
Ensembles de concepts
Cohérents
N’étant pas la motivation propre du projet• En support des autres domaines
Ne pas mettre les développeurs principaux
Considérer les solutions• Sur étagère• Externalisés
Exemple
Gestion de fuseaux horaires
Pas forcément réutilisable
non prioritaire
21
Cartographier le Système, ses interactions et ses contextes
Maintenir l’intégrité du modèle
22
Contexte borné (bounded context)
http://www.infoq.com/articles/ddd-contextmappingAlberto Brandolini
23
Cartographie des contextes
Interactions entre composant des systèmes
Les modules de l’application entre eux
Les applications entre elles
http://www.infoq.com/articles/ddd-contextmappingAlberto Brandolini
24
Noyau partagé
Eric Evans, DOMAIN-DRIVEN DESIGN, Addison-Wesley, Eric Evans, 2004.Creative Commons Deed: Attribution 2.0
25
TranslationMap
shared
Client / fournisseur
http://www.flickr.com/photos/chilangoco/ 26
Conformiste
http://www.flickr.com/photos/mckaysavage/ 27
http://www.flickr.com/photos/hansol/ 28
Hôte ouvert
http://www.flickr.com/photos/57768426@N00/ 29
Notre sous système
Coucheanti-corruption
Autre sous système
Façade
Service A Service B
Traducteur 1
Adaptateur 1 Adaptateur 2
Interface compliquée 423XB
…
…
……
……
…
Classe pas très propre
Classe élégante
Classe expressive
… …
Couche anti-corruption
Expose des services traités par un autre sous-système (legacy)
Dans le langage ubiquitaire
Met en valeur le strict nécessaire de ce sous système
Pattern façade
Relie les deux
Patterns adaptateurs
30
Exemple de carte
http://www.infoq.com/articles/ddd-contextmappingAlberto Brandolini
31
Conclusion
32
L’essentiel
Collaboration créative entre experts du domaine et experts du logiciel
Exploration et expérimentation
Modèles émergents formant et reformant le langage ubiquitaire
Frontières des contextes explicites
Se concentrer sur le cœur domaine
33
http://www.flickr.com/photos/phploveme/2746295460
35
?Questions
http://blog.anteo-consulting.com/
gcollic@sodifrance.fr
Recommended