Architecture héxagonale

Human Talks Lyon

11 octobre 2016

en 10 minutes !

Jean Detoeuf

Développeur

Passionné de nouvelles technologies

#jvm #docker #craftsmanship #rpi #diy

Qui a déjà tenté de changer de framework (DI, ORM, ...) ?

C'est galère ?

  • Code framework au milieu du code métier
  • Difficulté pour changer de framework
  • Tests trop lourds

Architecture en couche

  • Simple à comprendre
  • Montre le flux de données

Architecture en couche

  • Simple avec une couche de présentation et une couche de persistence
  • Les couches se mélangent dans le code

Architecture héxagonale

  • Permet d'isoler le code métier du code d'infrastructure
  • Agnostique : amenez votre langage préféré
  • Framework killer

Lancement d'un projet

  • Reporter les choix techniques
  • Connaissance métier limitée en début de projet

Concept

  • Code métier sans bibliothèque ni framework
  • Code technique dans des modules séparés

Tests simplifiés

  • Découpage des taches simplifié
  • TDD : dev/test métier, puis autres modules
  • Tests métier sans avoir à gérer l'infra
  • Validation rapide du métier

On commence quand ?

  • nouveau projet : simple à mettre en place
  • projet existant : démêlage de spaghettis

Perspectives

  • Changer de framework
  • Changer de BDD
  • Migrer une partie des données (ie. SQL vers NoSQL)
  • Ajouter une interface (API, messaging, autre IHM)

Perméabilité

  • Impossible d'utiliser du code "infra" dans le module "métier"
  • Rien n'empêche d'avoir du code "métier" qui se retrouve dans les modules "infra"

Retour d'expérience

  • C'est le code "métier" qui va diriger le code "infra"
  • Penser à la performance (ie requête SQL dans une boucle)

Dans quels cas ne pas l'utiliser

  • Framework
  • Librairie
  • Module technique

Premier pas vers le DDD

  • Faire communiquer plusieurs héxagones, chacun représentant un métier séparé
  • Un amateur pour faire une présentation du DDD ?

Questions ?

Merci pour votre écoute