Un rsum de Domain Driven Design dEric Evans

Domain-Driven
Design Vite fait

par Abel Avram & Floyd Marinescu

dit par : Dan Bergh Johnsson, Vladimir Gitlevich
traduction : Guillaume Lebur

Domain-Driven Design

Vite fait

 2006 C4Media Inc

Tous droits rservs.
C4Media, Editeur de InfoQ.com.
Ce livre fait partie de la collection de livres InfoQ Enterprise Software Development.
Pour plus dinformations ou pour commander ce livre ou dautres livres InfoQ, prire de contacter
books@c4media.com.
Aucune partie de cette publication ne peut tre reproduite, stocke dans un systme de
recherche, ou transmise sous aucune forme ni aucun moyen, lectronique, mcanique,
photocopiage, recodage, scanner ou autre sans que cela ne soit autoris par les Sections
107 ou 108 du Copyright Act 1976 des Etats-Unis, ni sans lautorisation crite pralable de
lditeur.
Les termes utiliss par les entreprises pour distinguer leurs produits sont souvent dclars
comme des marques commerciales. Dans tous les cas o C4Media Inc. est informe dune telle
dclaration, les noms de produits apparaissent avec une Majuscule initiale ou EN TOUTES
LETTRES MAJUSCULES.
Toutefois, les lecteurs devraient contacter les entreprises appropries pour des informations plus
compltes au sujet des marques commerciales et de leur enregistrement.
Certains diagrammes utiliss dans ce livre ont t reproduits, avec autorisation, sous la licence
Creative Commons, courtesy of : Eric Evans, DOMAIN-DRIVEN DESIGN, Addison-Wesley,
Eric Evans, 2004.
Crdits de production :
Rsum DDD par : Abel Avram
Responsable ditorial : Floyd Marinescu
Couverture : Gene Steffanson
Composition: Laura Brown et Melissa Tessier
Traduction : Guillaume Lebur
Remerciements spciaux Eric Evans.
Library of Congress Cataloging-in-Publication Data:
ISBN: 978-1-4116-0925-9
Imprim aux Etats-Unis dAmrique
10 9 8 7 6 5 3 2 1

Table des matires

Prface : Pourquoi DDD Vite fait ? ........................................................................................ 6
Introduction ........................................................................................................................... 8
1

Quest-ce que Domain Driven Design ? ........................................................................10

Btir la connaissance du domaine ............................................................................14

Le Langage omniprsent ..............................................................................................18

Le besoin dun langage commun ..............................................................................18
Crer le Langage omniprsent..................................................................................20

Conception dirige par le Modle .................................................................................26

Les blocs de construction dune conception oriente Modle....................................30
Larchitecture en couches .........................................................................................30
Les Entits................................................................................................................33
Les Objets-Valeurs ...................................................................................................35
Les Services .............................................................................................................37
Les Modules .............................................................................................................40
Les Agrgats.............................................................................................................41
Les Fabriques ...........................................................................................................45
Les Entrepts............................................................................................................49

Refactorer pour une vision plus profonde .....................................................................55

Refactorer en continu................................................................................................55
Mettre au jour les concepts cls................................................................................57

Prserver lintgrit du modle .....................................................................................62

Contexte born .........................................................................................................63
Intgration continue ..................................................................................................66
Carte de Contexte.....................................................................................................67
Noyau partag ..........................................................................................................68
Client-Fournisseur ....................................................................................................69

Conformiste ..............................................................................................................71
Couche anticorruption...............................................................................................73
Chemins spars......................................................................................................75
Service Hte ouvert ..................................................................................................76
Distillation .................................................................................................................77
6

DDD compte aujourdhui : une interview dEric Evans .................................................82

Lexique franais-anglais des termes DDD............................................................................88

Prface : Pourquoi DDD Vite fait ?

Jai entendu parler de Domain Driven Design et jai rencontr Eric Evans pour la
premire fois dans une petite assemble darchitectes lors dune confrence organise
la montagne par Bruce Eckel lt 2005. Un certain nombre de gens que je respecte
participaient la confrence, dont Martin Fowler, Rod Johnson, Cameron Purdy,
Randy Stafford et Gregor Hohpe.
Le groupe semblait assez impressionn par la vision Domain Driven Design, et
impatient den apprendre plus. Jai aussi senti que tout le monde aurait aim que ces
concepts rentrent davantage dans les moeurs. Quand jai constat quEric utilisait le
modle du domaine pour proposer des solutions divers dfis techniques dont le
groupe discutait, et mesur limportance quil accordait au domaine mtier plutt qu
la hype autour dune technologie en particulier, jai tout de suite su que cette vision
tait de celles qui manquaient cruellement la communaut.
Nous, les membres de la communaut des dveloppeurs dapplications dentreprise, et
particulirement la communaut des dveloppeurs web, avons t pollus par des
annes dune hype qui nous a loigns du dveloppement orient objet en lui-mme.
Dans la communaut Java, la notion de bon modle de domaine sest perdue, noye
dans la frnsie autour des EJB et des modles container/component des annes 19992004. Par chance, des changements technologiques et les expriences collectives de la
communaut du dveloppement logiciel sont en train de nous ramener vers les
paradigmes orient objet traditionnels. Cependant, il manque la communaut une
vision claire de la manire dappliquer lorient objet lchelle de lEntreprise, raison
pour laquelle je pense que DDD est important.
Malheureusement, hormis un petit groupe darchitectes parmi les plus vtrans, javais
la perception que trs peu de gens taient au courant de DDD, et cest pour cela
quInfoQ a command lcriture de ce livre.
Jai bon espoir quen publiant un rsum, une introduction aux fondamentaux de DDD
courte et rapide lire et en la rendant librement tlchargeable sur InfoQ avec ct
une version papier de poche et bon march, cette vision puisse devenir parfaitement
rpandue.
Ce livre nintroduit aucun concept nouveau ; il tente de rsumer de faon concise
lessence de DDD, puisant principalement dans le livre original dEric Evans sur le
sujet, ainsi que dans dautres sources publies depuis comme l Applying DDD de
Jimmy Nilsson et divers forums de discussion sur DDD. Ce livre vous donnera un
cours acclr sur les fondamentaux de DDD, mais il ne se substitue pas aux
6

nombreux exemples et tudes de cas fournies dans le livre dEric ou aux exemples de
terrain proposs dans le livre de Jimmy. Je vous encourage vivement lire lun et
lautre de ces deux excellents ouvrages. En attendant, si vous pensez que la
communaut a besoin que DDD fasse partie de notre conscience collective, nhsitez
pas parler autour de vous de ce livre et du travail dEric.
Floyd Marinescu
Co-fondateur et Chief Editor dInfoQ.com

Introduction
Les logiciels sont des instruments crs pour nous aider traiter la complexit de la
vie moderne. Les logiciels sont juste un moyen pour nous datteindre un but, et
gnralement ce but est quelque chose de tout fait pratique et rel. Par exemple nous
utilisons des logiciels pour le contrle du trafic arien, ce qui est directement reli au
monde qui nous entoure. Nous voulons aller dun endroit un autre par la voie des
airs, et pour a nous utilisons une machinerie sophistique, alors nous crons des
logiciels pour coordonner les vols des milliers davions qui se trouvent dans le ciel
toute heure.
Les logiciels doivent tre pratiques et utiles ; autrement nous ninvestirions pas autant
de temps et de ressources dans leur cration. Cela les rend minemment relis un
certain aspect de nos vies. Un paquetage logiciel utile ne peut pas tre dcorrl de
cette sphre de ralit : le domaine quil est cens nous aider grer. Au contraire, le
logiciel y est profondment entreml.
La conception de logiciels est un art, et comme tout art elle ne peut pas tre enseigne
et apprise comme une science prcise, au moyen de thormes et de formules. Nous
pouvons dcouvrir des principes et des techniques utiles appliquer tout au long du
processus de cration de logiciel, mais nous ne serons probablement jamais capables
de fournir un chemin exact suivre en partant du besoin du monde rel pour arriver
jusquau module de code destin rpondre ce besoin. Comme une photo ou un
btiment, un produit logiciel contiendra toujours la touche personnelle de ceux qui
lont conu et dvelopp, un petit quelque chose du charisme et du flair (ou du manque
de flair) de ceux qui ont contribu sa naissance et sa croissance.
Il y a diffrentes manires daborder la conception logicielle. Ces 20 dernires annes,
lindustrie du logiciel a connu et utilis plusieurs mthodes pour crer ses produits,
chacune avec ses avantages et ses inconvnients. Lobjectif de ce livre est de se
focaliser sur une mthode de conception qui a merg et volu au cours des deux
dernires dcennies, mais sest plus distinctement cristallise depuis quelques annes :
la conception dirige par le domaine. Eric Evans a grandement contribu la question
en couchant sur le papier dans un unique livre une grande part de la connaissance
accumule sur la conception dirige par le domaine. Pour une prsentation plus
dtaille du sujet, nous vous recommandons la lecture de son livre Domain-Driven
Design: Tackling Complexity in the Heart of Software publi par Addisson-Wesley,
ISBN: 0-321-12521-5.

Vous pourrez aussi dcouvrir de nombreux et prcieux points de vue en suivant le

groupe de discussion Domain Driven Design ladresse :
http://groups.yahoo.com/group/domaindrivendesign
Ce livre est seulement une introduction au sujet, destine vous donner rapidement
une comprhension fondamentale, mais non dtaille, de Domain Driven Design.
Nous voulons simplement aiguiser votre apptit pour les bonnes pratiques de
conception logicielle grce aux principes et lignes directrices utilises dans le monde
de la conception dirige par le domaine.

1
Quest-ce que Domain Driven Design ?
Le dveloppement logiciel est le plus souvent employ pour automatiser des processus
qui existent dj dans le monde rel, ou pour fournir des solutions des problmes
mtier rels. Ces processus mtier automatiser ou ces problmes du monde rel que
le logiciel traite constituent le domaine du logiciel. Nous devons comprendre ds le
dpart que le logiciel trouve son origine dans ce domaine et lui est profondment li.
Les logiciels sont faits de code. Nous pourrions tres tents de passer trop de temps sur
le code, et voir les logiciels simplement comme des objets et des mthodes.
Pensez la mtaphore de la fabrication de voitures. Les travailleurs impliqus dans la
construction automobile peuvent se spcialiser dans la production de pices de voiture,
mais ce faisant ils ont souvent une vision limite du processus de fabrication
automobile dans son ensemble. Ils commencent voir la voiture comme un norme
assemblage de pices qui doivent aller les unes avec les autres, mais une voiture est
bien plus que cela. Une bonne voiture, a commence par une vision. Cela commence
par des spcifications crites avec soin. Et a se poursuit avec de la conception.
Beaucoup, beaucoup de conception. Des mois, peut-tre des annes passes sur la
conception, la modifier et la raffiner jusqu ce quelle atteigne la perfection,
jusqu ce quelle reflte la vision originale. Le processus de conception ne se fait pas
entirement sur papier. Une grande partie consiste fabriquer des modles de la
voiture, et les tester sous certaines conditions pour vrifier quils marchent. On
modifie la conception sur la base des rsultats de ces tests. Finalement, la voiture est
envoye en production, et les pices sont cres et assembles.
Le dveloppement logiciel est similaire. On ne peut pas se contenter de rester assis et
taper du code. On peut le faire, et a marche bien pour des cas triviaux. Mais on ne
peut pas crer des logiciels complexes de cette manire.
Pour crer un bon logiciel, vous devez savoir de quoi il y est question. Vous ne pouvez
pas crer un systme logiciel bancaire moins davoir une bonne comprhension de ce
quest la banque, vous devez comprendre le domaine de la banque.

10

Est-il possible de crer un logiciel bancaire complexe sans une bonne connaissance du
domaine ? Pas une seconde. Jamais. Qui sy connait en banque ? Larchitecte logiciel ?
Non. Il utilise juste une banque pour sassurer que son argent est en scurit et
disponible quand il en a besoin. Lanalyste logiciel ? Pas vraiment. Il sait analyser un
sujet prcis, quand on lui donne tous les lments ncessaires. Le dveloppeur ? Vous
pouvez tout de suite oublier. Qui, alors ? Les banquiers, bien sr. Le systme bancaire
est trs bien compris par les gens de lintrieur, par ses spcialistes. Ils en connaissent
tous les dtails, tous les piges, tous les problmes possibles, toutes les rgles. Voil
par o lon devrait toujours commencer : le domaine.
Lorsque nous dbutons un projet informatique, nous devrions nous concentrer sur le
domaine dans lequel il opre. Le seul but du logiciel est damliorer un domaine
spcifique. Pour tre capable de faire cela, le logiciel doit se mettre au diapason du
domaine pour lequel il a t cr. Sans cela, il introduira des tensions dans le domaine,
provoquant des dysfonctionnements, des dgts, voire mme semant le chaos.
Comment peut-on mettre le logiciel au diapason du domaine ? La meilleure faon dy
arriver est de faire du logiciel un reflet du domaine. Le logiciel doit incorporer les
concepts et lments qui sont au cur du domaine, et saisir avec prcision les relations
entre eux. Le logiciel doit modliser le domaine.
Quelquun qui na pas de connaissances bancaires doit pouvoir en apprendre beaucoup
en lisant simplement le code du modle du domaine. Cest essentiel. Un logiciel dont
les racines ne sont pas enfouies profondment dans le domaine ne ragira pas bien au
changement au fil du temps.
On commence donc par le domaine. Quoi dautre ensuite ? Un domaine est une chose
qui appartient ce bas-monde. On ne peut pas juste le prendre et le verser sur le
clavier afin quil rentre dans lordinateur et devienne du code. Il nous faut crer une
abstraction du domaine. On en apprend beaucoup sur un domaine quand on parle avec
les experts du domaine. Mais cette connaissance brute ne sera pas facilement
transformable en des constructions logicielles, moins que nous en fabriquions une
abstraction, un schma dans notre esprit. Au dbut, le schma est toujours incomplet.
Mais avec le temps, en travaillant dessus, nous lamliorons et il devient de plus en
plus clair pour nous. Quest-ce que cette abstraction ? Cest un modle, un modle du
domaine. Selon Eric Evans, un modle du domaine nest pas un diagramme
particulier ; cest lide quon cherche vhiculer travers le diagramme. Ce nest pas
simplement la connaissance contenue dans le cerveau dun expert du domaine ; cest
une abstraction rigoureusement organise et slective de cette connaissance. Un
diagramme peut reprsenter et communiquer un modle, comme peut le faire un code
soigneusement crit, comme peut le faire aussi une phrase en franais.

11

Le modle est notre reprsentation interne du domaine cibl, et elle est absolument
ncessaire tout au long de la conception comme du processus de dveloppement.
Pendant la conception, nous nous remmorons le modle et nous nous y rfrons de
nombreuses fois. Le monde qui nous entoure reprsente bien plus que ce que nos
cerveaux peuvent traiter. Mme un domaine spcifique pourrait bien tre plus que ce
quun esprit humain peut manier la fois. Nous devons organiser linformation, la
systmatiser, la diviser en plus petits morceaux, regrouper ces morceaux dans des
modules logiques, en prendre un la fois et le traiter. Il nous faut mme laisser de ct
certaines parties du domaine. Un domaine contient simplement une masse trop grande
dinformation pour linclure toute entire dans le modle. Et pour une grande partie, il
nest mme pas ncessaire de la prendre en compte. Cest un dfi en soi. Que garder et
quoi jeter ? Ca fait partie de la conception, du processus de cration logicielle. Le
logiciel bancaire gardera surement une trace de ladresse du client, mais il ne devrait
pas soccuper de la couleur de ses yeux. Cest un exemple vident, mais il peut y en
avoir dautres moins flagrants.
Un modle est une partie essentielle dune conception logicielle. Nous en avons besoin
pour pouvoir grer la complexit. Toute notre mcanique de raisonnement sur le
domaine est synthtise dans ce modle. Tout a est trs bien, mais cela doit sortir de
notre esprit. Ce nest pas trs utile si a y reste enferm, vous ne croyez pas ? Nous
devons communiquer ce modle aux experts du domaine, nos collgues concepteurs,
et aux dveloppeurs. Le modle est lessence du logiciel, mais nous devons inventer
des faons de lexprimer, de le transmettre aux autres. Nous ne sommes pas tout seuls
dans ce processus, nous devons donc partager la connaissance et linformation, et nous
devons le faire bien, prcisment, compltement et sans ambigit. Il y a diffrentes
manires de le faire. Lune est graphique : diagrammes, cas dutilisation, dessins,
photos, etc. Lautre est de lcrire. De coucher sur le papier notre vision du domaine.
Une autre encore est le langage. Nous pouvons et nous devrions crer un langage pour
communiquer des problmes spcifiques du domaine. Nous dtaillerons tous ces
moyens plus tard, mais lide principale est que nous devons communiquer le modle.
Lorsque notre modle est exprim, on peut commencer concevoir le code. Ce qui est
diffrent de concevoir le logiciel. Concevoir le logiciel, cest comme imaginer
larchitecture dune maison, cest porter un il global sur ldifice. A linverse,
concevoir le code cest travailler les dtails, comme lemplacement dun tableau sur tel
ou tel mur. Le design du code est tout aussi important, mais pas aussi fondamental que
la conception du logiciel. Une erreur dans le design du code se corrige dhabitude
facilement, tandis que les erreurs de conception du logiciel sont beaucoup plus
coteuses rparer. Cest une chose de dplacer un tableau un peu plus gauche, mais
cen est une toute autre de dmolir un ct de la maison pour le refaire diffremment.
Nanmoins, le produit final ne sera pas bon sans un bon design du code. Cest l que
les design patterns de code savrent pratiques, et on devrait toujours les appliquer
12

quand cest ncessaire. De bonnes techniques de programmation aident crer du code

propre et maintenable.
Il y a diffrentes approches de la conception logicielle. Une dentre elles est la
mthode de conception en cascade. Cette mthode implique un certain nombre
dtapes. Les experts mtiers mettent en place un ensemble de spcifications qui sont
communiques aux analystes mtier. Les analystes crent un modle bas sur ces
spcifications, et font passer le rsultat aux dveloppeurs, qui se mettent coder en se
basant sur ce quils ont reu. Cest un flux de connaissance sens unique. Mme si
cette approche a t une approche traditionnelle en conception de logiciels et quon la
utilise avec un certain degr de succs au fil des annes, elle a ses failles et ses
limites. Le principal problme est quil ny a pas de feedback des analystes aux experts
mtier ni des dveloppeurs aux analystes.
Une autre approche est celle des Mthodes Agiles, comme eXtreme Programming
(XP). Ces mthodologies sont un mouvement collectif contre lapproche en cascade,
rsultant de la difficult dessayer dobtenir toutes les spcifications ds le dbut,
particulirement la lumire du fait que les exigences peuvent changer. Cest vraiment
difficile de crer un modle complet qui couvre davance tous les aspects dun
domaine. Ca demande beaucoup de rflexion, souvent on ne voit pas tous les enjeux
ds le dbut, et on ne peut pas prvoir non plus certains effets de bord ngatifs ou
erreurs dans notre conception. Un autre problme que lagilit essaie de rsoudre est ce
quon appelle l analysis paralysis , situation o les membres de lquipe ont
tellement peur de prendre des dcisions de conception quil ne progressent pas du tout.
Mme si les aptres de lagilit reconnaissent limportance des dcisions de
conception, ils sopposent lide de tout concevoir ds le dbut. Au lieu de a, ils
font un grand usage de la flexibilit dans limplmentation, et travers un
dveloppement itratif, une participation continue du dcideur mtier et beaucoup de
refactoring, lquipe de dveloppement parvient en apprendre plus sur le domaine du
client et peut mieux produire du logiciel qui satisfait les besoins du client.
Les mthodes Agiles ont leurs propres problmes et leurs limites ; elles prnent la
simplicit, mais chacun a sa propre vision de ce que cela veut dire. De plus, un
refactoring fait en continu par des dveloppeurs sans de solides principes de design
produira du code difficile comprendre ou modifier. Et sil est vrai que lapproche
en cascade peut mener une surabondance dingnierie, la crainte de lexcs
dingnierie peut quant elle conduire une autre peur : celle de mener une
conception en profondeur et mrement rflchie.
Ce livre prsente les principes de Domain-Driven Design qui, quand ils sont appliqus,
peuvent grandement augmenter la capacit de nimporte quel processus de
dveloppement modliser et implmenter les problmatiques complexes dun

13

domaine de faon maintenable. Domain-Driven Design combine pratiques de

conception et de dveloppement, et montre comment la conception et le
dveloppement peuvent travailler de concert pour crer une meilleure solution. Une
bonne conception va amliorer le dveloppement, de mme que le feedback provenant
du processus de dveloppement va amliorer le design.

Btir la connaissance du domaine

