All Archiectures Versus

Layered Architecture

Traditionnellement, nous avons la Presentation qui connait et dépend du Business qui connait et dépend de la Persistance.

Mais que se passe-t-il si nous décidons d’inverser la dépendance entre la Logique métier et la Persistance ?

• La partie Business appelle toujours la couche Data Access
• Mais ne la connait plus qui est appelé (fichier, base de données, in-memory, ?), elle partie métier devient indépendante

Comment ?

Pour ce faire :

• la partie Business (Service) dépend d’une interface (IRepository) qui est implémenté par la couche de Persistance (Repository)
• Et c’est en positionnant IRepository dans Business (et non dans Data Access) nous inversions la dépendance

Hexagonale

Nous avons la naissance du patron architectural Port/Adapter (ou Hexagonale). En effet :

• l’interface IRepository est un Port
• l’implémentation Repository un adaptateur

Par conséquent, le coeur applicatif n’a aucune dépendance; aucune référence vers le monde externe

Onion

Le coeur applicatif peut lui être divisé en différente couche (layers) avec des dépendances qui ne pointent que vers l’intérieur

Clean Architecture

La Clean Architecture reprend l’ensemble de ces idées pour y donner du sens. On va y nommer les couches

Conclusion

• Fondamentalement, l’architecture hexagonale (alias Ports/Adaptateurs) définit le cœur (logique métier) et la périphérie (services et composants externes) sans rien dire de la structure interne du cœur.
• Ses descendants, les architectures Onion et Clean, entrent dans les détails de la structuration du coeur en le divisant en plusieurs couches, conformément aux principes DDD.