Mes observations à propos de l'architecture

“propre/hexagonale”http://thegreenbar.wordpress.com/

Motivation

Robert C. Martin : http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html

Cyril Martraire : https://www.parleys.com/tutorial/coder-sans-peur-du-changement-avec-la-meme-pas-mal-architecture-hexagonale

L'architecture hexagonal en 30 secondes

Code métier (domain) séparé du code de l'infrastructure

Dépendances à sens unique (de l'infrastructure vers le métier)

Le code infra appelle des API métier (“ports”) et implémente des interfaces métier (“adapters”)

Mon approche

Patterns Utiles

CRUD: Service (domain) → Stockage (infra)Tests avec mocks au niveau service, avec une

vraie base de données au niveau stockageTests dans AbstractXXXStorageTest (domain)

avec setUp() dans sous-classe PostgresXXXStorageTest

Controlleur de session (infra?)

Patterns Utiles

Difficultés rencontrées et limitations

Logging (infra ou domain?) Extraire des composants de bas niveau (dépendances

métier à démêler) Interdiction des annotations Java EE dans le code métier Zones de gris (ex: controlleur – métier ou infra?) Même le choix du langage (Java, pour mon cas) impose

certains choix d'infrastructure pour la partie métier.

Points positifs

Facile de remplacer un élément infra (ex: remplacer Postgres par MongoDb, sans changer le code métier et sans ré-écrire les tests)

Code plus propre (code métier non-pollué par le code de l'infrastructure)

Possibilité de décaler les décisions sur l'infrastructure Plus facile de réutiliser le code métier dans d'autres projets Développement infra dirigé par les cas d'utilisation métier

(YAGNI) Facilite IoC et DI → code plus propre

Points négatifs

Difficile de tirer à max les avantages des frameworks – ex: pas d'annotations Java EE, Spring ou ORM dans le code métier.

Ne peut pas optimiser le code métier pour une infrastructure spécifique.

Un changement dans la logique métier peut toucher plusieurs endroits dans le code infra.

Complexité et redondance dans le TDD – un cas d'utilisation doit être testé à plusieurs endroits pour arriver de bout en bout.

Hexagonal et Microservices

Pas la même chose Hexagonal: découpage entre métier et

infra Microservices: découpage du métier en

morceaux Selon Martin Fowler, pas faisable de démarrer un projet

en microservices du début – besoin de créer une appli complèxe et le découper petit à petit

Donc le passage Hexagonal → Microservices a l'avantage d'une séparation du métier et infra pour plus facilement découper le métier.

Conclusion

La séparation entre métier et infra réduit la complexité “accidentelle”

Une bonne approche pour la plupart des projets de dev, sauf si:

tout petit projet Prototype jetable Besoin fort d'optimiser pour une

infrastructure spécifique