Considrons lexemple dun projet de systme de surveillance de vols aronautiques,
et voyons comment la connaissance du domaine peut tre btie.
A un instant donn, des milliers davions sont en lair dans tous les cieux de la plante.
Ils cheminent chacun vers leur destination, et il est assez important de sassurer quils
ne se heurtent pas en lair. Nous nessaierons pas de travailler sur le systme de
contrle du trafic tout entier, mais sur un plus petit sous-ensemble : un systme de
suivi de vol. Le projet propos est un systme de surveillance qui repre chaque vol
dans une zone donne, dtermine si le vol suit sa route prvue ou non, et sil y a
possibilit de collision.
Par o allons-nous commencer, dun point de vue dveloppement ? Dans la section
prcdente, nous avons dit que nous devrions commencer par comprendre le domaine,
qui dans ce cas est le suivi du trafic arien. Les aiguilleurs du ciel sont les spcialistes
de ce domaine. Mais les aiguilleurs ne sont pas des concepteurs systme ni des
spcialistes en informatique. Vous ne pouvez pas attendre deux quils vous tendent
une description complte du domaine qui pose problme.
Les aiguilleurs du ciel ont une vaste connaissance de leur domaine, mais pour pouvoir
btir un domaine, vous devez extraire linformation essentielle et la gnraliser. Quand
vous allez commencer leur parler, vous en entendrez beaucoup sur les dcollages
davions, les atterrissages, les appareils en vol et le risque de collision, les avions qui
attendent la permission datterrir, etc. Pour trouver un ordre dans cette quantit
dinformation apparemment chaotique, nous devons bien commencer quelque part.
Laiguilleur et vous convenez que chaque appareil a un terrain daviation de dpart et
darrive. Nous avons donc un appareil, un dpart et une destination, comme indiqu
dans la figure ci-dessous.

14

OK, lavion dcolle dun endroit et touche le sol dans un autre. Mais que se passe-t-il
en lair ? Quel chemin de vol suit-il ? En vrit, nous nous intressons davantage ce
qui se passe une fois quil est en lair. Laiguilleur dit quon assigne chaque avion un
plan de vol qui est cens dcrire le voyage arien en entier. Lorsque vous entendez
parler de plan de vol, vous pouvez penser dans votre for intrieur quil sagit du
chemin suivi par lavion dans le ciel. En discutant plus avant, vous notez un mot
intressant : route. Ce mot capte votre attention immdiatement, et ce pour une bonne
raison. La route reprsente un concept important en matire de transport arien. Cest
ce que les avions font en volant, ils suivent une route. Il est vident que le dpart et la
destination de laronef sont aussi les points de dbut et de fin de la route. Donc au
lieu dassocier lappareil aux points de dpart et de destination, il semble plus naturel
de le relier une route, qui son tour est associe au dpart et la destination
correspondants.

En parlant avec laiguilleur des routes suivies par les avions, vous dcouvrez que la
route est en fait forme de petits segments qui, mis bout bout, constituent une sorte
de ligne tortueuse allant du dpart la destination. La ligne est cense passer par des
points fixes dtermins lavance. Donc, une route peut tre considre comme une
srie de positions conscutives. A ce niveau, vous ne voyez plus le dpart et la
destination comme les points terminaux de la route, mais juste comme deux positions
parmi dautres. Cest probablement assez diffrent de la faon dont les voit

15

laiguilleur, mais il sagit dune abstraction ncessaire qui sera utile plus tard. Les
changements rsultant de ces dcouvertes sont les suivants :

Le diagramme montre un autre lment : le fait que chaque position est un point de
lespace suivi par la route, et elle est exprime sous forme dun point en 3 dimensions.
Mais en parlant laiguilleur, vous allez dcouvrir quil ne le voit pas de la mme
manire. En fait, il voit la route comme une projection sur Terre du vol de lavion. Les
positions sont juste des points la surface de la Terre dtermins de manire unique
par leur latitude et leur longitude. Le diagramme correct est donc :

Que se passe-t-il ici en ralit ? Vous et les experts du domaine, vous tes en train de
parler, dchanger de la connaissance. Vous commencez poser des questions, et ils
vous rpondent. Ce faisant, ils font ressortir des concepts essentiels du domaine du
trafic arien. Il est possible que ces concepts sortent mal dgrossis et dsorganiss,
mais ils sont nanmoins essentiels pour comprendre le domaine. Il vous faut en
apprendre le plus possible sur le domaine de la part des experts. Et en glissant les
bonnes questions, en traitant linformation de la bonne manire, vous et les experts
allez commencer esquisser une vue du domaine, un modle du domaine. Cette vue

16

nest ni complte ni juste, mais cest le point de dpart dont vous avez besoin. Essayez
de comprendre les concepts essentiels du domaine.
Cest une partie importante du design. Dhabitude, de longues discussions ont lieu
entre les architectes logiciels ou les dveloppeurs et les experts du domaine. Les
spcialistes logiciels veulent extraire la connaissance des experts du domaine, et ils
doivent aussi la transformer en une forme utile. Arrivs un certain point, ils
pourraient avoir envie de crer un premier prototype pour voir comment a marche
ce moment-l. Ce faisant, il est possible quils rencontrent certains problmes dans
leur modle ou leur approche, et quils veuillent changer le modle. La communication
ne se fait pas seulement dans un sens, des experts du domaine vers larchitecte logiciel
puis vers les dveloppeurs. Il y a aussi des retours, qui aident crer un meilleur
modle ainsi quune comprhension plus claire et plus juste du domaine. Les experts
du domaine connaissent bien leur terrain dexpertise, mais ils organisent et utilisent
leur connaissance dune manire spcifique, qui nest pas toujours la bonne pour une
implmentation dans un systme logiciel. Lesprit danalyse du concepteur du logiciel
aide dnicher certains concepts-cls du domaine lors des discussions avec les
experts, et aide aussi construire une structure pour de futures discussions comme
nous le verrons au chapitre suivant. Nous, les spcialistes en logiciel (architectes
logiciels et dveloppeurs), et les experts du domaine, crons le modle du domaine
ensemble, et le modle est lendroit o ces deux champs dexpertise se rencontrent. Ce
processus peut sembler trs gourmand en temps, et cest le cas, mais cest comme a
quil doit tre, parce quau final le but du logiciel est de rsoudre des problmes mtier
dans un domaine de la vie relle, et il doit donc se fondre parfaitement dans le
domaine.

17

2
Le Langage omniprsent

Le besoin dun langage commun

Le chapitre prcdent a fait la dmonstration quil tait absolument ncessaire de
dvelopper un modle du domaine en faisant travailler les spcialistes informatique
avec les experts du domaine ; toutefois cette approche se heurte couramment
quelques difficults dues une barrire de communication initiale. Les dveloppeurs
ont la tte pleine de classes, de mthodes, dalgorithmes, de patterns, et ont tendance
toujours vouloir faire correspondre un concept de la vie relle un artefact de
programmation. Ils veulent voir les classes dobjets quils devront crer et les relations
entre elles quil faudra modliser. Ils pensent en termes dhritage, de polymorphisme,
dorient objet, etc. Et ils parlent comme a tout le temps. Et cest normal pour eux
dagir ainsi. Les dveloppeurs restent des dveloppeurs. Mais les experts du domaine
ne connaissent en gnral rien de tout cela. Ils nont aucune ide de ce que peuvent
tre des bibliothques logicielles, des frameworks, la persistance, et dans bien des cas
mme une base de donnes. Ils connaissent leur champ dexpertise particulier.
Dans lexemple de surveillance du trafic arien, les experts du domaine sy
connaissent en avions, en routes, en altitudes, longitudes et latitudes, ils maitrisent les
dviations par rapport litinraire normal, les trajectoires des avions. Et ils parlent de
ces choses dans leur propre jargon, ce qui parfois nest pas trs facile suivre pour
quelquun de lextrieur.
Pour surmonter la diffrence de style de communication, quand nous construisons le
modle, nous devons nous parler pour changer des ides sur le modle, sur les
lments impliqus dans le modle, la manire dont nous les relions, sur ce qui est
pertinent ou non. La communication ce niveau est primordiale pour la russite du
projet. Si quelquun dit quelque chose et que lautre ne comprend pas, ou pire encore,
comprend autre chose, quelles chances y-a-t-il pour que le projet aboutisse ?

18

Un projet se trouve face de srieux problmes lorsque les membres de lquipe ne

partagent pas un langage commun pour discuter du domaine. Les experts du domaine
utilisent leur jargon tandis que les membres de lquipe technique ont leur propre
langage prvu pour discuter du domaine en termes de conception.
La terminologie des discussions de tous les jours est dconnecte de la terminologie
embarque dans le code (qui est finalement le produit le plus important dun projet
informatique). Et mme un individu identique utilise un langage diffrent loral et
lcrit, si bien que les expressions du domaine les plus perspicaces mergent souvent
dans une forme transitoire qui nest jamais capture dans le code ni mme dans les
documents crits.
Lors de ces sances de discussion, on utilise souvent la traduction pour faire
comprendre aux autres le sens de certains concepts. Les dveloppeurs peuvent essayer
dexpliquer quelques design patterns en utilisant un langage de non-spcialiste, parfois
sans succs. Les experts du domaine vont sefforcer de faire passer certaines de leurs
ides en crant probablement un nouveau jargon. Au cours de ce processus, la
communication souffre, et ce genre de traduction ne favorise pas le mcanisme de
construction de la connaissance.
Nous avons tendance utiliser nos propres dialectes pendant ces sances de
conception, mais aucun de ces dialectes ne peut tre un langage commun parce
quaucun ne sert les besoins de tout le monde.
Nous avons rsolument besoin de parler le mme langage quand nous nous runissons
pour parler du modle et le dfinir. Quel langage cela va-t-il tre ? Celui des
dveloppeurs ? Celui des experts du domaine ? Quelque chose entre les deux ?
Un des principes de base de Domain-Driven Design est dutiliser un langage bas sur
le modle. Puisque le modle est le terrain dentente, lendroit o le logiciel rencontre
le domaine, il est justifi de lutiliser comme terrain de construction de ce langage.
Utilisez le modle comme colonne vertbrale dun langage. Demandez ce que
lquipe utilise le langage assidment dans tous les changes, et aussi dans le code.
Quand elle partage la connaissance et dessine les contours du modle, lquipe utilise
lexpression orale, crite et des diagrammes. Assurez-vous que le langage apparaisse
en continu dans toutes les formes de communication utilises par lquipe ; cest en
cela que le langage est appel Langage omniprsent.
Le Langage omniprsent fait le lien entre toutes les parties du design, et jette les
fondements dun bon fonctionnement de lquipe de conception. Cela prend des mois
et mme des annes pour que puisse prendre forme le design de projets de grande
envergure. Les membres de lquipe dcouvrent que certains des concepts initiaux
taient inexacts ou utiliss mal propos, ou ils dcouvrent de nouveaux lments du
19

design qui ncessitent dtre examins et insrs dans la conception globale. Tout cela
nest pas possible sans un langage commun.
Les langages napparaissent pas du jour au lendemain. Ca demande un srieux travail
et beaucoup de concentration pour sassurer que les lments cls du langage voient le
jour. Il nous faut trouver ces concepts cls qui dfinissent le domaine et la conception,
trouver les mots qui leur correspondent, et commencer les utiliser. Certains dentre
eux sont faciles reprer, mais il y en a des plus ardus.
Eliminez les difficults en testant des expressions diffrentes, qui refltent des modles
alternatifs. Puis refactorez le code, en renommant les classes, les mthodes et les
modules pour vous conformer au nouveau modle. Trouvez une solution au flou
entourant certains termes grce la conversation, exactement de la mme manire
quon saccorde sur la signification de mots ordinaires.
Construire un langage comme cela conduit un rsultat manifeste : le modle et le
langage sont fortement interconnects lun lautre. Un changement dans le langage
doit devenir un changement dans le modle.
Les experts du domaine devraient sopposer des termes et des structures maladroites
ou inaptes vhiculer la comprhension du domaine. Sil y a des choses que les
experts du domaine ne comprennent pas dans le modle ou le langage, alors il est plus
que probable que quelque chose cloche dans ce dernier. Dun autre ct, les
dveloppeurs devraient surveiller les ambiguts et les incohrences qui auront
tendance apparaitre dans la conception.

Crer le Langage omniprsent

Comment pouvons-nous commencer crer un langage ? Voici un dialogue
hypothtique entre un dveloppeur logiciel et un expert du domaine dans le projet de
surveillance du trafic arien. Faites bien attention aux mots qui apparaissent en gras.
Dveloppeur : Nous voulons surveiller le trafic arien. Par o est-ce quon
commence ?
Expert : Commenons par la base. Tout ce trafic est compos davions. Chaque avion
dcolle dun lieu de dpart, et atterrit sur un lieu de destination.
Dveloppeur : Ca, cest simple. Une fois en vol, lavion peut opter pour nimporte
quel chemin arien choisi par les pilotes ? Est-ce que cest de leur ressort de dcider la
voie prendre, du moment quils atteignent la destination ?

20

Expert : Oh, non. Les pilotes reoivent une route suivre. Et ils doivent rester aussi
proches que possible de cette route.
Dveloppeur : Je vois cette route comme un chemin en 3D dans le ciel. Si nous
utilisons un systme de coordonnes cartsiennes, alors la route est simplement une
srie de points 3D.
Expert : Je ne pense pas. Nous ne voyons pas la route comme a. La route est en fait
la projection sur le sol du chemin arien attendu de lappareil. La route passe par une
srie de points au sol dtermins par leur latitude et longitude.
Dveloppeur : OK, appelons alors chacun de ces points une position, puisque cest un
point fixe la surface de la Terre. Ensuite on utilisera une srie de points 2D pour
dcrire le chemin. Et au passage, le dpart et la destination sont simplement des
positions. On ne devrait pas les considrer comme des concepts part. La route atteint
sa destination comme elle atteint nimporte quelle autre position. Lavion doit suivre
la route, mais est-ce que a veut dire quil peut voler aussi haut ou aussi bas quil
veut ?
Expert : Non. Laltitude quun appareil doit avoir un moment donn est aussi tablie
dans le plan de vol.
Dveloppeur : Plan de vol ? Quest-ce que cest ?
Expert : Avant de quitter laroport, les pilotes reoivent un plan de vol dtaill qui
comprend toutes sortes dinformation sur le vol : la route, laltitude de croisire, la
vitesse de croisire, le type dappareil, et mme des informations sur les membres de
lquipage.
Dveloppeur : Hmm, le plan de vol ma lair assez important. On va linclure dans le
modle.

21

Dveloppeur : Voil qui est mieux. Maintenant que je le vois, je ralise quelque
chose. Quand on surveille le trafic arien, en fait on ne sintresse pas aux avions euxmmes, sils sont blancs ou bleus, ou si cest des Boeing ou des Airbus. On sintresse
leur vol. Cest a quon trace et quon mesure, en ralit. Je pense quon devrait
changer le modle un petit peu pour le rendre plus prcis.
Remarquez comment cette quipe, en parlant du domaine de la surveillance du trafic
arien autour de son modle naissant, est lentement en train de crer un langage
constitu des mots en gras. Notez aussi la manire dont ce langage change le modle !
Cependant, dans la vie relle ce dialogue est beaucoup plus bavard, et les gens parlent
trs souvent des choses indirectement, entrent trop dans les dtails, ou choisissent de
mauvais concepts ; ceci peut rendre la formation du langage trs difficile. Pour
commencer attaquer ce problme, tous les membres de lquipe devraient tre
conscients du besoin de crer un langage commun et on devrait leur rappeler de rester
concentrs sur lessentiel, et dutiliser le langage chaque fois que cest ncessaire.
Nous devrions utiliser notre jargon aussi peu que possible pendant ce genre de sance,
et on devrait se servir du Langage omniprsent car il nous aide communiquer
clairement et prcisment.

22

Il est aussi fortement recommand aux dveloppeurs dimplmenter les concepts

principaux du modle dans le code. On pourrait crire une classe pour Route et une
autre pour Position. La classe Position pourrait hriter dune classe Point2D, ou
pourrait contenir un Point2D comme attribut principal. Cela dpend dautres facteurs
dont nous discuterons plus tard. En crant des classes pour les concepts du modle
correspondants, nous faisons du mapping entre le modle et le code, et entre le langage
et le code. Cest trs utile car cela rend le code plus lisible, et en fait une reproduction
du modle. Le fait davoir un code qui exprime le modle porte ses fruits plus tard
dans le projet, lorsque le modle devient gros, et lorsque des changements dans le code
peuvent avoir des consquences indsirables si le code na pas t conu proprement.
Nous avons vu comment le langage est partag par lquipe entire, et aussi comment
il aide btir la connaissance et crer le modle. Que devrions-nous employer pour
communiquer le langage ? Simplement lexpression orale ? Nous avons utilis des
diagrammes. Quoi dautre ? De lcrit ?
Certains diront quUML est suffisamment bon pour construire un modle entirement
dessus. Et en effet, cest un trs bon outil pour coucher sur le papier des concepts cls
comme les classes, et pour exprimer les relations qui existent entre elles. Vous pouvez
dessiner trois ou quatre classes sur un calepin, crire leurs noms, et montrer leurs
liaisons. Cest trs simple pour tout le monde de suivre le cheminement de votre
pense, et lexpression graphique dune ide est facile comprendre. Tout le monde
partage instantanment la mme vision dun sujet donn, et il devient plus simple de

23

communiquer en se basant l-dessus. Quand de nouvelles ides apparaissent, le

diagramme est modifi pour reflter le changement conceptuel.
Les diagrammes UML sont trs utiles lorsque le nombre dlments en jeu est petit.
Mais de lUML, a peut pousser comme des champignons aprs une pluie dt. Que
faire quand on a des centaines de classes qui occupent une feuille de papier aussi
longue que le Mississipi ? Cest difficilement lisible mme par des spcialistes en
logiciel, sans parler des experts du domaine. Ils ny comprendront pas grand-chose
lorsque tout a enflera, et a enfle mme dans des projets de taille moyenne.
De plus, UML sait bien exprimer les classes, leurs attributs et leurs relations. Mais les
comportements des classes et les contraintes ne se formulent pas aussi facilement.
Pour cela, UML a recours du texte plac sous forme de notes dans le diagramme.
Donc UML ne sait pas vhiculer deux aspects importants dun modle : la
signification des concepts quil reprsente et ce que lobjet est cens faire. Mais a ne
fait rien, puisque nous pouvons y ajouter dautres outils de communication.
On peut utiliser des documents. Une manire conseille de communiquer le modle est
de faire de petits diagrammes, chacun contenant un sous-ensemble du modle. Ces
diagrammes contiendront plusieurs classes et leurs relations. Cela regroupe dj une
bonne partie des concepts en jeu. Puis nous pouvons ajouter du texte au diagramme.
Le texte va expliquer le comportement et les contraintes que le diagramme ne peut pas
reprsenter. Chaque sous-section comme celle-l tente dexpliquer un aspect important
du domaine, elle braque un projecteur pour clairer une partie du domaine.
Ces documents peuvent mme tre dessins main leve, car a transmet limpression
quils sont temporaires, et pourraient tre changs dans un futur proche, ce qui est vrai
parce que le modle est modifi de nombreuses fois au dbut avant datteindre un tat
plus stable.
Il pourrait tre tentant dessayer de crer un grand diagramme couvrant le modle tout
entier. Toutefois, la plupart du temps de tels diagrammes sont presque impossibles
constituer. Et qui plus est, mme si vous parvenez fabriquer ce diagramme unique, il
sera si encombr quil ne vhiculera pas la comprhension mieux que le ferait
lassortiment de petits diagrammes.
Faites attention aux longs documents. Ils prennent beaucoup de temps crire, et
peuvent devenir obsoltes avant dtre termins. Les documents doivent tre
synchroniss avec le modle. De vieux documents qui utilisent le mauvais langage et
ne refltent pas le modle ne sont pas trs utiles. Essayez de les viter quand cest
possible.
Il est aussi possible de communiquer en utilisant du code. La communaut XP plaide
abondamment pour cette approche. Du code bien crit peut tre trs communicatif.
24

Bien que le comportement exprim par une mthode soit clair, le nom de la mthode
est-il aussi clair que son corps ? Les assertions dun test parlent delles-mmes, mais
quen est-il du nom des variables et de la structure gnrale du code ? Donnent-ils
haut et fort une version intgrale des faits ? Du code qui fonctionnellement fait ce quil
y a faire, nexprime pas forcment ce quil y a exprimer. Ecrire un modle en code
est trs difficile.
Il y a dautres faons de communiquer lors de la conception. Ce nest pas lobjectif de
ce livre de les prsenter toutes. Une chose est nanmoins claire : lquipe de
conception, compose darchitectes logiciels, de dveloppeurs et dexperts du
domaine, a besoin dun langage qui unifie leurs actions, et les aide crer un modle
et lexprimer dans du code.

25

