1. G. Saint Etienne & Thierry Cros
très fortement inspiré par Uncle Bob
*

2. *
*Disposition, ordonnance d'un édifice.
Architecture Foundation London, by Zaha Hadid

3. *

4. *
*Uncle Bob says

5. *

6. *

7. *

10. dependencies between software
packages in the Gentoo Linux operating
system. In total there are 14319 packages
with 63988 dependencies between them!

11. *

12. *

13. *
*A quick view

23. *
*Quelques rappels
*Êtes vous S.O.L.I.D. ?

24. *
*Object Encapsulation
*Inheritance
*Polymorphism
*Single Responsability Principle

25. *
*Open Close Principle
*Ouvert aux extensions / Fermé aux modifications
*Interface Segregation Principle
*Un composant ne doit jamais être forcé de dépendre d’une interface (ou un
package) qu’il n’utilise pas
*Dependency Inversion Principle
*Les éléments de « haut » niveau ne doivent pas dépendre des
éléments de « bas » niveaux
*Les abstractions ne doivent pas dépendre des détails (implémentations)

26. *
*Du spaghetti …
*… Au multiples couches

28. *

29. *
*La granularité de la réutilisation est la
granularité de ce que est livré/livrable.
*Ne ré-utilisez rien qui ne soit livrable
indépendamment.
*Ré-utilisez si vous pouvez vous sentir comme
un simple consommateur d’un livrable.

30. *
*Ensemble dans le même package si (ré)utilisés
en même temps

31. *
*Si 2 classes changent ensemble alors elles
devraient se retrouver ensemble dans le même
package.
*Similaire à Open Close Principle
*Gain en maintenabilité.

32. *

33. *
*Stable Dependencies Principle (SDP)
*Moins un package est stable, moins il devrait y avoir de
dépendances vers lui (moins de couplage).
*Stable Abstractions Principle (SAP)
*Les packages ne contenant que des abstractions doivent être
les plus stables possibles.
*Forte Cohérence Interne / Faible Couplage Externe

34. Concepts
d'architecture
Concepts
d'implémentation
Détails
d'implémentation
Dépendances
Ne dépendent que
d'autres concepts
d'architecture
Peuvent dépendre
de concepts
d'architecture ou de
d'autres concepts
d'implémentation
Dépendent de
concepts
d'architecture et de
concepts
d'implémentation
Niveau
d'abstraction
Entièrement
abstraits
Mélange
d'abstraction et de
détails
Entièrement
composés de détails
Niveau de stabilité Stabilité maximale Partiellement stable
Change au moindre
changement dans le
logiciel

35. *
*Let’s code for real

36. *
*A good architecture allows major decisions to be defered
*What and how to instanciate
*How display it
*How store it ….
*A good architecture maximes the number of decision not
made

37. *
*Independant of Frameworks
*Fully and Unit Testable… and very fast!
*Independant of UI
*Independant of Database
*Independant of any External Agency

39. *
*A l’extérieur: l’infrastructure, les services externes
*la persistence, l’UI en font partie
*A l’intérieur: la description des comportements et
des entités
*Dépendances: de l’extérieur vers l’intérieur
seulement

40. *Les entités
*On en parle demain dans « TDD vs DBO »
*Uses cases
*Ce sont des « Application business rules »
*Jamais impacté par les changements externes (UI, DB, etc…)
*Interface Adapters
*Convertissent les entités vers des formats
adaptés aux infrastructures
*Frameworks & Drivers
*Fournissent des services (persistence,
présentation, quincaillerie en tous genre)

41. * Always remember

42. *
* http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html
* http://blog.kamil.dworakowski.name/2010/08/from-layers-to-hexagon-
architecture.html
* http://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle
* http://www.objectmentor.com/resources/articles/granularity.pdf
* http://java.boot.by/scea5-guide/ch01.html
* Dojos
* https://github.com/martinsson/DevelopersAnonymous/blob/master/c%23/Guild
edRose/GildedRose.cs