anteo mda aosd

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