3
Conception dirige par le Modle
Les chapitres prcdents soulignaient limportance dune approche du dveloppement
logiciel centre sur le domaine mtier. Nous avons dit quil tait fondamentalement
important de crer un modle profondment enracin dans le domaine, et qui reflte
les concepts essentiels du domaine avec une grande prcision. Le Langage
omniprsent devrait tre pratiqu pleinement tout au long du processus de
modlisation de manire faciliter la communication entre les spcialistes logiciels et
les experts du domaine, et dcouvrir les concepts cls du domaine qui devront tre
utiliss dans le modle. Lobjectif de ce processus de modlisation est de crer un bon
modle. Ltape suivante est limplmentation du modle en code. Cest une phase
tout aussi importante du processus de dveloppement logiciel. Si vous avez cr un
excellent modle mais que vous chouez le transfrer correctement dans le code, il
en rsultera en un logiciel de qualit discutable.
Il arrive que les analystes logiciels travaillent avec les experts du domaine mtier
pendant des mois, dcouvrent les lments fondamentaux du domaine, mettent en
lumire leurs relations, et crent un modle correct, qui capture le domaine de faon
exacte. Puis le modle est pass aux dveloppeurs. Ce qui peut se produire, cest que
les dveloppeurs regardent le modle et dcouvrent que certains des concepts ou
relations qui sy trouvent ne peuvent pas tre correctement exprims par du code. Ils
utilisent donc le modle original comme source dinspiration, mais ils crent leur
propre conception qui emprunte des ides du modle, et y ajoutent certaines de leurs
propres ides. Le processus de dveloppement se poursuit, et davantage de classes sont
ajoutes au code, creusant lcart entre le modle dorigine et limplmentation finale.
On nest plus assur davoir le bon rsultat la fin. Il se peut que de bons
dveloppeurs mettent sur pied un produit qui marche, mais rsistera-t-il lpreuve du
temps ? Sera-t-il facilement extensible ? Sera-t-il aisment maintenable ?
Tout domaine peut tre exprim travers de nombreux modles, et tout modle peut se
traduire de diverses manires dans le code. A chaque problme particulier il peut y

26

avoir plus dune solution. Laquelle choisir ? Avoir un modle analytiquement correct
ne signifie pas quil puisse tre directement exprim en code. A ce stade, la question
principale est la suivante : comment allons-nous aborder la transition du modle vers
le code ?
Parmi les techniques de conception parfois prconises, il y a ce quon appelle le
modle danalyse, qui est vu comme tant spar du design du code et gnralement
fait par des personnes diffrentes. Le modle danalyse est le produit de lanalyse du
domaine mtier, il se traduit par un modle qui ne prend pas en compte le logiciel
utilis dans limplmentation. On se sert de ce genre de modle pour comprendre le
domaine. Un certain niveau de connaissance est bti, et le modle rsultant peut tre
analytiquement correct. Le logiciel nest pas pris en compte cette tape car on le
considre comme un facteur de confusion. Ce modle parvient ensuite aux
dveloppeurs qui sont censs faire la conception. Comme le modle na pas t
construit avec des principes de conception en tte, il ne servira probablement pas bien
cet objectif. Les dveloppeurs devront ladapter, ou crer une conception spare. Et il
cesse dy avoir un mappage entre le modle et le code. Rsultat, les modles danalyse
sont rapidement abandonns aprs quon ait commenc coder.
Un des principaux problmes de cette approche est que les analystes ne peuvent pas
prvoir certains dfauts de leur modle, ni toutes les subtilits du domaine. Il arrive
que les analystes soient alls trop dans les dtails de certains composants du modle, et
nen aient pas assez prcis dautres. On dcouvre des dtails trs importants pendant
le processus de conception et dimplmentation. Il peut savrer quun modle fidle
au domaine ait de srieux problmes avec la persistance des objets, ou un
comportement inacceptable en termes de performances. Les dveloppeurs seront
obligs de prendre des dcisions par eux-mmes, et apporteront des modifications la
conception pour rsoudre un problme rel qui navait pas t pris en compte lorsque
le modle avait t cr. Ils produisent une conception qui sloigne du modle, le
rendant moins pertinent.
Si les analystes travaillent indpendamment, ils vont finalement crer un modle.
Quand ce modle est transmis aux concepteurs, une partie de la connaissance du
domaine et du modle dtenue par les analystes est perdue. Mme si on peut exprimer
le modle travers des diagrammes et des documents crits, il y a des chances pour
que les concepteurs ne saisissent pas tout le sens du modle, les relations entre certains
objets, ou leur comportement. Il y a des dtails dun modle qui ne sexpriment pas
facilement sous forme de diagramme, et ne peuvent pas tre prsents dans leur
intgralit mme dans des documents crits. Il ne sera pas facile pour les dveloppeurs
de les saisir. Dans certains cas ils feront des suppositions sur le comportement voulu,
et il est possible quils fassent les mauvaises, dbouchant sur un fonctionnement
incorrect du programme.

27

Les analystes tiennent leurs propres runions fermes o lon dbat de beaucoup de
choses autour du domaine, et o il y a beaucoup de partage de connaissance. Ils crent
un modle cens contenir toute linformation sous forme condense, et les
dveloppeurs doivent en assimiler lintgralit en lisant les documents quon leur
donne. Ce serait bien plus productif si les dveloppeurs pouvaient se joindre aux
runions des analystes et ainsi accder une vue claire, complte du domaine et du
modle avant de commencer concevoir le code.
Une meilleure approche est de lier troitement modlisation du domaine et conception.
Le modle devrait tre construit en gardant un il sur les considrations logicielles et
conceptuelles. On devrait intgrer les dveloppeurs dans le processus de modlisation.
Lide importante est de choisir un modle qui puisse tre exprim convenablement
dans du logiciel, pour que le processus de conception soit direct et bas sur le modle.
Le fait de coupler troitement le code un modle sous-jacent donne du sens au code
et rend le modle pertinent.
Impliquer les dveloppeurs permet davoir du feedback. Cela permet de sassurer que
le modle peut tre implment en logiciel. Si quelque chose ne va pas, le problme
est identifi un stade prcoce, et on peut facilement le corriger.
Ceux qui crivent le code devraient trs bien connaitre le modle, et se sentir
responsables de son intgrit. Ils devraient raliser quun changement dans le code
implique un changement dans le modle ; sans quoi ils refactoreront le code jusquau
point o il aura cess dexprimer le modle original. Si lanalyste est dissoci du
processus dimplmentation, il perdra rapidement toute proccupation concernant les
limites introduites par le dveloppement. Le rsultat de cela sera un modle qui nest
pas pragmatique.
Toute personne technique qui contribue llaboration du modle doit passer du temps
manipuler le code, quel que soit le rle premier quil ou elle joue dans le projet.
Toute personne ayant la responsabilit de modifier du code doit apprendre exprimer
un modle travers le code. Chaque dveloppeur doit tre impliqu, un niveau ou un
autre, dans la discussion autour du modle et tre en contact avec les experts du
domaine. Ceux qui contribuent de manire non technique doivent engager
consciemment, avec ceux qui manipulent le code, un change dynamique dides sur
le modle travers le Langage omniprsent.
Si on ne peut pas faire la correspondance entre la conception, ou une partie centrale de
celle-ci, et le modle du domaine, ce modle naura que peu de valeur, et la justesse du
logiciel sera suspecte. Qui plus est, les mappages complexes entre modles et
fonctions conceptuelles seront difficiles comprendre, et, en pratique, impossibles
maintenir lorsque la conception changera. Un foss mortel souvrira entre lanalyse et

28

la conception si bien que le discernement quon gagnera pratiquer lune des deux
activits ne nourrira pas lautre.
Concevez toute portion du systme logiciel de telle sorte quelle reflte le modle du
domaine de manire trs littrale, de cette manire le mappage sera vident. Revisitez
ensuite le modle et modifiez-le pour quil puisse tre implmentable plus
naturellement dans le logiciel, mme si votre but reste une reprsentation fine du
domaine. Exigez un modle unique qui serve bien ces deux objectifs, en plus de
supporter un Langage omniprsent fluide.
Puisez dans le modle la terminologie utiliser pour la conception et laffectation des
responsabilits de base. Le code devient une expression du modle, donc il se peut
quun changement apport au code se traduise en un changement du modle. Son effet
doit se propager en consquence travers le reste des activits du projet.
Lier troitement limplmentation un modle ncessite gnralement des langages et
outils de dveloppement qui supportent un paradigme de modlisation, comme par
exemple la programmation oriente objet.
La programmation oriente objet convient bien limplmentation de modle car ils
sont tous deux bass sur le mme paradigme. La programmation oriente objet prvoit
des classes dobjets et leurs associations, des instances dobjets, et lenvoi de messages
entre eux. Les langages de POO rendent possible la cration de mappages directs entre
les objets du modle avec leurs relations, et leurs quivalents en programmation.
Les langages procduraux offrent un support limit de la conception dirige par le
Modle. Ces langages ne proposent pas les briques ncessaires pour implmenter les
composants-cls dun modle. Certains disent quon peut faire de la POO avec un
langage procdural comme le C, et en effet, une partie des fonctionnalits peuvent tre
reproduites de cette faon. Les objets peuvent tre simuls par des structures de
donnes. Ce genre de structure ne contient pas le comportement de lobjet, il faut le
rajouter sparment dans des fonctions. La signification de telles donnes existe
seulement dans lesprit du dveloppeur, car le code lui-mme nest pas explicite. Un
programme crit dans un langage procdural est gnralement peru comme un
ensemble de fonctions, lune appelant lautre, qui travaillent ensemble pour atteindre
un rsultat donn. Un programme comme cela est incapable dencapsuler facilement
des connexions conceptuelles, ce qui rend le mappage entre le domaine et le code
difficile raliser.
Certains domaines spcifiques, comme les mathmatiques, sont facilement
modlisables et implmentables en programmation procdurale, car bien des thories
mathmatiques se traitent facilement en utilisant des appels de fonctions et des
structures de donnes, en effet il sagit avant tout de calculs. Il y a des domaines plus

29

complexes qui ne sont pas juste une suite de concepts abstraits impliquant des calculs,
et ne peuvent pas tre rduits un jeu dalgorithmes, cest pourquoi les langages
procduraux sont bien en peine dexprimer ces modles. Pour cette raison, la
programmation procdurale nest pas recommande en conception dirige par le
modle.

Les blocs de construction dune conception

oriente Modle
Les sections suivantes de ce chapitre exposent les principaux patterns utiliss en
conception dirige par le modle. Le diagramme qui suit est une carte des patterns
prsents et des relations qui existent entre eux.

Larchitecture en couches

30

Lorsquon cre une application logicielle, une grande part de lapplication nest pas
relie directement au domaine, mais fait partie de linfrastructure ou sert le logiciel luimme. Il peut arriver, et cest justifi, que la partie domaine dune application soit
assez rduite compare au reste, puisquune application typique contient beaucoup de
code li laccs la base de donnes, laccs aux fichiers ou au rseau, aux
interfaces utilisateur, etc.
Dans un programme orient objet, le code de lIHM, de la base de donnes, et dautres
modules de support se retrouve souvent directement crit dans les objets mtier. Une
partie de la logique mtier est quant elle embarque dans le comportement des
composants dIHM et des scripts de base de donnes. Cela arrive parfois car cest la
faon la plus simple de faire marcher les choses rapidement.
Cependant, quand du code relatif au domaine est mlang aux autres couches, il
devient trs difficile de garder un il dessus et de sen souvenir. Des changements
superficiels dans lIHM peuvent en ralit modifier la logique mtier. Il se peut que
changer une rgle mtier exige une fouille mticuleuse dans code de lIHM, dans code
de la base de donnes, ou dautres lments du programme. Implmenter des objets
orients modle cohrents devient difficilement praticable. Les tests automatiss
deviennent peu commodes. Avec toute la technologie et toute la logique incluse dans
chaque activit, on doit garder un programme trs simple ou il devient impossible
comprendre.
Pour cette raison, vous devez partitionner un programme complexe en COUCHES.
Imaginez une conception au sein de chaque COUCHE qui soit cohrente et ne dpende
que des couches en-dessous. Suivez les modles darchitecture standard pour fournir
31

un couplage faible aux couches du dessus. Concentrez tout le code li au modle du

domaine dans une couche et isolez-le du code dinterface utilisateur, applicatif, et
dinfrastructure. Les objets du domaine, librs de la responsabilit de safficher euxmmes, de se stocker eux-mmes, de grer les tches applicatives, et ainsi de suite,
pourront se concentrer sur lexpression du modle du domaine. Cela permet un
modle dvoluer jusqu tre assez riche et assez clair pour capturer la connaissance
essentielle du mtier et la mettre en uvre.
Une solution architecturale courante pour les conceptions diriges par le domaine
contient quatre couches conceptuelles :
Interface utilisateur
(couche de
prsentation)

Responsable de la prsentation de linformation lutilisateur et

de linterprtation des commandes de lutilisateur.

Couche application

Cest une couche fine qui coordonne lactivit de lapplication.

Elle ne contient pas de logique mtier. Elle ne recle pas ltat
des objets mtier, mais elle peut dtenir ltat de la progression
dune tche applicative.

Couche domaine

Cette couche contient les informations sur le domaine. Cest le

cur du logiciel mtier. Ltat des objets mtier est renferm ici.
La persistance des objets mtier et peut-tre aussi leur tat est
dlgu la couche infrastructure.

Couche infrastructure

Cette couche agit comme une bibliothque de soutien pour

toutes les autres couches. Elle fournit la communication entre les
couches, implmente la persistance des objets mtier, contient
les bibliothques auxiliaires de la couche dinterface utilisateur,
etc.

Il est important de scinder une application en couches spares, et dtablir des rgles
dinteraction entre elles. Si le code nest pas clairement spar en couches, il deviendra
vite si enchevtr quil sera trs difficile de grer les changements. Une simple
modification dans une section du code pourra avoir des rsultats inattendus et
indsirables dans dautres sections. La couche domaine devrait se concentrer sur les
enjeux du cur du domaine. Elle ne devrait pas tre implique dans des activits
dinfrastructure. LIHM ne devrait tre troitement lie ni la logique mtier, ni aux
tches qui incombent normalement la couche infrastructure. Une couche application
est ncessaire dans beaucoup de cas : il faut quil y ait un gestionnaire au-dessus de la
logique mtier qui supervise et coordonne lactivit densemble de lapplication.
Par exemple, une interaction typique entre application, domaine et infrastructure
pourrait ressembler ceci : lutilisateur veut rserver une route pour un vol, et

32

demande au service application dans la couche applicative de le faire. Le tiers

application rcupre les objets mtier appropris auprs de linfrastructure et invoque
les mthodes adquates dessus, par exemple pour vrifier les marges de scurit par
rapport aux autres vols dj rservs. Une fois que les objets du domaine ont fait toutes
les vrifications et mis jour leur statut dcid , le service application persiste les
objets en passant par linfrastructure.

Les Entits
Il y a une catgorie dobjets dont lidentit semble rester la mme au fil des tats du
logiciel. Chez ces objets, ce ne sont pas les attributs qui comptent, mais une ligne de
continuit et didentit qui stend sur la dure de vie dun systme et peut sallonger
au-del. Ces objets sont appels Entits.
Les langages de POO conservent des instances dobjets en mmoire, et ils associent
une rfrence ou une adresse mmoire chaque objet. Cette rfrence est unique un
objet un instant donn, mais il ny a aucune garantie quelle le reste indfiniment. En
fait, cest plutt le contraire. Les objets sont constamment enlevs et remis dans la
mmoire, ils sont srialiss et envoys travers le rseau pour tre recrs lautre
bout, ou ils sont dtruits. Cette rfrence, qui fait office didentit pour
lenvironnement dexcution du programme, nest pas lidentit dont nous parlons. Si
une classe porte une information sur la mto, comme la temprature, il est tout fait
possible davoir deux instances distinctes de cette classe qui contiennent toutes deux la
mme valeur. Les objets sont parfaitement gaux et interchangeables, mais ils ont des
rfrences diffrentes. Ce ne sont pas des entits.
Si nous devions implmenter le concept dune personne utilisant un programme
logiciel, nous crerions probablement une classe Personne avec une srie dattributs :
nom, date de naissance, lieu de naissance, etc. Est-ce quun de ces attributs constitue
lidentit de la personne ? Le nom ne peut pas tre lidentit parce quil peut y avoir
dautres gens qui sappellent pareil. On ne pourrait pas faire la distinction entre deux
personnes homonymes, si on devait seulement prendre en compte leur nom. Nous ne
pouvons pas non plus utiliser la date de naissance, parce quil y a beaucoup de gens
ns le mme jour. Il en va de mme pour lieu de naissance. Un objet doit se distinguer
des autres mme sils peuvent avoir les mmes attributs. Une confusion didentit peut
conduire une corruption des donnes.
Considrons lexemple dun systme de comptes bancaires. Chaque compte a son
propre numro. Un compte peut tre prcisment identifi par son numro. Ce numro
reste inchang tout au long de la vie du systme, et assure la continuit. Le numro de
compte peut exister en tant quobjet en mmoire, ou il peut tre dtruit de la mmoire
33

et envoy la base de donnes. Il peut aussi tre archiv quand le compte est ferm,
mais il existe toujours quelque part du moment quon a un intrt le garder sous le
coude. Peu importe la reprsentation qui en est faite, le numro reste le mme.
Donc, implmenter des entits dans le logiciel revient crer de lidentit. Pour une
personne a peut tre une combinaison dattributs : nom, date de naissance, lieu de
naissance, nom des parents et adresse actuelle. Le numro de scurit sociale est aussi
utilis aux Etats-Unis pour crer lidentit. Pour un compte bancaire, le numro de
compte semble suffire. Gnralement, lidentit est un attribut de lobjet, une
combinaison dattributs, un attribut spcialement cr pour prserver et exprimer
lidentit, ou mme un comportement. Il est important que deux objets avec des
identits diffrentes soient facilement distingus par le systme, et que deux objets de
mme identit soient considrs comme les mmes. Si cette condition nest pas
satisfaite, alors le systme entier peut devenir corrompu.
Il y a diffrentes manires de crer une identit unique pour chaque objet. LID peut
tre gnr automatiquement par un module, et utilis en interne dans le logiciel sans
tre rendu visible pour lutilisateur. Ca peut tre une cl primaire dans une table de la
base de donnes, qui est certifie unique dans la base. Lorsque lobjet est pris dans la
base, son ID est rcupr et recr en mmoire. LID peut aussi tre cr par
lutilisateur comme cest le cas avec les codes associs aux aroports. Chaque aroport
a un identifiant chane de caractres unique qui est reconnu internationalement et
utilis par les agences de voyages du monde entier pour identifier les aroports dans la
programmation de leurs voyages. Une autre solution est dutiliser les attributs de
lobjet pour crer lID, et quand a ne suffit pas, un autre attribut peut tre ajout pour
aider identifier lobjet en question.
Lorsquun objet se distingue par son identit plutt que par ses attributs, faites de cela
un lment primordial de sa dfinition dans le modle. Gardez une dfinition de la
classe simple et focalise sur la continuit du cycle de vie et lidentit. Dfinissez une
faon de distinguer chaque objet quelle que soit sa forme ou son historique. Restez
vigilant par rapport aux spcifications qui demandent retrouver des objets par leurs
attributs. Dfinissez une opration qui garantit la production dun rsultat unique pour
chaque objet, si possible en y rattachant un symbole qui est garanti unique. Ce moyen
didentification peut venir de lextrieur, ou a peut tre un identifiant arbitraire cr
par et pour le systme, mais il doit correspondre aux distinctions didentit dans le
modle. Le modle doit dfinir ce que signifie tre la mme chose .
Les entits sont des objets importants dun modle du domaine, et elles devraient tre
examines ds le dbut du processus de modlisation. Il est aussi important de
dterminer si un objet doit tre une entit ou non, cest ce dont il est question dans le
pattern suivant.

34

Les Objets-Valeurs
Nous avons parl des entits et de limportance de les reconnaitre tt dans la phase de
modlisation. Les entits sont des objets ncessaires dans un modle du domaine.
Devons-nous faire de tous les objets des entits ? Chaque objet doit-il avoir une
identit ?
Il pourrait tre tentant de faire de tous les objets des entits. Les entits peuvent tre
suivies la trace. Mais crer et tracer lidentit a un cot. On doit sassurer que chaque
instance a son identit unique, et tiqueter les identits nest pas simple. Dcider ce qui
constitue une identit demande une rflexion longue et minutieuse, car une mauvaise
dcision mnerait des objets de mme identit, ce quon ne souhaite pas. Il y a aussi
des rpercussions sur les performances dans le fait de faire de tous les objets des
entits. Il faut quil y ait une instance pour chaque objet. Si Client est un objet entit,
alors une instance de cet objet, qui reprsente un client particulier dune banque, ne
peut pas tre rutilise pour des oprations sur des comptes correspondant dautres
clients. La consquence est quune telle instance doit tre cre pour chaque client.
Cela peut avoir comme rsultat une dgradation des performances du systme
lorsquon a affaire des milliers dinstances.
Considrons lexemple dune application de dessin. On prsente lutilisateur un
canevas, et il peut y dessiner tous les points et lignes de lpaisseur, du style et de la
couleur quil souhaite. Il est utile de crer une classe dobjets nomme Point, et le
programme pourrait crer une instance de cette classe pour chaque point sur le
canevas. Un point comme celui-l contiendrait deux attributs associs ses
coordonnes sur lcran ou dans le canevas. Est-il ncessaire de considrer chaque
point comme ayant une identit ? Est-ce quil possde une continuit ? Il semble que la
seule chose qui compte chez un tel objet, ce sont ses coordonnes.
Il y a des cas o on a purement besoin de stocker des attributs dun lment du
domaine. Ce qui nous intresse nest pas de savoir de quel objet il sagit, mais quels
attributs il a. Un objet qui est utilis pour dcrire certains aspects dun domaine et qui
na pas didentit, est appel Objet-Valeur.
Il est ncessaire de distinguer les Objets Entits des Objets-Valeurs. Ca ne sert rien
de faire de tous les objets des entits juste pour des raisons duniformit. En fait, il est
plutt recommand de choisir comme entits seulement les objets qui sont conformes
la dfinition dune entit. Et de faire du reste des objets des Objets-Valeurs. (Nous
prsenterons un autre type dobjet dans la section suivante, mais supposons pour
linstant que nous avons seulement des objets entits et des objets-valeurs.) Ca va
simplifier la conception, et il y aura dautres consquences positives.

35

Nayant pas didentit, les Objets-Valeurs peuvent facilement tre crs et jets.
Personne na se soucier de leur crer une identit, et le garbage collector rgle son
compte lobjet quand il nest plus rfrenc par aucun autre objet. Ca simplifie
beaucoup le design.
Il est fortement recommand que les objets-valeurs soient immuables. Ils sont crs
laide dun constructeur, et jamais modifis au cours de leur vie. Lorsque vous voulez
une valeur diffrente pour lobjet, vous en crez tout simplement un autre. Ceci a des
consquences importantes sur la conception. Etant immuables, et nayant pas
didentit, les Objets-Valeurs peuvent tre partags. Ca peut savrer obligatoire dans
certains designs. Les objets immuables sont partageables, avec dimportantes
retombes en termes de performances. Ils ont aussi un caractre dintgrit, au sens
intgrit des donnes. Imaginez ce que cela voudrait dire de partager un objet qui nest
pas immuable. Un systme de rservation de voyages en avion pourrait crer des
objets pour chaque vol. Un des attributs pourrait tre le code du vol. Un client rserve
un vol pour une destination donne. Un autre client veut rserver sur le mme vol. Le
systme choisit de rutiliser lobjet qui comporte le code du vol, parce quil sagit du
mme vol. Entretemps, le client change davis, et choisit de prendre un vol diffrent.
Le systme change le code du vol car il nest pas immuable. Rsultat, le code du vol
du premier client change aussi.
Il y a une rgle dor : si les Objets-Valeurs sont partageables, ils doivent tre
immuables. Les Objets-Valeurs devraient garder une certaine minceur et une certaine
simplicit. Lorsquun Objet-Valeur est demand par un tiers, il peut simplement tre
pass par valeur, ou on peut en crer une copie et lui donner. Faire une copie dun
Objet-Valeur est simple, et gnralement sans aucune consquence. Sil ny a pas
didentit, vous pouvez faire autant de copies que vous voulez, et toutes les dtruire si
ncessaire.

36

Les Objets-Valeurs peuvent contenir dautres Objets-Valeurs, ils peuvent mme

contenir des rfrences des Entits. Bien que les Objets-Valeurs soient simplement
utiliss pour contenir les attributs dun objet du domaine, a ne signifie pas quils
devraient comporter une longue liste de tous les attributs. Les attributs peuvent tre
regroups dans diffrents objets. Les attributs quon choisit pour constituer un ObjetValeur devraient former un tout conceptuel. A un client, on associe un nom, une rue,
une ville et un Etat. Cest mieux si les informations sur ladresse sont contenues dans
un objet spar, et lobjet client aura une rfrence cet objet. La rue, la ville et lEtat
devraient avoir leur propre objet, lAdresse, car ils ont conceptuellement leur place
ensemble, plutt qutre des attributs spars du client, comme indiqu dans le
diagramme ci-dessus.

Les Services
Quand on analyse le domaine et quon essaye de dterminer les principaux objets qui
le composent, on dcouvre que certains aspects du domaine ne se transposent pas
facilement en objets. On considre de manire gnrale que les objets ont des attributs,
un tat interne quils grent, et quils exposent un comportement. Lorsquon labore le
Langage omniprsent, les concepts cls du domaine sont introduits dans le langage, et
les noms de ce dernier sont facilement convertibles en objets. Les verbes du langage,
associs aux noms correspondants, viennent former une partie du comportement de ces
objets. Mais il y a certaines actions dans le domaine, certains verbes, qui ne semblent
appartenir aucun objet. Ils reprsentent un comportement important du domaine, ils
ne peuvent donc tre ngligs ou simplement incorpors dans des Entits ou des
Objets-Valeurs. Ajouter un tel comportement un objet le corromprait, le ferait

37

incarner une fonctionnalit qui ne lui appartient pas. Nanmoins, utilisant un langage
orient objet, nous sommes obligs demployer un objet cet effet. Il ne peut pas
simplement y avoir une fonction spare, toute seule. Elle doit tre rattache un
objet. Souvent, ce genre de comportement fonctionne travers plusieurs objets,
potentiellement de classes diffrentes. Par exemple, transfrer de largent dun compte
un autre : cette fonction devrait-elle se trouver dans le compte qui envoie ou dans le
compte qui reoit ? Lun et lautre semblent tout autant mal placs.
Lorsque ce genre de comportement est identifi dans le domaine, la meilleure mthode
est de le dclarer en tant que Service. Un tel objet na pas dtat interne, et son objectif
est simplement de fournir de la fonctionnalit au domaine. Lassistance fournie par un
Service peut tre non ngligeable, et un service peut regrouper des fonctionnalits
connexes qui servent aux Entits et aux Objets-Valeurs. Cest beaucoup mieux de
dclarer le Service explicitement, parce que cela cre une distinction claire dans le
domaine, a encapsule un concept. Mettre ce genre de fonctionnalit dans une Entit
ou un Objet-Valeur engendre de la confusion, car ce que ces objets reprsentent
napparaitra pas clairement.
Les services agissent comme des interfaces qui fournissent des oprations. Les
services sont courants dans les frameworks techniques, mais ils peuvent aussi tre
utiliss dans la couche domaine. Lintrt dun Service ne rside pas dans lobjet qui
rend le service, il est plutt li aux objets sur ou pour le compte desquels les oprations
sont effectues. Par consquent, il nest pas inhabituel quun Service devienne le point
de connexion de beaucoup dobjets. Cest une des raisons pour lesquelles un
comportement qui appartient naturellement un Service ne devrait pas tre inclus dans
les objets du domaine. Si on intgre une telle fonctionnalit dans les objets du
domaine, un rseau dassociations dense se cre entre eux et les objets bnficiaires
des oprations. Un degr lev de couplage entre de nombreux objets est le signe dun
pitre design parce que a rend le code difficile lire et comprendre, et, plus
important encore, a le rend difficile changer.
Un Service ne doit pas remplacer une opration qui appartient normalement aux objets
du domaine. On ne devrait pas crer un Service pour chaque opration dont on a
besoin. Mais lorsquil ressort quune telle opration est un concept important du
domaine, un Service doit tre cr pour a. Un service compte 3 caractristiques :
1. Lopration excute par le Service fait rfrence un concept du domaine qui
nappartient pas naturellement une Entit ou un Objet-Valeur.
2. Lopration effectue fait rfrence dautres objets du domaine.
3. Lopration na pas dtat.

38

Quand un processus ou une transformation significative du domaine nest pas la

responsabilit naturelle dune Entit ou dun Objet-Valeur, vous pouvez ajouter une
opration au modle sous la forme dune interface autonome dclare en tant que
Service. Dfinissez linterface dans des termes du langage du modle et assurez-vous
que le nom de lopration fait partie du Langage omniprsent. Faites en sorte que le
Service nait pas dtat.
Quand on utilise des Services, il est important de prserver lisolation de la couche
domaine. On peut facilement confondre les services qui appartiennent la couche du
domaine, et ceux qui appartiennent linfrastructure. Il peut aussi y avoir des services
dans la couche application, ce qui ajoute encore un niveau de complexit. Ces services
sont encore plus difficiles sparer de leurs homologues rsidant dans la couche
domaine. Au cours du travail sur le modle et pendant la phase de conception, on doit
sassurer que le niveau domaine reste isol des autres niveaux.
Les Services de lapplication et les Services du domaine sont gnralement tous deux
construits autour des Entits et des Valeurs du domaine, ils fournissent des
fonctionnalits qui sont directement relies ces objets. Dcider quelle couche un
Service appartient nest pas chose aise. Si lopration effectue appartient
conceptuellement la couche application, alors cest l quon devrait placer le Service.
Si lopration concerne des objets du domaine, si elle est strictement lie au domaine,
et rpond un besoin du domaine, alors elle devrait appartenir la couche domaine.
Considrons un exemple pratique, une application web de reporting. Les rapports
utilisent des donnes stockes dans une base, et ils sont gnrs partir de gabarits. Le
rsultat final est une page HTML prsente lutilisateur dans un navigateur web.
La couche dIHM est contenue dans des pages web et permet lutilisateur de se
connecter, de choisir le rapport souhait et cliquer sur un bouton pour le lancer. La
couche application est une couche fine qui se trouve entre linterface utilisateur, le
domaine et linfrastructure. Elle interagit avec linfrastructure de la base de donnes
pendant les oprations de connexion, et avec la couche domaine lorsquelle a besoin de
crer des rapports. La couche domaine va contenir le cur du domaine, les objets
directement relis aux rapports. Rapport et Gabarit sont deux de ces objets, sur
lesquels sont bass les rapports. La couche infrastructure assurera laccs la base de
donnes et aux fichiers.
Quand un utilisateur slectionne un rapport crer, il slectionne en ralit le nom
dun rapport dans une liste de noms. Cest le reportID, une chane de caractres.
Dautres paramtres sont passs, comme les lments afficher dans le rapport et
lintervalle de temps des donnes quil contient. Mais nous parlerons seulement du
reportID pour plus de simplicit. Ce nom est pass par le biais de la couche application
la couche domaine. Etant donn le nom, la couche domaine est responsable de la
39

cration et du retour du rapport. Puisque les rapports sont bass sur des gabarits, on
pourrait crer un Service, dont le but serait dobtenir le gabarit qui correspond un
reportID. Ce gabarit est stock dans un fichier ou en base de donnes. Lobjet Rapport
lui-mme nest pas lendroit appropri pour mettre une telle opration. Elle
nappartient pas lobjet Gabarit non plus. Donc on cre un Service part dont
lobjectif est de rcuprer le gabarit dun rapport en se basant sur lID du rapport. Ce
serait un service situ dans la couche du domaine. Il se servirait de linfrastructure
fichier pour aller chercher le gabarit sur le disque.

Les Modules
Dans une application vaste et complexe, le modle a tendance devenir de plus en
plus gros. Le modle atteint un point ou il est difficile de parler de lui dans sa
globalit, et o il devient compliqu de comprendre les relations et interactions entre
ses diffrentes parties. Cest la raison pour laquelle il est ncessaire dorganiser le
modle en modules. Les modules sont utiliss comme mthode dorganisation des
concepts et tches connexes en vue de rduire la complexit.
Les modules sont largement utiliss dans la plupart des projets. Il est plus facile de
saisir le tableau densemble dun gros modle si vous regardez les modules quil
contient, puis les relations entre ces modules. Une fois quon a compris linteraction
entre les modules, on peut commencer sintresser aux dtails lintrieur dun
module. Cest une manire simple et efficace de grer la complexit.
Une autre raison dutiliser des modules est lie la qualit du code. Il est largement
reconnu que le code logiciel doit avoir un fort niveau de cohsion et un faible niveau
de couplage. Mme si la cohsion commence lchelle de la classe et de la mthode,
elle peut tre applique lchelle du module. Il est recommand de regrouper les
classes fortement lies dans des modules pour fournir le maximum de cohsion
possible. Il y a plusieurs types de cohsion. Deux des plus rpandues sont la cohsion
communicationnelle et la cohsion fonctionnelle. La cohsion communicationnelle est
effective lorsque des parties du module oprent sur les mmes donnes. Ca a du sens
de les regrouper, car il existe une forte relation entre elles. La cohsion fonctionnelle
est atteinte quand toutes les parties du module travaillent de concert pour raliser une
tche bien dfinie. Elle est considre comme la meilleure forme de cohsion.
Utiliser des modules dans la conception est une faon de renforcer la cohsion et de
diminuer le couplage. Les modules devraient tre constitus dlments qui vont de
pair fonctionnellement ou logiquement, ce qui assure la cohsion. Les modules
devraient avoir des interfaces bien dfinies auxquelles accdent dautres modules. Au
lieu dappeler trois objets dun module, il est mieux daccder une interface, car cela
40

rduit le couplage. Un couplage faible diminue la complexit, et augmente la

maintenabilit. Il est plus facile de comprendre comment un systme fonctionne quand
il y a peu de connexions entre des modules qui assurent des tches bien dfinies, que
quand chaque module a des tas de connexions avec tous les autres.
Choisissez des Modules qui incarnent la nature du systme et renferment un ensemble
de concepts cohrents. Cela mne souvent un couplage faible entre modules, mais si
ce nest pas le cas, trouvez une manire de modifier le modle pour dbroussailler les
concepts, ou cherchez un concept que vous auriez ignor et qui pourrait tre la base
dun Module rassemblant les lments de manire sense. Visez un couplage faible,
dans le sens de concepts quon peut comprendre et rflchir indpendamment les uns
des autres. Raffinez le modle jusqu ce quil soit partitionn selon des concepts de
haut niveau du domaine et que le code correspondant soit galement dcoupl.
Donnez aux Modules des noms qui deviendront partie intgrante du Langage
omniprsent. Les modules et leurs noms doivent donner un aperu du domaine.
Les concepteurs ont lhabitude de crer des modules ds le dbut. Ce sont des
lments ordinaires de nos conceptions. Aprs que le rle du module ait t dcid, il
reste gnralement inchang, tandis que lintrieur du module peut varier beaucoup. Il
est recommand de samnager de la flexibilit, de permettre aux modules dvoluer
avec le projet et de ne pas les figer. Cest vrai quun refactoring de module peut tre
plus coteux quun refactoring de classe, mais lorsquune erreur de design dun
module est constate, il vaut mieux sy attaquer en changeant le module quen trouvant
des solutions palliatives.

Les Agrgats
Les trois derniers patterns de ce chapitre vont traiter dun autre dfi de modlisation,
un dfi li au cycle de vie des objets du domaine. Les objets du domaine passent par
une srie dtats au cours de leur vie. Ils sont crs, placs en mmoire et utiliss dans
des traitements, puis ils sont dtruits. Dans certains cas ils sont sauvegards dans des
emplacements permanents, comme une base de donnes, o on peut les rcuprer un
peu plus tard, ou bien ils sont archivs. A un moment donn ils peuvent tre
compltement effacs du systme, y compris de la base et de larchive.
Grer le cycle de vie dun objet du domaine constitue un dfi en soi, et si ce nest pas
fait correctement, cela peut avoir un impact ngatif sur le modle du domaine. Nous
allons prsenter trois patterns qui nous aident rgler cela. Agrgat est un pattern de
domaine utilis pour dfinir lappartenance et les frontires des objets. Les Fabriques

41

et les Entrepts sont deux design patterns qui nous aident traiter la cration des
objets et leur stockage. Nous allons commencer par parler des Agrgats.
Un modle peut contenir un grand nombre dobjets du domaine. Aussi grande soit
lattention porte la conception, il arrive que de nombreux objets soient associs
entre eux, crant un rseau de relations complexe. Il y a plusieurs types dassociations.
Pour chaque association traversable du modle, il doit y avoir un mcanisme logiciel
correspondant qui la met en application. Les vritables associations entre objets du
domaine se retrouvent dans le code, et souvent mme dans la base de donnes. Une
relation un--un entre un client et le compte bancaire ouvert son nom est exprime
sous la forme dune rfrence entre deux objets, et engendre une relation entre deux
tables en base, celle qui contient les clients et celle qui contient les comptes.
Bien souvent, le dfi avec les modles nest pas de faire en sorte quils soient
suffisamment complets, mais de les rendre les plus simples et les plus comprhensibles
possible. La plupart du temps, il savre payant dliminer ou de simplifier des
relations du modle. A moins bien sr quelles ne reclent une comprhension
profonde du domaine.
Une association un--plusieurs est plus complexe car elle met en jeu de nombreux
objets qui deviennent lis. Cette relation peut tre simplifie en la transformant en une
association entre un objet et une collection dautres objets, bien que a ne soit pas
toujours possible.
Il existe des associations plusieurs--plusieurs et un grand nombre dentre elles sont
bidirectionnelles. Cela augmente beaucoup la complexit, rendant la gestion du cycle
de vie de ce genre dobjets assez difficile. Le nombre dassociations devrait tre rduit
autant que possible. En premier lieu, les associations qui ne sont pas essentielles pour
le modle devraient tre retires. Il se peut quelles existent dans le domaine, mais
quelles ne soient pas ncessaires dans notre modle, donc on peut les enlever.
Deuximement, la multiplicit peut tre rduite en ajoutant une contrainte. Si
beaucoup dobjets satisfont une relation, cest possible quun seul puisse le faire si
on impose la bonne contrainte sur la relation. Troisimement, dans bien des cas les
associations bidirectionnelles peuvent tre transformes en associations
unidirectionnelles. Chaque voiture a un moteur, et chaque moteur a une voiture dans
laquelle il tourne. La relation est bidirectionnelle, mais elle peut facilement tre
simplifie en considrant que la voiture a un moteur, et pas linverse.
Aprs avoir rduit et simplifi les associations entre objets, il se peut quon ait encore
beaucoup de relations sur les bras. Un systme bancaire dtient et traite des donnes
client. Ces donnes comprennent les informations personnelles du client, comme le
nom, ladresse, les numros de tlphone, la description de lemploi, et des
informations sur le compte : numro de compte, solde, oprations effectues, etc.
42

Quand le systme archive ou supprime compltement les informations sur un client, il

doit sassurer que toutes les rfrences sont enleves. Si beaucoup dobjets possdent
ces rfrences, il est difficile dtre sr quelles ont toutes t retires. De plus, lorsque
les donnes dun client changent, le systme doit vrifier quelles sont correctement
mises jour travers tout le systme, et que lintgrit des donnes est garantie. On
laisse gnralement la base de donnes le soin de sen occuper. Les transactions sont
utilises pour assurer lintgrit des donnes. Mais si le modle na pas t
soigneusement conu, il y aura un fort degr de sollicitation de la base, conduisant
des performances mdiocres. Mme si les transactions de base de donnes jouent un
rle vital dans de telles oprations, il est souhaitable de rsoudre certains problmes
lis lintgrit des donnes directement dans le modle.
Il est aussi ncessaire de pouvoir faire respecter les invariants. Les invariants sont ces
rgles qui doivent tre maintenues chaque fois que les donnes changent. Cest dur
accomplir quand beaucoup dobjets ont des rfrences vers les objets dont les donnes
changent.
Il est difficile de garantir la cohrence des modifications apportes aux objets dans un
modle avec des associations complexes. Dans bien des cas, les invariants sappliquent
des objets troitement lis, pas juste des objets discrets. Mme des politiques de
verrouillage prudentes peuvent amener plusieurs utilisateurs interfrer entre eux sans
raison et rendre un systme inutilisable.
Pour cette raison, utilisez des Agrgats. Un Agrgat est un groupe dobjets associs
qui sont considrs comme un tout unique vis--vis des modifications de donnes.
LAgrgat est dmarqu par une frontire qui spare les objets situs lintrieur de
ceux situs lextrieur. Chaque Agrgat a une racine. La racine est une Entit, et
cest le seul objet accessible de lextrieur. La racine peut possder des rfrences vers
nimporte quel objet de lagrgat, et les autres objets peuvent se rfrencer entre eux,
mais un objet externe peut seulement avoir une rfrence vers lobjet racine. Sil y a
dautres Entits lintrieur de la frontire, lidentit de ces entits est locale, elle fait
sens seulement lintrieur de lagrgat.
Comment lAgrgat assure-t-il lintgrit des donnes et fait-il respecter les
invariants ? Puisque les objets externes peuvent seulement avoir des rfrences vers la
racine, a veut dire quils ne peuvent pas directement modifier les autres objets de
lagrgat. Tout ce quils peuvent faire, cest changer la racine, ou demander la racine
deffectuer des actions. La racine sera capable de modifier les autres objets, mais cest
une opration contenue dans lagrgat, et contrlable. Si la racine est supprime et
retire de la mmoire, tous les autres objets de lagrgat seront supprims aussi, car il
ny aura plus dautre objet possdant une rfrence vers lun dentre eux. Lorsquun
quelconque changement est apport la racine qui affecte indirectement les autres

43

objets de lagrgat, il est facile dassurer les invariants, car cest la racine qui le fait.
Ca serait beaucoup plus dur faire si des objets externes avaient un accs direct aux
objets internes et les modifiaient. Garantir les invariants dans cette circonstance
impliquerait de mettre la logique adquate dans des objets externes, ce qui nest pas
souhaitable.
La racine a la possibilit de passer des rfrences phmres dobjets internes des
objets externes, la condition que les objets externes ne conservent pas la rfrence
aprs que lopration soit finie. Une illustration simple de cela consiste passer des
copies dObjets Valeurs aux objets externes. Ce qui arrive ces objets nest pas
vraiment important, parce que a naffectera pas lintgrit de lagrgat de toute faon.
Si les objets dun Agrgat sont stocks en base de donnes, seule la racine devrait
pouvoir tre obtenue par des requtes. Ont devrait accder aux autres objets travers
des associations traversables.
Les objets lintrieur dun Agrgat doivent tre autoriss dtenir des rfrences
vers les racines dautres Agrgats.
LEntit racine a une identit globale, et elle est responsable du maintien des
invariants. Les Entits internes ont une identit locale.
Rassemblez les Entits et Objets Valeurs dans des Agrgats et dfinissez des frontires
autour de chacun. Dans chaque Agrgat, choisissez une Entit qui sera la racine, et
faites-lui contrler laccs aux objets situs lintrieur de la frontire. Vous ne devez
autoriser les objets externes dtenir des rfrences que vers la racine. Des rfrences
phmres vers des membres internes peuvent tre passes au-dehors uniquement dans
le cadre dune utilisation pour une opration ponctuelle. Puisque la racine contrle
laccs, elle ne peut pas tre prise de court par une modification inattendue des
lments internes. Grce cet arrangement, il devient pratique dassurer les invariants
des objets de lAgrgat et de lAgrgat dans sa globalit lors de tout changement
dtat.
Un exemple simple dAgrgation est prsent dans le diagramme qui suit. Le client est
la racine de lAgrgat, et tous les autres objets sont internes. Si on a besoin de
lAdresse, une copie de celle-ci peut tre passe aux objets externes.

44

Les Fabriques
Les Entits et les Agrgats peuvent parfois tre vastes et complexes trop complexes
pour tre crs dans le constructeur de lentit racine. En fait, essayer de construire un
agrgat complexe dans son constructeur serait entrer en contradiction avec la manire
dont a se passe souvent dans le domaine lui-mme, o des choses sont cres par
dautres choses (comme les composants lectroniques sont crs par des lignes
dassemblage). Ce serait comme demander une imprimante de se construire ellemme.
Lorsquun objet client veut crer un autre objet, il appelle son constructeur et lui passe
ventuellement des paramtres. Mais quand la construction de lobjet est un processus
laborieux, crer lobjet demande une grande connaissance de sa structure interne, des
relations entre les autres objets quil contient, et des rgles qui sy appliquent. En
dautres termes, chaque client de lobjet va devoir dtenir une connaissance spcifique
de lobjet construire. Ca rompt lencapsulation des objets du domaine et des
Agrgats. Si le client appartient la couche application, une partie de la couche
domaine a t dplace ailleurs, ce qui dtraque toute la conception. Dans la vie relle,
cest comme si on nous donnait du plastique, du caoutchouc, du mtal, du silicium et
quon construisait notre propre imprimante. Ce nest pas impossible faire, mais cela
en vaut-il rellement la peine ?
La cration dun objet a beau tre une opration importante en soi, les oprations
dassemblage complexes ne sont pas de la responsabilit des objets crateurs.
45

Combiner de telles responsabilits peut produire des designs disgracieux qui sont
difficiles comprendre.
Cest pourquoi il est ncessaire dintroduire un nouveau concept qui aide encapsuler
le processus de cration dun objet complexe. Cest ce quon appelle une Fabrique.
Les Fabriques sont utilises pour encapsuler la connaissance ncessaire la cration
des objets, et elles sont particulirement utiles pour crer des Agrgats. Quand la
racine dun Agrgat est cre, tous les objets contenus dans lAgrgat sont crs en
mme temps quelle, et tous les invariants sont appliqus.
Il est important que le processus de cration soit atomique. Si ce nest pas le cas, il y a
des chances pour que le processus soit moiti termin chez certains objets, les
laissant dans un tat indtermin. Cest encore plus vrai pour les Agrgats. Lorsquon
cre la racine, il est ncessaire de crer aussi tous les objets sujets des invariants.
Sinon, les invariants ne peuvent pas tre appliqus. Pour des Objets Valeurs
immuables, cela veut dire que tous les attributs sont initialiss dans un tat valide. Si
un objet ne peut pas tre cr correctement, une exception devrait tre leve, assurant
quon ne retourne pas une valeur invalide.
Pour cette raison, faites basculer la responsabilit de crer des instances dobjets
complexes et dAgrgats dans un objet spar, qui potentiellement na lui-mme
aucune responsabilit dans le modle du domaine mais fait tout de mme partie du
design du domaine. Fournissez une interface qui encapsule tout lassemblage
complexe et ne ncessite pas que le client rfrence les classes concrtes des objets
instancier. Crez les Agrgats entiers de faon unitaire, en appliquant leurs invariants.
On utilise plusieurs design patterns pour implmenter les Fabriques. Le livre Design
Patterns (Gamma et al.) les dcrit en dtail, et prsente entre autres ces deux
patterns : Mthode de fabrication, et Fabrique abstraite1. Nous nallons pas tenter de
prsenter ces patterns dun point de vue conception, mais dun point de vue
modlisation du domaine.
Une Mthode de fabrication est une mthode dun objet qui contient et masque la
connaissance ncessaire pour crer un autre objet. Cest trs utile lorsquun client veut
crer un objet qui appartient un Agrgat. La solution est dajouter une mthode la
racine dagrgat qui soccupe de crer lobjet, de mettre en uvre tous les invariants,
et de retourner une rfrence vers cet objet ou vers une copie de cet objet.

Factory Method et Abstract Factory

46

Le conteneur contient des composants qui sont dun certain type. Quand un tel
composant est cr, il est ncessaire quil appartienne automatiquement un
conteneur. Le client appelle la mthode creerComposant(Type t) du conteneur. Le
conteneur instancie un nouveau composant. La classe concrte du composant est
dtermine en se basant sur son type. Aprs sa cration, le composant est ajout la
collection de composants du conteneur, et une copie en est retourne au client.
Il y a des fois o la construction dun objet est soit plus complexe, soit elle implique la
cration dune srie dobjets. Par exemple : la cration dun Agrgat. Cacher les
besoins internes de cration dun Agrgat peut se faire dans un objet Fabrique spar
qui est ddi cette tche. Prenons lexemple dun module dun programme qui
calcule la route pouvant tre suivie par une voiture dun point de dpart une
destination, tant donn une srie de contraintes. Lutilisateur se connecte au site web
qui excute lapplication et spcifie une des contraintes suivantes : trajet le plus court,
trajet le plus rapide, trajet le moins cher. Les trajets crs peuvent tre annots avec
des informations utilisateur quil faut sauvegarder, pour quon puisse les retrouver plus
tard lorsque lutilisateur se connectera nouveau.

47

Le gnrateur dID de route est utilis pour crer une identit unique pour chaque
route, chose ncessaire pour une Entit.
Lorsquon cre une Fabrique, on est forc de violer lencapsulation dun objet, ce qui
doit tre fait avec prudence. A chaque fois que quelque chose change dans lobjet qui a
un impact sur les rgles de construction ou sur certains des invariants, nous devons
nous assurer que le code de la Fabrique est mis jour pour supporter les nouvelles
conditions. Les Fabriques sont profondment lies aux objets quelles crent. Ca peut
tre une faiblesse, mais a peut aussi tre une force. Un Agrgat contient une srie
dobjets troitement relis entre eux. La construction de la racine est associe la
cration des autres objets de lAgrgat, et il doit y avoir une logique pour constituer un
Agrgat. Cette logique nappartient pas naturellement un des objets, parce quelle
concerne la construction dautres objets. Il semble adapt dutiliser une classe
Fabrique spciale qui on confie la tche de crer lAgrgat tout entier, et qui
contiendra les rgles, les contraintes et les invariants devant tre appliqus pour que
lAgrgat soit valide. Les objets resteront simples et serviront leur propre but sans tre
gns par le fouillis dune logique de construction complexe.
Les Fabriques dEntits sont diffrentes des Fabriques dObjets Valeurs. Les Objets
Valeurs sont gnralement immuables, et tous les attributs ncessaires doivent tre
produits au moment de leur cration. Lorsque lobjet est cr, il doit tre valide et
finalis. Il ne changera pas. Les Entits ne sont pas immuables. Elles peuvent tre
changes plus tard en modifiant des attributs, en ajoutant que tous les invariants
doivent tre respects. Une autre diffrence vient du fait que les Entits ont besoin
dune identit alors que les Objets Valeurs, non.

48

Certaines fois, on na pas besoin dune Fabrique, un simple constructeur suffit.

Utilisez un constructeur lorsque :
La construction nest pas complique.
La cration dun objet nimplique pas la cration dautres, et tous les attributs
requis sont passs via le constructeur.
Le client sintresse limplmentation, et potentiellement il veut choisir la
Stratgie utiliser.
La classe est le type. Il ny a pas de hirarchie en jeu, donc pas besoin de
choisir parmi une liste dimplmentations concrtes.
Une autre observation est que les Fabriques doivent soit crer de nouveaux objets
partir de zro, soit on leur demande de reconstituer des objets qui existaient
prcdemment, mais qui ont probablement t persists dans une base de donnes.
Ramener des Entits en mmoire depuis leur lieu stockage en base met en jeu un
processus compltement diffrent de la cration de nouvelles Entits. Une diffrence
vidente est que lobjet existant na pas besoin dune nouvelle identit. Lobjet en a
dj une. Les violations des invariants sont traites diffremment. Quand un nouvel
objet est cr partir de rien, toute violation dinvariant finit en exception. On ne peut
pas faire a avec des objets recrs depuis une base. Les objets doivent tre rpars
dune manire ou dune autre pour quils puissent tre fonctionnels, sinon il y a perte
de donnes.

Les Entrepts
Dans une conception dirige par le modle, les objets ont un cycle de vie qui
commence par leur cration et se termine avec leur suppression ou leur archivage. Un
constructeur ou une Fabrique se charge de la cration de lobjet. Tout lobjectif de
crer des objets est de pouvoir les utiliser. Dans un langage orient objet, on doit
possder une rfrence vers un objet pour tre capable de sen servir. Pour avoir cette
rfrence, le client doit soit crer lobjet, soit lobtenir dun autre, en traversant une
association existante. Par exemple, pour obtenir un Objet-Valeur dun Agrgat, le
client doit le demander la racine de lAgrgat. Lennui, cest que maintenant le client
a une rfrence vers la racine. Dans de grosses applications, a peut tre un problme
parce quon doit sassurer que le client a toujours une rfrence vers lobjet dont il a
besoin, ou vers un autre objet qui lui, a cette rfrence. Utiliser ce genre de rgle dans
la conception va forcer les objets conserver une srie de rfrences quils ne
garderaient probablement pas autrement. Cela augmente le couplage, crant une srie
dassociations dont on na pas vraiment besoin.
49

Utiliser un objet implique que lobjet ait dj t cr. Si lobjet est la racine dun
Agrgat, alors cest une Entit, et il y a des chances pour quelle soit stocke dans un
tat persistant dans une base de donnes ou une autre forme de stockage. Si cest un
Objet-Valeur, il peut tre obtenu auprs dune Entit en traversant une association,
mais il savre que bon nombre dobjets peuvent tre directement rcuprs dans une
base de donnes. Cela rsout le problme de lobtention de rfrences dobjets. Quand
un client veut utiliser un objet, il accde la base, y retrouve lobjet et sen sert. Cela
semble une solution simple et rapide, mais a a des impacts ngatifs sur le design.
Les bases de donnes font partie de linfrastructure. Une solution mdiocre serait que
le client connaisse les dtails requis pour accder une base. Par exemple, le client
devrait crer des requtes SQL pour rcuprer les donnes souhaites. La requte de
base de donnes retournerait un jeu denregistrements, exposant encore plus de ses
dtails internes. Quand beaucoup de clients doivent crer des objets directement depuis
la base de donnes, ce genre de code se retrouve parpill un peu partout dans le
domaine. A cet instant le modle du domaine est compromis. Il doit traiter de
nombreux dtails dinfrastructure au lieu de soccuper des concepts du domaine. Que
se passe-t-il si la dcision est prise de changer la base de donnes sous-jacente ? Tout
ce code dispers doit tre modifi pour quon puisse accder au nouvel emplacement
de stockage. Lorsque du code client accde une base directement, il est possible quil
restaure un objet interne un Agrgat. Cela rompt lencapsulation de lAgrgat, avec
des consquences inconnues.
Un client a besoin dun moyen concret dacqurir des rfrences vers des objets du
domaine prexistants. Si linfrastructure rend cela facile, il est probable que les
dveloppeurs du code client ajouteront plus dassociations traversables et embrouillent
le modle. Ou alors, il se peut quils utilisent des requtes pour puiser directement
dans la base les donnes exactes dont ils ont besoin, ou pour piocher quelques objets
spcifiques plutt que de naviguer partir des racines dagrgats. La logique du
domaine est dplace dans les requtes et le code client, et les Entits et Objets
Valeurs deviennent de simples conteneurs de donnes. La complexit technique brute
de limplmentation de linfrastructure daccs la base submerge rapidement le code
client, ce qui amne les dveloppeurs abtir la couche domaine, et rend le modle
obsolte. Leffet gnral est quon perd la focalisation sur le domaine et quon
compromet le design.
Pour cette raison, utilisez un Entrept, dont le but est dencapsuler toute la logique
ncessaire lobtention de rfrences dobjets. Les objets du domaine nauront pas
soccuper de linfrastructure de rcupration des rfrences aux autres objets du
domaine dont ils ont besoin. Ils iront simplement les chercher dans lEntrept et le
modle retrouvera sa clart et sa focalisation.

50

LEntrept est capable de conserver des rfrences vers des objets. Quand un objet est
cr, il peut tre sauvegard dans lEntrept, et y tre rcupr plus tard quand on
voudra lutiliser. Si le client demande un objet lEntrept, et que lEntrept ne la
pas, ce dernier peut aller le chercher dans lemplacement de stockage physique. Dans
tous les cas, lEntrept agit comme un endroit o sont emmagasins des objets
globalement accessibles.
LEntrept peut aussi comporter une Stratgie. Il peut accder un stockage persistant
ou un autre en fonction de la Stratgie prcise. Il se peut quil utilise diffrents
emplacements de stockage pour diffrents types dobjets. Cela a pour effet global de
dcoupler le modle du domaine du besoin de stocker des objets ou leurs rfrences et
de celui daccder linfrastructure de persistance sous-jacente.

Pour chaque type dobjet qui ncessite un accs global, crez un objet qui puisse
procurer lillusion dune collection en mmoire de tous les objets de ce type.
Organisez-en laccs travers une interface globale connue de tous. Fournissez des
mthodes pour ajouter et enlever des objets, qui encapsuleront les vritables insertions
et suppressions de donnes dans le stockage des donnes. Proposez des mthodes qui
slectionnent des objets en se basant sur des critres et qui retournent des objets ou
collections dobjets pleinement instancis dont les valeurs satisfont les critres ; ce
faisant, vous encapsulerez la technologie relle de stockage et de requtage.
Fournissez des Entrepts seulement pour les racines dagrgats qui ncessitent
rellement un accs direct. Conservez un client focalis sur le modle, en dlgant tout
stockage ou accs aux donnes aux Entrepts.
Un Entrept peut contenir des informations dtailles dont il se sert pour accder
linfrastructure, mais son interface devrait tre simple. Un Entrept doit avoir un jeu
de mthodes utilises pour rcuprer des objets. Le client appelle une de ces mthodes
51

et lui passe un ou plusieurs paramtres qui reprsentent les critres de slection utiliss
pour choisir un objet ou un ensemble dobjets correspondants. Une Entit peut
facilement tre demande en passant son identit. Dautres critres de slection
peuvent tre constitus dun ensemble dattributs de lobjet. LEntrept va comparer
tous les objets cet ensemble et retournera ceux qui satisfont aux critres. Linterface
de lEntrept pourrait aussi contenir des mthodes utilises pour effectuer des calculs
supplmentaires comme le nombre dobjets dun certain type.
On notera que limplmentation dun entrept peut tre troitement assimile de
linfrastructure, mais que linterface de lentrept est du pur modle du domaine.

Une autre option est de prciser des critres de slection sous forme de Spcification.
La Spcification permet de dfinir des critres plus complexes, comme dans lexemple
suivant :

52

Il y a une relation entre Fabrique et Entrept. Ce sont tous deux des patterns de
conception dirige par le modle, et ils nous aident tous les deux grer le cycle de vie
des objets du domaine. Tandis que la Fabrique est concerne par la cration dobjets,
lEntrept se charge des objets dj existants. LEntrept peut mettre en cache des
objets localement, mais trs souvent il a besoin de les rcuprer dans un lieu de
stockage persistant. Les objets sont soit crs en utilisant un constructeur, soit on les
passe une Fabrique pour quils y soient construits. Cest pour cette raison que
lEntrept peut tre vu comme une Fabrique, car il cre des objets. Ce nest pas une
cration ex nihilo, mais la reconstitution dun objet qui a exist. On ne doit pas
mlanger Entrept et Fabrique. La fabrique cre de nouveaux objets, tandis que
lEntrept retrouve des objets dj crs. Quand un nouvel objet doit tre ajout

53

lEntrept, il devrait dabord tre cr par la Fabrique, et ensuite donn lEntrept

qui le stockera comme dans lexemple ci-dessous.

Une autre faon de qualifier cela est de dire que les Fabriques sont purement
domaine alors que les Entrepts peuvent contenir des liens avec linfrastructure, par
exemple la base de donnes.

54

4
Refactorer pour une vision plus profonde

Refactorer en continu

Jusquici nous avons parl du domaine, et de limportance de crer un modle qui

exprime le domaine. Nous avons donn quelques conseils sur les techniques utiliser
pour crer un modle utile. Le modle doit tre troitement associ au domaine do il
provient. Nous avons aussi dit que le design du code doit tre construit autour du
modle, et que le modle lui-mme devait tre amlior partir des dcisions de
design. Concevoir sans modle peut mener un logiciel qui ne sera pas fidle au
domaine quil sert, et naura peut-tre pas le comportement attendu. A linverse,
modliser sans le feedback de la conception et sans impliquer les dveloppeurs nous
conduira vers un modle qui nest pas bien compris par ceux qui doivent
limplmenter, et peut ne pas tre adapt aux technologies utilises.
Pendant le processus de conception et de dveloppement, nous devons nous arrter de
temps en temps et jeter un il sur le code. Peut-tre que cest alors le bon moment
pour un refactoring. Le refactoring est le processus de reconception du code en vue de
lamliorer sans changer le comportement de lapplication. Le refactoring se droule
gnralement en petites tapes contrlables et prcautionneuses, pour ne pas casser des
fonctionnalits ou introduire des bugs. Aprs tout, lobjectif du refactoring est de
parfaire le code, pas de le dtriorer. Les tests automatiss sont dune grande aide pour
sassurer que nous navons rien endommag.
Il y a de nombreuses manires de refactorer du code. Il y a mme des patterns de
refactoring. Ces patterns constituent une approche automatise du refactoring. Il existe
des outils bass sur ces patterns, qui rendent la vie du dveloppeur bien plus facile

55

quelle ntait. Sans ces outils, il peut tre trs difficile de refactorer. Ce genre de
refactoring concerne plus le code et sa qualit.
Il existe un autre type de refactoring, qui est li au domaine et son modle. Parfois on
a de nouvelles ides sur le domaine, quelque chose devient plus clair, ou on dcouvre
une relation entre deux lments. Tout ceci doit tre inclus dans la conception via du
refactoring. Il est trs important davoir un code expressif, facile lire et
comprendre. A la lecture du code, on devrait tre capable de dire ce quil fait, mais
aussi pourquoi il le fait. Cest cette seule condition que le code peut vritablement
capturer la substance du modle.
Le refactoring technique, celui bas sur des patterns, peut tre organis et structur. Un
refactoring pour une vision plus profonde ne peut pas seffectuer de la mme manire.
On ne peut pas crer des patterns pour a. La complexit et la varit des modles ne
nous offrent pas la possibilit daborder la modlisation de faon mcanique. Un bon
modle est le produit dune rflexion profonde, de la perspicacit, de lexprience, et
du flair.
Une des premires choses quon nous apprend sur la modlisation, cest de lire les
spcifications fonctionnelles et de chercher les noms et les verbes. Les noms sont
convertis en classes, tandis que les verbes deviennent des mthodes. Cest une
simplification, et cela mne un modle superficiel. Tous les modles manquent de
profondeur au dbut, et nous devrions les refactorer en vue dune comprhension
toujours plus fine.
La conception doit tre flexible. Un design rigide rsiste au refactoring. Du code qui
na pas t construit dans un esprit de flexibilit, cest du code avec lequel il est
difficile de travailler. A chaque besoin de changement, vous allez devoir vous battre
avec le code, et les choses refactorer prendront facilement beaucoup de temps.
Utiliser un ensemble prouv de blocs de construction de base ainsi quun langage
cohrent assainit dj leffort de dveloppement. Ca nous laisse avec le dfi de trouver
un modle incisif, un modle qui capture les proccupations subtiles des experts du
domaine et peut guider une conception pragmatique. Un modle qui se dbarrasse du
superficiel et capture lessentiel est un modle profond. Cela devrait mettre le logiciel
davantage au diapason du mode de pense des experts du domaine, et le rendre plus
rceptif aux besoins des utilisateurs.
Traditionnellement, le refactoring est dcrit en termes de transformations de code avec
des motivations techniques. Le refactoring peut aussi tre motiv par une avance
nouvelle dans le domaine et le raffinement correspondant du modle ou de son
expression dans le code.

56

Les modles du domaine sophistiqus sont rarement dvelopps autrement que par un
processus itratif de refactoring, qui suppose une implication troite des experts mtier
et des dveloppeurs intresss par lapprentissage du domaine.

Mettre au jour les concepts cls

Le refactoring se fait par petites tapes. Aussi, le rsultat est une srie de petites
amliorations. Il y a des fois ou de nombreux petits changements ajoutent trs peu de
valeur au design, et dautres o quelques changements font une grande diffrence.
Cest ce quon appelle une Avance majeure.
Au dbut, on a un modle superficiel et grossier. Ensuite nous le raffinons, lui et le
design, en nous basant sur une connaissance plus profonde du domaine, sur une
meilleure comprhension de ses enjeux. On y ajoute des abstractions. Puis la
conception est refactore. Chaque affinage ajoute de la clart au design. Cela cre
ensuite les conditions pour une Avance majeure.
Une Avance majeure implique souvent un changement dans la faon dont nous
pensons et voyons le modle. Cest une source de grand progrs dans le projet, mais
cela a aussi ses inconvnients. Une Avance majeure peut impliquer une grande
quantit de refactoring. Cela signifie du temps et des ressources, choses dont, semblet-il, nous manquons toujours. Cest galement risqu, car un vaste refactoring peut
introduire des changements dans le comportement de lapplication.
Pour raliser une Avance majeure, il nous faut rendre explicites les concepts
implicites. Quand on parle aux experts du domaine, on change beaucoup dides et de
connaissances. Certains concepts se frayent un chemin jusquau Langage omniprsent,
mais dautres passent inaperus dans un premier temps. Ce sont des concepts
implicites, utiliss pour expliquer dautres concepts dj prsents dans le modle.
Pendant le processus daffinage de la conception, quelques-uns de ces concepts
implicites attirent notre attention. On dcouvre que certains dentre eux jouent un rle
cl dans la conception. Cest ce moment-l que nous devrions rendre ces concepts
explicites. On devrait leur crer des classes et des relations. Quand a se produit, il se
peut quon ait la chance dtre face une Avance majeure.
Les concepts implicites ne devraient pas le rester. Si ce sont des concepts du domaine,
ils devraient tre prsents dans le modle et dans la conception. Comment les
reconnaitre ? La premire faon de dcouvrir des concepts implicites, cest dcouter

57

le langage. Le langage quon utilise pendant la modlisation et la conception contient

beaucoup dinformations sur le domaine. Au dbut il peut ne pas y en avoir tant que
a, ou une partie de linformation peut ne pas tre utilise correctement. Il se peut que
certains des concepts ne soient pas pleinement compris, ou mme quon les ait
totalement mal compris. Tout a fait partie de lapprentissage dun nouveau domaine.
Mais mesure que nous construisons notre Langage omniprsent, les concepts cls
finissent par sy intgrer. Cest l quon doit commencer chercher des concepts
implicites.
Parfois, il y a des parties du design qui ne sont pas si claires que a. Un ensemble de
relations rend le cheminement des traitements dur suivre. Ou bien les procdures font
quelque chose de complexe et de difficilement comprhensible. Il y a des maladresses
dans le design. Cest un bon endroit o chercher des concepts cachs. Probablement
que quelque chose manque. Si un concept cl manque au puzzle, les autres vont devoir
remplacer ses fonctionnalits. Cela va dilater certains objets, leur ajoutant un
comportement qui nest pas cens sy trouver. Cest la clart du design qui va en
souffrir. Essayez de voir sil y a un concept manquant et si vous en trouvez un, rendezle explicite. Refactorez le design pour le rendre plus simple et plus souple.
Lorsquon btit la connaissance, il est possible quon se heurte des contradictions. Ce
que dit un expert du domaine peut sembler aller lencontre de ce quun deuxime
soutient. Une spcification peut sembler en contredire une autre. Certaines
contradictions nen sont pas vraiment, ce sont plutt des manires diffrentes de voir la
mme chose, ou simplement un manque de prcision dans les explications. Nous
devons essayer de rconcilier les contradictions. Parfois, a met au jour des concepts
importants. Mme si ce nest pas le cas, cest tout de mme important de le faire pour
maintenir un modle bien clair.
Une autre faon vidente de dnicher des concepts du domaine est dutiliser la
littrature du domaine. Il existe des livres sur peu prs nimporte quel sujet. Ils
renferment des tas de connaissances sur leurs domaines respectifs. Gnralement, les
livres ne contiennent pas de modle des domaines quils prsentent : linformation qui
sy trouve doit tre traite, distille et raffine. Nanmoins, cette information est de
grande valeur et offre une vue approfondie du domaine.
Il y a dautres concepts qui sont trs utiles lorsquon les rend explicites : Contrainte,
Processus et Spcification. Une Contrainte est une manire simple dexprimer un
invariant. Quoi quil arrive aux donnes des objets, linvariant est respect. On peut
faire a simplement en mettant la logique de linvariant dans une Contrainte. Ce qui
suit en est un exemple simple. Son but est dexpliquer le concept, pas de prsenter
lapproche prconise dans ce cas nominal.

58

On peut ajouter des livres une tagre, mais on ne devrait jamais pouvoir en ajouter
plus que sa capacit. On peut voir a comme faisant partie du comportement de
lEtagre, comme dans le code Java qui suit.
public class Etagere {
private int capacite = 20;
private Collection contenu;
public void ajouter(Livre livre) {
if(contenu.size() + 1 <= capacite) {
contenu.add(livre);
} else {
throw new IllegalOperationException(
Ltagre a atteint sa limite.);
}
}
}

Nous pouvons refactorer le code en extrayant la contrainte dans une mthode spare.
public class Etagere {
private int capacite = 20;
private Collection contenu;
public void ajouter(Livre livre) {
if(espaceEstDisponible()) {
contenu.add(livre);
} else {
throw new IllegalOperationException(
Ltagre a atteint sa limite.);
}
}
private boolean espaceEstDisponible() {
return contenu.size() < capacite;
}

59

Placer la contrainte dans une mthode spare a lavantage de la rendre explicite. Cest
facile lire et tout le monde remarquera que la mthode ajouter() est sujette cette
contrainte. Il y aura aussi de la place pour une volution lorsquon voudra ajouter plus
de logique aux mthodes, si la contrainte devient plus complexe.
Les Processus sont gnralement exprims dans du code travers des procdures.
Nous nallons pas utiliser une approche procdurale, puisque nous utilisons un langage
orient objet ; il nous faut donc choisir un objet pour le processus, et y ajouter un
comportement. La meilleure manire dimplmenter les processus est dutiliser un
Service. Sil y a diffrentes manires de mener bien le processus, alors nous pouvons
encapsuler lalgorithme dans un objet et utiliser une Stratgie. Tous les processus ne
sont pas destins tre rendus explicites. Le bon moment pour implmenter
explicitement un processus, cest quand le Langage omniprsent le mentionne
expressment.
La dernire mthode pour rendre les concepts explicites dont nous traiterons ici est la
Spcification. Pour faire simple, on utilise une Spcification pour tester un objet afin
de voir sil satisfait certains critres.
La couche domaine contient des rgles mtier qui sappliquent aux Entits et aux
Objets Valeurs. Ces rgles sont classiquement intgres dans les objets auxquels elles
sappliquent. Certaines dentre elles sont juste un ensemble de questions dont la
rponse est oui ou non . Ce genre de rgle peut tre exprim par une srie
doprations logiques appliques sur des valeurs boolennes, et le rsultat final est
aussi un boolen. Un exemple de a, cest le test effectu sur un objet Client pour voir
sil est ligible un certain crdit. La rgle peut tre exprime sous forme de mthode
appele estEligible(), et rattache lobjet Client. Mais cette rgle nest pas une simple
mthode qui opre strictement sur des donnes du Client. Lvaluation de la rgle
implique de vrifier les rfrences du client, de voir sil a pay ses dettes dans le pass,
dexaminer sil a des soldes ngatifs, etc. Ces rgles mtier peuvent tre grosses et
complexes et faire gonfler lobjet au point quil ne serve plus son objectif dorigine. A
ce moment on pourrait tre tent de dplacer lintgralit de la rgle au niveau
application, car elle semble stendre au-del du niveau domaine. En fait, il est temps
de refactorer.
La rgle doit tre encapsule dans un objet spar qui devient la Spcification du
Client, et quon doit laisser dans la couche domaine. Le nouvel objet va contenir une
srie de mthodes boolennes qui testent si un objet Client particulier est ligible pour
un crdit ou pas. Chaque mthode joue le rle dun petit test, et toutes les mthodes
combines donnent la rponse la question dorigine. Si la rgle mtier nest pas

60

comprise dans un unique objet Spcification, le code qui correspond finira parpill
dans bon nombre dobjets, ce qui le rendra incohrent.
La Spcification est utilise pour tester des objets pour voir sils rpondent un
besoin, ou sils sont prts remplir un objectif. On peut aussi sen servir pour
slectionner un objet particulier dans une collection, ou comme condition durant la
cration dun objet.
Souvent, il y a une Spcification spare pour vrifier que chaque rgle simple est
satisfaite, et ensuite on combine un certain nombre dentre elles dans une spcification
composite qui exprime la rgle complexe, comme ceci :
Client client =
entrepotClients.trouverClient(identiteClient);

Specification clientEligiblePourRemboursement = new

Specification(
new clientAPayeSesDettesDansLePasse(),
new clientNAPasDeSoldesNegatifs());
if(clientEligiblePourRemboursement.estSatisfaitePar(client)
{
serviceRemboursement.envoyerRemboursementA(client);
}

Il est plus simple de tester des rgles lmentaires, et juste en regardant ce code, la
dfinition dun client ligible un remboursement devient vidente.

61

5
Prserver lintgrit du modle
Ce chapitre traite des gros projets qui ncessitent les efforts combins de multiples
quipes. On se retrouve face un nouvel ensemble de dfis lorsquon confie
plusieurs quipes, dans des conditions de management et de coordination diverses, la
tche de dvelopper un projet. Les projets dentreprise sont gnralement vastes, ils
emploient des technologies et des ressources varies. La conception de tels projets
devrait tout de mme tre base sur un modle du domaine, et on doit prendre les
mesures qui correspondent pour sassurer de la russite du projet.
Quand plusieurs quipes travaillent sur un projet, le dveloppement du code est fait en
parallle, chaque quipe se voyant assigner une partie spcifique du modle. Ces
parties ne sont pas indpendantes, mais plus ou moins interconnectes. On part dun
seul gros modle, et tout le monde reoit une partie de celui-ci implmenter.
Supposons quune quipe a cr un module, et le rend disponible lusage des autres
quipes. Un dveloppeur dune autre quipe commence utiliser le module, et
dcouvre quil manque ce dernier une fonctionnalit requise par son propre module.
Il ajoute cette fonctionnalit et archive le code pour quil puisse tre utilis par tous.
Ce quil na peut-tre pas ralis, cest que a constitue en ralit un changement du
modle, et il est tout fait possible que ce changement casse des fonctionnalits de
lapplication. Ca peut arriver dautant plus facilement que personne ne prend tout fait
le temps de comprendre le modle en entier. Chacun matrise son propre pr carr,
mais ne connait pas les autres zones suffisamment en dtail.
Il suffit de pas grand-chose pour partir dun bon modle et le faire progresser vers un
modle incohrent. La premire ncessit pour un modle est quil soit cohrent, avec
des termes fixs et aucune contradiction. La cohrence interne dun modle est appele
unification. Un projet dentreprise peut avoir un modle qui recouvre lintgralit du
domaine de lentreprise, sans contradictions et sans termes qui se chevauchent. Le
modle dentreprise unifi est un idal difficile atteindre, et parfois a ne vaut mme
pas la peine dessayer. Ce genre de projet requiert les efforts combins de nombreuses
quipes. Les quipes ont besoin dun degr lev dindpendance dans le processus de
dveloppement, parce quelles nont pas le temps de se rencontrer et de dbattre de la
62

conception constamment. La coordination de telles quipes est une tche

pouvantable. Il se peut quelles appartiennent des services diffrents et quelles
aient des managements spars. Lorsque le design du modle volue en partie
indpendamment, on doit faire face lventualit dune perte dintgrit du modle.
Si on essaye de prserver lintgrit du modle en maintenant un gros modle unifi
pour tout le projet dentreprise, a ne marchera pas. La solution nest pas si vidente,
parce quelle est le contraire de tout ce que nous avons appris jusquici. Au lieu
dessayer de garder un gros modle qui va seffondrer plus tard, nous devrions le
diviser sciemment en plusieurs modles. Plusieurs modles bien intgrs peuvent
voluer indpendamment tant quils obissent au contrat auquel ils sont lis. Chaque
modle doit avoir une frontire clairement dlimite, et les liaisons entre modles
doivent tre dfinies avec prcision.
Nous allons dcrire un ensemble de techniques utilises pour maintenir lintgrit du
modle. Le dessin qui suit prsente ces techniques et les relations qui existent entre
elles.

Contexte born
Tout modle a un contexte. Quand on a affaire un seul modle, le contexte est
implicite. On na pas besoin de le dfinir. Quand on cre une application cense

63

interagir avec un autre logiciel, par exemple avec une application historique2, il est
clair que la nouvelle application possde ses propres modle et contexte, qui sont
spars du modle et du contexte historiques. Les deux ne peuvent pas tre combins,
mlangs, ou confondus. Mais lorsquon travaille sur une grosse application
dentreprise, il nous faut dfinir un contexte pour chaque modle que nous crons.
Dans tout gros projet, plusieurs modles entrent en jeu. Mais quand on essaie de
combiner des morceaux de code bass sur des modles distincts, le logiciel devient
bugg, peu fiable, et difficile comprendre. La communication entre les membres de
lquipe devient confuse. On ne distingue souvent pas bien dans quel contexte un
modle donn ne devrait pas tre appliqu.
Il ny a pas de formule mathmatique pour diviser un gros modle en modles plus
petits. Essayez de placer dans le mme modle les lments qui sont lis, et qui
forment un concept naturel. Un modle doit tre assez petit pour pouvoir tre assign
une seule quipe. La coopration et la communication au sein dune mme quipe
sont plus fluides et compltes, ce qui favorise le travail des dveloppeurs sur le mme
modle. Le contexte dun modle est lensemble de conditions quon doit appliquer
pour sassurer que les termes utiliss dans le modle prennent un sens prcis.
Lide de base, cest de dfinir le primtre dun modle, de tracer les limites de son
contexte, puis de faire tout ce qui est possible pour prserver son unit. Cest difficile
de maintenir un modle dans un tat pur quand il stend sur lintgralit du projet
dentreprise, mais cest beaucoup plus facile quand il se limite une zone prcise.
Dfinissez explicitement le contexte dans lequel le modle sapplique. Posez des
bornes explicites en termes dorganisation dquipe, dutilisation au sein de parties
spcifiques de lapplication, et de manifestations physiques comme les bases de code
et les schmas de bases de donnes. Essayez de prserver un modle strictement
cohrent lintrieur de ces frontires, et ne vous laissez pas distraire ou embrouiller
par des problmes extrieurs.
Un Contexte born nest pas un Module. Un Contexte born fournit le cadre logique
lintrieur duquel le modle volue. Les Modules sont utiliss pour organiser les
lments dun modle, donc le Contexte born englobe le Module.
Quand diffrentes quipes sont amenes travailler sur le mme modle, elles doivent
faire trs attention ne pas se marcher sur les pieds. Nous devons tre constamment
conscients que des changements dans le modle peuvent casser des fonctionnalits
existantes. Lorsquon utilise des modles multiples, chacun peut travailler librement
sur sa propre partie. Nous connaissons tous les limites de notre modle, et nous restons

Legacy application

64

 lintrieur de ses frontires. Nous devons juste nous assurer que le modle reste pur,
cohrent et unifi. Chaque modle supporte plus facilement le refactoring, sans
rpercussion sur les autres modles. La conception peut tre affine et distille afin
dobtenir le maximum de puret.
Il y a un prix payer pour avoir des modles multiples. On doit dfinir les frontires et
les relations entre les diffrents modles. Cela demande du travail en plus et un effort
de conception supplmentaire, et il y aura peut-tre des traductions faire entre les
modles. On ne pourra pas transfrer des objets entre deux modles, ni invoquer
librement un comportement comme sil ny avait pas de frontire. Mais ce nest pas
une tche trs difficile, et les bnfices justifient quon se donne cette peine.
Par exemple, nous voulons crer une application de-commerce pour vendre des
choses sur Internet. Cette application permet aux clients de senregistrer, et collecte
leurs donnes personnelles, dont le numro de carte de crdit. Les donnes sont
conserves dans une base relationnelle. Les clients peuvent se logger, parcourir le site
pour chercher des produits, et passer commande. Lapplication va devoir publier un
vnement chaque fois quune commande est passe, pour que quelquun puisse
expdier larticle demand. Nous voulons aussi construire une interface de reporting
pour crer des rapports, en vue de surveiller le statut des produits disponibles, les
achats qui intressent les clients, ce quils naiment pas, etc. Au dbut, nous
commenons avec un modle qui couvre tout le domaine de le-commerce. Nous
avons cette tentation parce quaprs tout, on nous a demand de crer une seule grosse
application. Mais si nous examinons avec plus dattention la tche qui nous occupe,
nous dcouvrons que lapplication de boutique en ligne nest pas vraiment lie celle
de reporting. Elles ont des responsabilits diffrentes, et elles risquent mme de devoir
utiliser des technologies diffrentes. La seule chose vraiment commune est que les
donnes clients et produits sont conserves dans la base de donnes, et que les deux
applications y accdent.
Lapproche prconise est de crer un modle spar pour chacun des domaines, un
pour la boutique en ligne, et un pour le reporting. Ils peuvent tous deux voluer
librement sans grande proccupation de lautre, et mme devenir des applications
spares. Il peut savrer que lapplication de reporting ait besoin de donnes
particulires que lapplication de vente en ligne devra enregistrer en base, mais part
a elles peuvent se dvelopper indpendamment.
On a besoin dun systme de messagerie qui informe le personnel de lentrept des
commandes qui sont passes, pour quils puissent envoyer les marchandises
commandes. Le personnel du service expditions va utiliser une application qui lui
donne des informations dtailles sur larticle achet, la quantit, ladresse du client, et
les conditions de livraison. Nul besoin que le modle de-commerce couvre les deux

65

domaines dactivit. Il est beaucoup plus simple que lapplication de boutique en ligne
envoie des Objets Valeurs contenant les informations de commande lentrept en
utilisant des messages asynchrones. Il y a indniablement deux modles qui peuvent
tre dvelopps sparment, et nous devons juste nous assurer que linterface entre les
deux marche bien.

Intgration continue
Une fois quun Contexte born a t dfini, nous devons le maintenir dans un tat sain.
Quand un certain nombre de gens travaillent dans le mme Contexte born, le modle
a une forte tendance se fragmenter. Plus lquipe est grosse, plus le problme est de
taille, mais mme trois ou quatre personnes peuvent rencontrer de srieux ennuis. Pour
autant, vouloir dcomposer le systme en contextes de plus en plus petits finit par
provoquer la perte dun niveau dintgration et de cohrence trs utile.
Mme quand une quipe travaille dans un Contexte born, il y a de la place pour
lerreur. Il nous faut communiquer lintrieur de lquipe pour vrifier que nous
comprenons tous le rle jou par chaque lment du modle. Si quelquun ne saisit pas
bien les relations entre objets, il risque de modifier le code dune manire qui rentre en
contradiction avec lintention dorigine. Il est facile de se tromper de cette manire
quand on ne reste pas 100% concentr sur la puret du modle. Un membre de
lquipe peut crire du code qui duplique un code existant sans le savoir, ou ajouter du
code en doublon au lieu de modifier le code actuel, de peur de casser une
fonctionnalit existante.
Un modle nest pas entirement dfini ds le dbut. Il est cr, puis il volue
continuellement sur la base de nouvelles perspectives dans le domaine et de retours
dinformations du processus de dveloppement. Cela veut dire que de nouveaux
concepts risquent dentrer dans le modle, et que de nouveaux lments sont ajouts au
code. Tout cela doit tre intgr dans le modle unifi, et implment en consquence
dans le code. Cest pourquoi lIntgration continue est un procd ncessaire dans le
cadre dun Contexte born. Il nous faut un processus dintgration qui nous assure que
tous les lments ajouts sintgrent harmonieusement dans le reste du modle, et sont
correctement implments dans le code. Nous avons besoin dune procdure pour
fusionner le code. Plus tt nous fusionnons le code, mieux cest. Pour une petite
quipe seule, on recommande une intgration quotidienne. Il nous faut aussi mettre en
place un processus de compilation. Le code fusionn doit tre automatiquement
compil pour pouvoir tre test. Une autre condition ncessaire est de pratiquer des
tests automatiss. Si lquipe possde un outil de test, et a cr une suite de tests, ceux66

ci peuvent tre jous aprs chaque compilation, ainsi toute erreur est signale. On peut
facilement modifier le code pour rparer les erreurs indiques parce quelles sont
prises en charge tt, et ensuite le processus dintgration, compilation et tests repart.
LIntgration continue se base sur lintgration de nouveaux concepts dans le modle,
qui font leur chemin dans limplmentation o ils sont ensuite tests. Toute
incohrence du modle peut tre repre dans limplmentation. LIntgration
continue sapplique un Contexte born, elle nest pas utilise pour traiter les relations
entre Contextes voisins.

Carte de Contexte
Une application dentreprise a de multiples modles, et chaque modle a son propre
Contexte born. Il est conseill dutiliser le contexte comme base de lorganisation
dquipe. Les personnes dune mme quipe communiquent plus facilement, et ils
travaillent plus efficacement intgrer le modle et limplmentation.
Mme si chaque quipe travaille sur son modle, il est bon que tout le monde ait une
ide du tableau densemble. Une Carte de Contexte est un document qui met en
vidence les diffrents Contextes borns et leurs liaisons. Une Carte de Contexte peut
tre un diagramme comme celui-ci-dessous, ou nimporte quel document crit. Le
niveau de dtail peut varier. Ce qui est important, cest que tous ceux qui travaillent
sur le projet la partagent et la comprennent.

Il ne suffit pas davoir des modles unifis distincts. Ils doivent tre intgrs, parce que
chacune des fonctionnalits dun modle nest quune partie du systme entier. A la
fin, les pices doivent tre assembles, et tout le systme doit fonctionner
correctement. Si les contextes ne sont pas clairement dfinis, il est possible quils se

67

chevauchent. Si les liaisons entre contextes ne sont pas mises en vidence, il y a des
chances quelles ne marchent pas quand le systme sera intgr.
Chaque Contexte born doit avoir un nom qui fait partie du Langage omniprsent.
Cela favorise beaucoup la communication dquipe lorsquon parle du systme dans sa
globalit. Tout le monde devrait connaitre les limites de chaque contexte et les
mappages entre contextes et code. Une pratique courante consiste dfinir les
contextes, puis crer les modules de chaque contexte, et utiliser une convention de
nommage pour indiquer le contexte auquel chaque module appartient.
Dans les pages qui suivent, nous allons parler de linteraction entre diffrents
contextes. Nous prsenterons une srie de patterns qui peuvent tre utiliss pour crer
des Cartes de Contexte o les contextes ont des rles clairs et o leurs relations sont
montres. Noyau partag et Client-Fournisseur sont des patterns qui comportent un
haut niveau dinteraction entre contextes. Chemins spars est un pattern quon utilise
quand on veut que les contextes soient fortement indpendants et voluent sparment.
Il y a deux autres patterns qui traitent de linteraction entre un systme et un systme
historique ou un systme externe, ce sont les Services Htes ouverts et les Couches
Anticorruption.

Noyau partag

Quand lintgration fonctionnelle est limite, le cot de lIntgration continue peut tre
jug trop lev. Ca savre particulirement vrai lorsque les quipes nont pas les
comptences ou lorganisation politique ncessaires pour maintenir une intgration

68

continue, ou quand une quipe unique est simplement trop grosse et peu maniable.
Alors, on peut dfinir des Contextes borns spars et former plusieurs quipes.
Des quipes non coordonnes qui travaillent sur des applications troitement lies
peuvent faire la course chacun de leur ct pendant un moment, mais ce quelles
produisent risque de ne pas bien sassembler. Elles peuvent finir par passer plus de
temps sur des couches de traduction et des rajustements quelles nen auraient pass
sur de lIntgration continue le cas chant, ce qui se traduit par des efforts faits en
double et la perte des bnfices dun Langage omniprsent commun.
Par consquent, dsignez un sous-ensemble du modle du domaine que les deux
quipes saccordent partager. Bien sr cela comprend, en plus de cette portion du
modle, la sous-partie du code ou de la conception de la base de donnes qui va avec.
Ce morceau explicitement partag possde un statut spcial, et ne devrait pas tre
modifi sans consultation de lautre quipe.
Intgrez un systme fonctionnel frquemment, mais un peu moins souvent que le
rythme dintgration continue de chaque quipe. Lors de ces intgrations, jouez les
tests des deux quipes.
Lobjectif du Noyau partag est dviter les doublons, tout en gardant deux contextes
spars. Dvelopper sur un Noyau partag demande beaucoup de prcaution. Les deux
quipes peuvent modifier le code du noyau, et elles doivent intgrer leurs
changements. Si les quipes utilisent des copies spares du code du noyau, elles
doivent fusionner le code aussi souvent que possible, au moins une fois par semaine.
Un harnais de test devrait tre mis en place, pour que chaque changement apport au
noyau soit test immdiatement. Toute modification du noyau devrait tre
communique lautre quipe, et toutes les quipes devraient tre informes et tenues
au courant des nouvelles fonctionnalits.

Client-Fournisseur
Parfois, il arrive que deux sous-systmes aient une relation particulire : lun dpend
beaucoup de lautre. Les contextes dans lesquels ces deux sous-systmes existent sont
distincts, et le rsultat des traitements dun systme est dvers dans lautre. Ils nont
pas de Noyau partag, peut-tre parce quil nest conceptuellement pas correct den
avoir un, ou mme car il nest pas techniquement possible que les deux sous-systmes
partagent du code commun. Les deux systmes sont dans une relation ClientFournisseur.
Revenons un prcdent exemple. Nous avons parl plus haut des modles impliqus
dans une application de-commerce qui comporte aussi du reporting et un systme de
69

messages. Nous avons dj dit quil tait bien mieux de crer des modles spars
pour tous ces contextes, car un modle unique serait un goulet dtranglement
permanent et une source de discorde dans le processus de dveloppement. En
supposant que nous nous soyons mis daccord pour avoir des modles spars, quelle
devrait tre la relation entre le sous-systme de boutique web et celui de reporting ? Le
Noyau partag ne semble pas tre un bon choix. Les sous-systmes vont trs
probablement utiliser des technologies diffrentes dans leur implmentation. Lun est
une exprience purement navigateur, tandis que lautre pourrait tre une application
avec une IHM riche. Mme si lapplication de reporting est faite avec une interface
web, les concepts principaux des modles prcdemment cits sont diffrents. Il peut y
avoir de lempitement, mais pas assez pour justifier un Noyau partag. Nous allons
donc choisir une voie diffrente. Dun autre ct, le sous-systme de shopping en ligne
ne dpend pas du tout de celui de reporting. Les utilisateurs de la boutique
lectronique sont des clients qui parcourent les articles sur le web et passent des
commandes. Toutes les donnes sur les clients, les produits et les commandes sont
mises en base. Et cest tout. Lapplication de shopping en ligne ne sintresse pas
vraiment ce qui arrive aux dites donnes.
Dans le mme temps, lapplication de reporting, elle, sy intresse et a besoin des
donnes enregistres par la boutique en ligne. Elle a aussi besoin dinformations
supplmentaires pour assurer le service de reporting quelle propose. Il se peut que les
clients mettent des articles dans leur panier, mais en enlvent avant de rgler. Il se peut
quils visitent certains liens plus que dautres. Ce genre dinformations na pas de sens
pour lapplication de shopping en ligne, mais elles pourraient vouloir dire beaucoup
pour celle de reporting. Par consquent, il faut que le sous-systme fournisseur
implmente des spcifications dont a besoin le sous-systme client. Cest une des
connexions quil peut y avoir entre les deux sous-systmes.
Une autre exigence est lie la base de donnes utilise, et plus prcisment son
schma. Les deux applications vont se servir de la mme base. Si le sous-systme de
boutique en ligne tait le seul y accder, le schma de base de donnes pourrait tre
modifi tout moment pour reflter ses besoins. Mais le sous-systme de reporting
doit aussi accder la base, il a donc besoin de stabilit dans son schma. Il est
inimaginable que le schma de la base ne change pas du tout pendant le processus de
dveloppement. Ca ne posera pas de souci lapplication de shopping en ligne, mais
a sera certainement un problme pour celle de reporting. Les deux quipes vont
devoir communiquer, probablement travailler sur la base de donnes ensemble, et
dcider quand le changement doit tre ralis. Cela va reprsenter une limitation pour
le sous-systme de reporting, car cette quipe prfrerait effectuer la modification
rapidement et continuer dvelopper, au lieu dattendre lapplication de boutique en
ligne. Si lquipe boutique en ligne a le droit de veto, elle peut imposer des limites aux
changements faire sur la base de donnes, ce qui nuit lactivit de lquipe
70

reporting. Si lquipe boutique en ligne peut agir indpendamment, elle rompra les
accords tt ou tard, et implmentera des changements auxquels lquipe de reporting
nest pas prpare. Cest pourquoi ce pattern marche bien si les quipes sont
chapeautes par un mme management. Cela facilite le processus de dcision, et cre
une harmonie.
Cest quand on est face ce genre de scnario que la pice de thtre doit commencer.
Lquipe reporting doit jouer le rle du client, tandis que lquipe boutique en ligne
doit endosser celui du fournisseur. Les deux quipes devraient se rencontrer
rgulirement ou la demande, et discuter comme un client le fait avec son
fournisseur. Lquipe cliente prsente ses besoins, et lquipe fournisseur prpare ses
plans en consquence. Mme si toutes les exigences du client devront tre satisfaites
au final, cest au fournisseur den dcider lagenda de ralisation. Si certains besoins
sont considrs comme vraiment importants, ils devraient tre implments plus tt,
alors que dautres exigences peuvent tre reportes. Lquipe cliente aura aussi besoin
que des donnes dentre et de la connaissance soient partages par lquipe
fournisseur. Le processus circule dans une seule direction, mais cest ncessaire dans
certains cas.
Il faut que linterface entre les deux sous-systmes soit prcisment dfinie. Une suite
de tests de conformit devrait tre cre et utilise pour vrifier tout moment si les
spcifications de linterface sont respectes. Lquipe fournisseur pourra travailler sur
sa conception avec moins de rserve car le filet de scurit de la suite de tests
dinterface lalertera chaque fois quil y aura un problme.
Etablissez une relation client/fournisseur claire entre les deux quipes. Pendant les
sances de planning, ngociez et budgtez des tches pour les exigences du client de
sorte que chacun comprenne lengagement et le calendrier.
Dveloppez conjointement des tests dacceptation automatiss qui valideront
linterface attendue. Ajoutez ces tests la suite des tests de lquipe fournisseur pour
quils soient jous comme faisant partie de son intgration continue. Ces tests rendront
lquipe fournisseur libre de faire des modifications sans craindre deffets de bord dans
lapplication de lquipe cliente.

Conformiste
Une relation Client-Fournisseur est viable quand les deux quipes ont un intrt dans
la relation. Le client est trs dpendant du fournisseur, mais linverse nest pas vrai.
Sil y a un management pour faire fonctionner cela, le fournisseur prtera lattention
ncessaire et coutera les requtes du client. Si le management na pas clairement

71

dcid comment les choses sont censes se passer entre les deux quipes, ou si le
management est dfaillant ou absent, le fournisseur commencera tout doucement tre
plus proccup par son modle et sa conception que par laide apporter au client.
Aprs tout, les membres de lquipe fournisseur ont leurs propre deadlines. Mme si
ce sont des gens bien, volontaires pour aider lautre quipe, la pression des dlais aura
son mot dire, et lquipe cliente va en souffrir. Cela arrive aussi quand les quipes
appartiennent des socits diffrentes. La communication est difficile, et la socit
qui fournit peut ne pas trouver beaucoup dintrt sinvestir dans cette relation. Elle
va soit apporter une aide sporadique, soit refuser de cooprer tout court. Rsultat,
lquipe client se retrouve toute seule, en essayant de se dbrouiller du mieux quelle
peut avec le modle et la conception.
Quand deux quipes de dveloppement ont une relation Client-Fournisseur dans
laquelle lquipe qui fournit nest pas motive pour rpondre aux besoins de lquipe
cliente, cette dernire est dmunie. Laltruisme peut inciter les dveloppeurs
fournisseurs faire des promesses, mais il est peu probable quelles soient tenues. La
croyance en ces bonnes intentions mne lquipe cliente faire de plans se basant sur
des fonctionnalits qui ne seront jamais disponibles. Le projet client sera retard
jusqu ce que lquipe finisse par apprendre vivre avec ce quon lui donne. Une
interface taille pour les besoins de lquipe cliente nest pas prs de voir le jour.
Lquipe cliente a peu doptions. La plus vidente est de se sparer du fournisseur et
dtre compltement seule. Nous examinerons ceci plus tard dans le pattern Chemins
spars. Parfois, les bnfices apports par le sous-systme du fournisseur nen valent
pas la peine. Il peut tre plus simple de crer un modle spar, et de concevoir sans
avoir penser au modle du fournisseur. Mais ce nest pas toujours le cas.
Parfois il y a de la valeur dans le modle du fournisseur, et une connexion doit tre
maintenue. Mais comme lquipe fournisseur naide pas lquipe cliente, cette dernire
doit prendre des mesures pour se protger des changements du modle effectus par le
fournisseur. Elle va devoir implmenter une couche de translation qui connecte les
deux contextes. Il est aussi possible que le modle du fournisseur soit mal conu,
rendant son utilisation malaise. Le contexte client peut tout de mme sen servir, mais
il devrait se protger en utilisant une Couche anticorruption dont nous parlerons plus
loin.
Si le client est oblig dutiliser le modle de lquipe fournisseur, et si celui-ci est bien
fait, cest peut tre le moment de faire preuve de conformisme. Lquipe cliente peut
adhrer au modle du fournisseur et sy conformer entirement. Cela ressemble
beaucoup au Noyau partag, mais il y a une diffrence importante. Lquipe cliente ne
peut pas apporter de changements au noyau. Elle peut simplement lutiliser comme sil
faisait partie de son modle, et construire par-dessus le code existant qui lui est fourni.

72

Il y a beaucoup de cas o ce genre de solution est viable. Lorsque quelquun fournit un

composant riche, et une interface daccs celui-ci, nous pouvons construire notre
modle en y incluant ledit composant comme sil nous appartenait. Si le composant a
une petite interface, il pourrait savrer plus judicieux de crer simplement un
adaptateur, et de faire la traduction entre notre modle et le modle du composant.
Cela isolerait notre modle, et nous pourrions le dvelopper avec un grand degr de
libert.

Couche anticorruption
Nous rencontrons souvent des circonstances o nous crons une application qui est
oblige dinteragir avec du code logiciel historique ou une application spare. Cest
un dfi supplmentaire pour le modlisateur du domaine. Beaucoup dapplications
historiques nont pas t construites en utilisant des techniques de modlisation de
domaine, et leur modle est confus, broussailleux, il est difficile de le comprendre et
de travailler avec. Mme sil a t bien fait, le modle de lapplication historique ne
nous est pas dune grande utilit, car notre modle est probablement assez diffrent.
Nanmoins, il faut quil y ait un certain niveau dintgration entre notre modle et le
modle historique, car cela fait partie des prrequis pour pouvoir utiliser la vieille
application.
Notre systme client peut interagir avec un systme externe de diffrentes manires.
Lune dentre elles est de passer par des connexions rseau. Les deux applications
doivent utiliser les mmes protocoles de communication rseau, et il faut que le client
adhre linterface utilise par le systme externe. Une autre mthode dinteraction est
la base de donnes. Le systme externe travaille avec des donnes stockes dans une
base.
Le
client
est
cens
accder

la
mme
base.
Dans ces deux cas, nous avons affaire des donnes primitives qui sont transfres
entre les systmes. Bien que cela paraisse assez simple, en vrit les donnes
primitives ne contiennent aucune information sur les modles. On ne peut pas prendre
des donnes dans une base et les traiter entirement comme des donnes primitives. Il
y a beaucoup de smantique cache derrire les donnes. Une base de donnes
relationnelle contient des donnes primitives relies dautres, ce qui cre une toile de
relations. La smantique des donnes est trs importante et doit tre prise en
considration : lapplication cliente ne peut pas accder la base et y crire sans
comprendre la signification des donnes utilises. Il faut bien voir que des parties du
modle externe sont refltes dans la base de donnes, et elles viennent sintgrer dans
notre modle.

73

Il y a des chances pour que le modle externe altre le modle client, si on laisse faire
cela. Nous ne pouvons pas ignorer linteraction avec le modle externe, mais nous
devrions faire attention isoler notre propre modle de celui-ci. Nous devrions
construire une Couche anticorruption qui se dresse entre notre modle client et
lextrieur. Du point de vue de notre modle, la Couche anticorruption est une partie
naturelle du modle, elle ne parait pas tre quelque chose dtranger. Elle opre avec
des concepts et des actions familires notre modle. Mais la Couche anticorruption
dialogue avec le modle externe en utilisant le langage externe, pas le langage client.
Cette couche agit comme un traducteur dans les deux sens entre deux domaines et
langages. Le meilleur rsultat possible, cest que le modle client reste pur et cohrent
sans tre contamin par le modle externe.
Comment implmenter la Couche anticorruption ? Une trs bonne solution consiste
voir la couche comme un Service du point de vue du modle client. Un Service est trs
facile utiliser parce quil fait abstraction de lautre systme et nous permet de nous
adresser lui dans nos propres termes. Cest le Service qui va faire la traduction
requise, donc notre domaine reste isol. En ce qui concerne limplmentation concrte,
le Service va tre conu comme une Faade (voir Design Pattern de Gamma et al.,
1995). Dautre part, la Couche anticorruption va trs probablement avoir besoin dun
Adaptateur. LAdaptateur vous permet de convertir linterface dune classe en une
autre qui sera comprise par le client. Dans notre cas, lAdaptateur nenrobe pas
ncessairement une classe, car son travail consiste assurer la traduction entre deux
systmes.

La couche anticorruption peut contenir plus dun Service. Pour chaque Service il y a
une Faade qui correspond, et chaque Faade on adjoint un Adaptateur. On ne doit

74

pas utiliser un seul Adaptateur pour tous les Services, parce quon lencombrerait de
fonctionnalits htroclites.
Il nous reste encore un composant ajouter. LAdaptateur soccupe denvelopper le
comportement du systme externe, mais nous avons aussi besoin de convertir des
objets et des donnes. Cela se fait au moyen dun traducteur. Ca peut tre un objet trs
simple, avec peu de fonctionnalits, qui rpond au besoin basique de traduire des
donnes. Si le systme externe a une interface complexe, il peut savrer plus
judicieux dajouter une Faade supplmentaire entre les adaptateurs et cette interface
externe. Cela va simplifier le protocole de lAdaptateur, et le sparer de lautre
systme.

Chemins spars
Jusquici, nous avons cherch des faons dintgrer des sous-systmes, de les faire
travailler ensemble, et ce de telle manire que le modle et la conception restent sains.
Cela demande des efforts et des compromis. Les quipes qui travaillent sur ces soussystmes doivent passer un temps considrable rgler les relations entre eux. Ils
peuvent tre obligs de faire constamment des fusions de leur code, et deffectuer des
tests pour sassurer quils nont rien cass. Parfois, il arrive quune des quipes doive
passer un temps considrable simplement pour implmenter quelques exigences dont
lautre quipe a besoin. Il faut aussi faire des compromis. Cest une chose de
dvelopper quand on est indpendant, de choisir les concepts et associations
librement ; cen est une tout autre de devoir sassurer que notre modle sintgre dans
le framework dun autre systme. On va peut-tre devoir transformer le modle juste
pour quil fonctionne avec lautre sous-systme. Ou introduire des couches spciales
qui assurent les traductions entre les deux sous-systmes. Il y a des fois o on est
oblig de faire a, mais en certaines occasions on peut emprunter une voie diffrente.
Nous devons valuer prcisment les bnfices de lintgration des deux systmes et
lutiliser seulement si on en tire une vraie valeur. Si nous arrivons la conclusion que
lintgration apporte plus dennuis quelle nest utile, alors on devrait opter pour des
Chemins spars.
Le pattern Chemins spars concerne le cas o une application dentreprise peut tre
constitue de plusieurs applications plus petites qui nont pas grand-chose ou rien en
commun dun point de vue modlisation. Il y a un seul jeu de spcifications et, vu de
lutilisateur, il sagit dune seule application, mais ct conception et modlisation,
cela peut tre fait en utilisant des modles spars avec des implmentations distinctes.
Ce quon devrait faire, cest regarder les spcifications et voir si elles peuvent tre
75

divises en deux ensembles ou plus qui nont pas grand-chose en commun. Si cest
ralisable, alors on peut crer des Contextes borns spars et les modliser
indpendamment. Cela a lavantage de nous donner la libert de choisir les
technologies utilises pour limplmentation. Les applications quon cre peuvent
partager une IHM fine commune qui agit comme un portail, avec des liens ou des
boutons qui servent accder chaque application. Cest une intgration mineure qui
a trait lorganisation des applications plutt quau modle sous-jacent.
Avant de partir sur des Chemins spars, nous devons nous assurer que nous ne
reviendrons pas un systme intgr. Les modles dvelopps indpendamment sont
trs difficiles rintgrer. Ils ont si peu en commun que a nen vaut simplement pas
la peine.

Service Hte ouvert

Lorsquon essaie dintgrer deux sous-systmes, on cre souvent une couche de
traduction entre les deux. Cette couche agit comme un tampon entre le sous-systme
client et le sous-systme externe avec lequel on essaie de sintgrer. Cette couche peut
tre plus ou moins cohrente, selon la complexit des relations et la manire dont le
sous-systme externe a t conu. Si ce dernier savre tre utilis non pas par un soussystme client, mais par plusieurs, on doit crer une couche de traduction pour chacun
dentre eux. Toutes ces couches vont rpter la mme tche de traduction, et contenir
du code similaire.
Quand un sous-systme doit tre intgr avec beaucoup dautres, fabriquer un
traducteur sur mesure pour chacun peut enliser lquipe. Il y a de plus en plus de
choses maintenir, et de plus en plus de choses dont il faut se soucier quand des
modifications sont faites.
La solution est de voir le sous-systme externe comme un fournisseur de services. Si
nous pouvons lenrober dun ensemble de Services, alors tous les autres sous-systmes
accderont ces Services, et nous naurons pas besoin de couche de traduction. La
difficult est que chaque sous-systme peut avoir besoin dinteragir de manire
spcifique avec le sous-systme externe, et crer un ensemble de Services cohrent
peut savrer problmatique.
Dfinissez un protocole qui donne accs votre sous-systme comme un ensemble de
Services. Ouvrez le protocole pour que tous ceux qui doivent sintgrer avec lui
puissent lutiliser. Amliorez et tendez le protocole pour grer de nouvelles ncessits
dintgration, sauf quand une quipe a des besoins idiosyncratiques. Dans ce cas,

76

utilisez un traducteur exceptionnel spar pour largir le protocole cette situation

particulire tout en gardant un protocole partag simple et cohrent.

Distillation
La distillation est le procd qui consiste sparer les substances qui composent un
mlange. Le but de la distillation est dextraire une substance particulire du mlange.
Pendant le processus de distillation, on peut obtenir des sous-produits, et ils peuvent
aussi avoir un intrt.
Un gros domaine aura un gros modle, mme aprs que nous layons raffin et cr
beaucoup dabstractions. Il peut rester volumineux mme suite de nombreux
refactorings. Dans une situation comme celle-l, il est peut-tre temps de distiller.
Lide est de dfinir un Cur de Domaine qui reprsente lessence du domaine. Les
sous-produits du processus de distillation seront des Sous-domaines gnriques qui
vont contenir dautres parties du domaine.
Dans la conception dun gros systme, il y a tellement de composants auxiliaires, tous
compliqus et tous absolument ncessaires au succs, que lessence du modle du
domaine, le vrai capital mtier, peut tre obscurci et nglig.
Quand on travaille avec un modle vaste, on devrait essayer de sparer les concepts
essentiels des concepts gnriques. Au dbut, nous avons donn lexemple dun
systme de surveillance du trafic arien. Nous avons dit quun Plan de Vol contenait la
Route quun avion est destin suivre. La Route semble tre un concept
continuellement prsent dans ce systme. Mais en ralit, ce concept est gnrique et
pas essentiel. Le concept de Route est utilis dans de nombreux domaines, et un
modle gnrique peut tre conu pour le dcrire.
Lessence de la surveillance de trafic arien se situe ailleurs. Le systme de contrle
connait la route que lavion doit suivre, mais il reoit aussi des informations dun
rseau de radars qui dtectent lavion dans le ciel. Ces donnes montrent le vritable
chemin suivi par lavion, et il est gnralement diffrent du chemin prescrit.
Le systme va devoir calculer la trajectoire de lavion en se basant sur ses paramtres
de vol actuels, les caractristiques de lavion et la mto. La trajectoire est un chemin
4 dimensions qui dcrit compltement la route que lavion va suivre au cours du
temps. La trajectoire peut tre calcule pour les deux minutes qui suivent, les quelques
dizaines de minutes venir ou les deux prochaines heures. Chacun de ces calculs
favorise le processus de prise de dcision. Tout lintrt de calculer la trajectoire de
lavion est de voir sil y a une chance pour que le chemin de cet avion en croise un
77

autre. Dans le voisinage des aroports, lors des dcollages et des atterrissages,
beaucoup davions font des cercles en lair ou manuvrent. Si un avion drive de sa
route prvue, il est fort possible quun crash se produise. Le systme de contrle du
trafic arien va calculer les trajectoires des avions, et diffuser une alerte sil y a la
possibilit dune intersection. Les aiguilleurs du ciel vont devoir prendre des dcisions
rapides, dirigeant les avions afin dviter la collision. Quand les avions sont plus
loigns, les trajectoires sont calcules sur de plus longues priodes, et il y a plus de
temps pour ragir.
Le module qui synthtise la trajectoire de lavion partir des donnes disponibles
constitue ici le cur du systme mtier. Il devrait tre dsign comme tant le cur de
domaine. Le modle de routage relve plus dun domaine gnrique.
Le Cur de Domaine dun systme dpend de la manire dont nous regardons ce
systme. Un systme de routage simple verra la Route et ses dpendances comme un
lment central de la conception. Le systme de surveillance du trafic arien
considrera la Route comme un sous-domaine gnrique. Le Cur de Domaine dune
application peut devenir un sous-domaine gnrique chez une autre. Il est important
didentifier correctement le Cur, et de dterminer les relations quil entretient avec
les autres parties du modle.
Faites rduire le modle. Trouvez le Cur de Domaine et proposez un moyen de le
distinguer facilement de la masse de modles et de code auxiliaires. Mettez laccent
sur les concepts les plus valables et les plus spcialiss. Adoptez un cur relativement
petit.
Mettez vos meilleurs talents sur le Cur de Domaine, et recrutez en consquence.
Concentrez vos efforts sur le Cur pour trouver un modle approfondi et dvelopper
un design souple suffisamment pour satisfaire la vision du systme. Justifiez les
investissements sur toute autre partie en les mettant en regard du bnfice apport au
Cur distill.
Il est important dassigner aux meilleurs dveloppeurs la tche dimplmenter le Cur
de Domaine. Les dveloppeurs ont gnralement tendance aimer les technologies,
apprendre le meilleur et tout dernier langage, tre attirs plus par linfrastructure que
par la logique mtier. La logique mtier dun domaine semble tre ennuyeuse et peu
gratifiante pour eux. Aprs tout, quoi bon apprendre les spcificits des trajectoires
davions ? Quand le projet sera termin, toute cette connaissance sera de lhistoire
ancienne,
et
aura
trs
peu
dintrt.
Mais la logique mtier du domaine est au centre de celui-ci. Des erreurs dans la
conception et limplmentation du cur peuvent mener labandon complet du projet.
Si la logique mtier centrale ne fait pas son travail, toutes les paillettes et dorures
technologiques ne vaudront rien.
78

Un Cur de Domaine ne se cre gnralement pas dun seul coup. Il y a un processus

daffinage et des refactorings successifs sont ncessaires avant que le Cur nmerge
plus clairement. Nous devons instaurer le Cur comme pice centrale du design, et
dlimiter ses frontires. Il nous faut par ailleurs repenser les autres lments du modle
en relation avec le nouveau Cur. Ceux-ci peuvent eux aussi avoir besoin dtre
refactors, et des fonctionnalits peuvent ncessiter des changements.
Certaines autres parties du modle ajoutent de la complexit sans pour autant capturer
ni communiquer une connaissance spcialise. Tout ce qui est sans rapport avec le
sujet rend le Cur de Domaine plus difficile discerner et comprendre. Le modle
sencrasse de principes gnraux que tout le monde connait, ou de dtails appartenant
des spcialits qui ne sont pas votre point de mire principal mais jouent un rle
auxiliaire. Pourtant, quelle que soit leur gnricit, ces autres lments sont essentiels
au fonctionnement du systme et lexpression complte du modle.
Identifiez les sous-domaines cohrents qui ne sont pas la motivation principale de
votre projet. Extrayez les modles gnriques de ces sous-domaines et placez-les dans
des Modules spars. Ny laissez aucune trace de vos spcialits. Une fois quils ont
t spars, donnez leur dveloppement permanent une priorit plus basse quau
Cur de Domaine, et vitez dassigner les dveloppeurs du cur ces tches (parce
quils y gagneront peu de connaissance mtier). Considrez aussi des solutions
disponibles dans le commerce ou des modles dj publis pour ces Sous-domaines
gnriques.
Tout domaine utilise des concepts qui sont utiliss par dautres domaines. Largent et
les concepts qui sy rattachent comme les devises et les taux de change se retrouvent
dans diffrents systmes. Les graphiques et diagrammes sont un autre concept
largement rpandu, trs complexe en lui-mme mais qui peut tre utilis dans
beaucoup dapplications.
Il y a diffrentes manires dimplmenter un Sous-domaine gnrique :
1. Solution du commerce. Celle-ci a lavantage que toute la solution ait dj t
ralise par quelquun dautre. Il y a toujours une courbe dapprentissage lie
au produit, et cette solution implique des dpendances. Si le code est bugg,
vous devez attendre quil soit corrig. Vous devez aussi utiliser des
compilateurs et des versions de librairies spcifiques. Lintgration ne se fait
pas aussi facilement compar un systme maison.
2. Sous-traitance. La conception et limplmentation sont confies une autre
quipe, probablement dune socit diffrente. Cela vous permet de vous
concentrer sur le Cur de Domaine, et vous enlve le fardeau dun autre
domaine traiter. Il y a toujours le dsagrment de devoir intgrer le code sous-

79

trait. Linterface utilise pour dialoguer avec le sous-domaine doit tre dfinie
et communique lautre quipe.
3. Modle existant. Une solution pratique consiste utiliser un modle dj cr.
Il existe certains livres qui ont publi des patterns danalyse, et ils peuvent tre
utiliss comme source dinspiration pour nos sous-domaines. Il se peut quil ne
soit pas possible de recopier les patterns ad litteram, mais beaucoup dentre eux
peuvent tre utiliss avec de petites modifications.
4. Implmentation maison. Cette solution a lavantage daccomplir le meilleur
niveau dintgration. Cela veut bien entendu dire des efforts supplmentaires, y
compris le fardeau de la maintenance.

80

81

6
DDD compte aujourdhui :
une interview dEric Evans
InfoQ.com interviewe le fondateur de Domain Driven Design, Eric Evans, pour
replacer DDD dans le contexte daujourdhui :

Pourquoi DDD est-il aujourdhui plus important que jamais ?

Fondamentalement, DDD est le principe selon lequel nous devrions nous concentrer
sur les enjeux profonds du domaine dans lequel nos utilisateurs sont impliqus, selon
lequel le meilleur de nos esprits devrait tre dvou la comprhension ce domaine, et
la collaboration avec les experts du domaine pour russir accoucher dune forme
conceptuelle que nous pouvons utiliser pour btir des logiciels flexibles et puissants.
Cest un principe qui ne passera jamais de mode. Il sapplique chaque fois que lon
opre dans un domaine complexe et trs labor.
La tendance sur le long terme est dappliquer linformatique des problmes de plus
en plus compliqus, de plus en plus profondment au cur de ces mtiers. Il me
semble que cette tendance sest interrompue pendant quelques annes, au moment o
nous connaissions lexplosion du web. Lattention tait dtourne dune logique riche
et de solutions approfondies, tant il y avait de valeur dans le simple fait de mettre sur
le web des donnes avec un comportement trs basique. Il y avait beaucoup faire en
la matire, et mme raliser des choses simples sur le web a t difficile pendant un
moment, donc cela a absorb tout leffort de dveloppement.
Mais maintenant que le niveau basique dutilisation du web a largement t assimil,
les projets commencent se faire de nouveau plus ambitieux sur la logique mtier.
Trs rcemment, les plateformes de dveloppement web ont commenc tre
suffisamment mres pour rendre le dveloppement web assez productif pour DDD, et

82

il y a un certain nombre de tendances positives. Par exemple, lapproche SOA, quand

elle est bien utilise, nous fournit une faon trs pratique disoler le domaine.
Dans le mme temps, les processus Agiles ont eu assez dinfluence pour que la plupart
des projets actuels aient au moins lintention de faire des itrations, de travailler
troitement avec les partenaires mtier, dappliquer lintgration continue, et de
travailler dans un environnement fortement communicant.
DDD parait donc de plus en plus important pour le futur prvisible, et il semble que
des fondations soient en place.
Les plateformes technologiques (Java, .NET, Ruby et autres) sont en constante
volution. Comment Domain Driven Design se situe-t-il par rapport cela ?
En fait, les nouvelles technologies et les nouveaux processus devraient tre jugs sur
leur capacit aider les quipes se concentrer sur leur domaine, plutt que de les en
distraire. DDD nest pas spcifique une plateforme technologique, mais certaines
plateformes donnent des moyens plus expressifs de crer de la logique mtier, et
certaines plateformes ont moins dencombrements parasites. Vis--vis de ce dernier
caractre, les quelques dernires annes montrent une direction optimiste,
particulirement aprs laffreuse fin des annes 90.
Java a t le choix par dfaut ces dernires annes ; pour ce qui est de son expressivit,
elle est typique des langages orient objet. En ce qui concerne les encombrements
parasites, le langage de base nest pas trop mauvais. Il offre la garbage collection, ce
qui en pratique savre essentiel. (Contrairement au C++, qui exigeait daccorder trop
dattention aux dtails de bas niveau.) Il y a du fouillis dans la syntaxe Java, mais il y
a toujours moyen de rendre lisibles des plain old java objects (POJOs). Et certaines
des innovations de syntaxe de Java 5 favorisent la lisibilit.
Mais quand le framework J2EE est paru pour la premire fois, il enterrait littralement
cette expressivit basique sous des montagnes de code du framework. En suivant les
premires conventions (comme EJB Home, les accesseurs prfixs par get/set pour
toutes les variables, etc.), on produisait des objets affreux. Les outils taient si lourds
que le simple fait de les faire marcher absorbait toute la capacit des quipes de
dveloppement. Et il tait si difficile de changer les objets, une fois que le gigantesque
fatras de code gnr et de XML avait t rgurgit, que les gens ne faisaient pas
beaucoup de modifications. Cette plateforme rendait une modlisation du domaine
efficace pratiquement impossible.
Il faut ajouter cela limpratif de produire des IHM web convoyes par http et html
(qui nont pas t conus dans cet objectif), en utilisant des outils de premire
gnration quelque peu primitifs. Pendant cette priode, crer et maintenir une
interface utilisateur dcente tait devenue si difficile quil restait peu dattention
83

accorder la conception de fonctionnalits internes complexes. Lironie de la chose,

cest quau moment mme o la technologie objet prenait le pouvoir, la modlisation
et la conception sophistiques prenaient un svre coup sur la tte.
La situation tait similaire sur la plateforme .NET, o certaines problmatiques taient
un peu mieux traites, et dautres un peu moins bien.
Ce fut une priode dcourageante, mais la tendance sest inverse au cours des quatre
dernires annes environ. Dabord, si lon regarde Java, il y a eu la convergence dune
nouvelle sophistication dans la communaut sur la manire dutiliser les frameworks
de faon slective, et dune mnagerie de nouveaux frameworks (open source pour la
plupart) qui samliorent incrmentalement. Des frameworks comme Hibernate et
Spring grent des tches spcifiques que J2EE essayait de traiter, mais de faon bien
plus lgre. Des approches comme AJAX tentent de sattaquer au problme de
linterface utilisateur de manire moins laborieuse. Et les projets sont beaucoup plus
intelligents maintenant dans leurs choix dutiliser les composants de J2EE qui leur
apportent de la valeur, en y incorporant certains de ces autres lments plus rcents.
Cest pendant cette re que le terme POJO a t propos.
Le rsultat, cest une diminution incrmentale mais sensible des efforts techniques des
projets, et une amlioration distincte dans lisolation de la logique mtier du reste du
systme afin quelle puisse tre crite en termes de POJOs. Ca ne produit pas
automatiquement une conception dirige par le domaine, mais cela en fait une
opportunit raliste.
Voil pour le monde Java. Ensuite, vous avez les nouveaux arrivants comme Ruby.
Ruby a une syntaxe trs expressive, et sur ce plan fondamental ce devrait tre un trs
bon langage pour DDD (bien que je naie pas encore entendu parler de beaucoup
dutilisations relles de DDD dans ce genre dapplications.) Rails a gnr beaucoup
dexcitation parce quil semble finalement rendre la cration dinterfaces web aussi
facile que les IHM ltaient au dbut des annes 90, avant le Web. Aujourdhui, cette
capacit a surtout t exploite dans la construction dapplications web faisant partie
de celles, trs nombreuses, qui nont pas une richesse de domaine trs importante
derrire elles ; et pour cause, mme celles-ci taient douloureusement compliques
dans le pass. Mais jai espoir quavec la diminution de laspect implmentation IHM
du problme, les gens y verront une opportunit de focaliser davantage leur attention
sur le domaine. Si jamais lutilisation de Ruby commence prendre cette direction, je
pense quil pourrait constituer une excellente plateforme pour DDD. (Quelques pans
dinfrastructure devraient probablement tre combls.)
Sur des problmatiques plus pointues, il y a les efforts dans le champ des domainspecific languages (DSLs), dont je pense depuis longtemps quils pourraient tre le
prochain grand pas pour DDD. A cette date, nous navons toujours pas doutil qui nous
84

donne rellement ce que nous attendons. Mais les gens font plus dexpriences que
jamais dans ce domaine, et cela me donne espoir.
Aujourdhui, pour autant que je sache, la plupart des gens qui tentent dappliquer DDD
travaillent en Java ou .NET, et quelques-uns en Smalltalk. Donc cest la mouvance
positive du monde Java qui profite des effets immdiats.
Que sest-il pass dans la communaut DDD depuis que vous avez crit votre livre ?
Quelque chose qui me passionne, cest quand les gens prennent les principes dont jai
parl dans mon livre et les utilisent dune manire que je naurais jamais souponne.
Il y a par exemple lutilisation du design stratgique chez StatOil, la compagnie
nationale de ptrole norvgienne. Les architectes l-bas ont crit un retour
dexprience

ce
propos.
(Vous
pouvez
le
lire

ladresse
http://domaindrivendesign.org/articles/.)
Entre autres, ils ont pris la carte de contexte et lont applique lvaluation de
logiciels du march dans des prises de dcisions achat/ralisation.
Pour citer un exemple assez diffrent, certains dentre nous ont explor dautres
problmatiques en dveloppant une bibliothque de code Java contenant quelques
objets du domaine fondamentaux dont ont besoin beaucoup de projets. Les gens
peuvent consulter tout a ladresse :
http://timeandmoney.domainlanguage.com
Nous avons explor, par exemple, jusquo lon peut pousser lide dun langage
fluent spcifique au domaine, tout en continuant implmenter les objets en Java.
Il y a pas mal de choses qui se passent. Japprcie toujours quand des personnes me
contactent pour me faire part de ce quils font.
Avez-vous des conseils pour les gens qui essaient dapprendre DDD aujourdhui ?
Lisez mon livre ! ;-) Essayez aussi dutiliser Timeandmoney dans votre projet. Un de
nos objectifs dorigine tait de proposer un bon exemple grce auquel les gens
pourraient apprendre en lutilisant.
Une chose quil faut avoir en tte, cest que DDD est principalement pratiqu au
niveau de lquipe, donc au besoin vous devrez peut-tre vous faire vanglisateur. Sur
un plan plus raliste, vous pourriez aussi chercher un projet o les gens font dj un
effort pour faire du DDD.
Gardez lesprit certains piges de la modlisation de domaine :
1)

Gardez la main. Les modlisateurs ont besoin de coder.

85

2)

Concentrez-vous sur des scnarios concrets. La rflexion abstraite doit tre

ancre dans des cas concrets.

3)

Nessayez pas dappliquer DDD tout. Tracez une carte de contexte et dcidez
o vous allez faire des efforts sur DDD ou pas. Ensuite, ne vous en souciez pas
hors de ces limites.

4)

Exprimentez beaucoup et attendez-vous faire beaucoup derreurs. La

modlisation est un processus cratif.

86

A propos dEric Evans

Eric Evans est lauteur de "Domain-Driven Design: Tackling Complexity in
Software," Addison-Wesley 2004.
Depuis le dbut des annes 90, il a travaill sur de nombreux projets, dveloppant de
larges systmes mtier en objet, avec de nombreuses approches et rsultats diffrents.
Le livre est une synthse de cette exprience. Il prsente un systme de techniques de
modlisation et conception que des quipes ont utilises avec succs pour aligner des
systmes logiciels complexes sur les besoins mtier et garder des projets agiles quand
les systmes deviennent plus gros.
Eric dirige maintenant Domain Language , un groupe de consulting qui coache et
forme les quipes appliquer Domain Driven Design, et les aide rendre leur travail
de dveloppement plus productif et plus utile pour le mtier.

87

Lexique franais-anglais des termes DDD

Agrgat

Aggregate

Avance majeure

Breakthrough

Carte de Contexte

Context Map

Chemins spars

Separate Ways

Cur de Domaine

Core Domain

Conception dirige par le modle

Model-Driven Design

Contexte born

Bounded Context

Couche anticorruption

Anticorruption Layer

Entit

Entity

Entrept

Repository

Fabrique

Factory

Fabrique abstraite

Abstract Factory

Langage omniprsent

Ubiquitous Language

Mthode de fabrication

Factory Method

Modle du domaine

Domain Model

Noyau partag

Shared Kernel

Objet-Valeur

Value Object

Racine dagrgat

Aggregate Root

Service Hte ouvert

Open Host Service

Sous-domaine gnrique

Generic Subdomain

88