Les hexagones de la Ruche qui dit Oui !

Présentation pour le Forum PHP 2017 : https://event.afup.org/forumphp2017/programme/#2314

Malgré une douloureuse ré-écriture en partant de zéro, le site de la Ruche qui dit Oui ! n'avait toujours pas d'architecture évidente permettant de faciliter les évolutions fonctionnelles et techniques.

Afin d'éviter une nouvelle "big ball of mud" difficile à maintenir, l'équipe a décidé l'année dernière de procéder à la migration continue de notre architecture vers un ensemble d'hexagones.

Chaque hexagone est en réalité un module bien borné et bien découplé au sein d'un monolithe, ce qui nous permet de ne pas céder aveuglément à la mode des microservices !

Voyons ensemble comment cette migration continue a débuté, quels sont les pièges à éviter et bien sûr quels bénéfices nous en retirons au quotidien.

Capture vidéo : https://www.youtube.com/watch?v=nR4Ssp4d1gE

Transcript

1. LES HEXAGONES
   DE LA RUCHE QUI DIT OUI !
   Benoît Merlet ‒ benoit@lrqdo.fr ‒ @trompouet
   

   View Slide

2. View Slide

3. 170 000
   Membres actifs
   30 000
   Commandes
   par semaine
   4 500
   Producteurs
   1 200
   Ruches
   9
   Pays
   20
   Personnes dans
   l’équipe technique
   1 000
   Distributions
   par semaine
   

   View Slide

4. Été 2015
   NOTRE BASE DE CODE
   

   View Slide

5. DE BONNES INTENTIONS
   Monolithe dont la conception a été
   pilotée par le métier (DDD)
   ● architecture en couches
   ● patrons de conception
   ● framework absent du domaine
   ○ vrai pour Symfony
   ○ moins évident pour Doctrine
   

   View Slide

6. C’est une approche du développement
   logiciel.
   Les postulats sont :
   ● de se focaliser sur le métier
   ● de modéliser le métier
   ● de collaborer avec le métier
   DOMAIN-DRIVEN DESIGN
   

   View Slide

7. ICI, LE MÉTIER EST CACHÉ
   Après avoir ouvert une profondeur de
   trois niveaux de répertoires, seule la
   technique se dévoile.
   En explorant la couche domaine, les
   différents sous-domaines ne sont pas
   évidents à deviner.
   

   View Slide

8. LE CODE EST ORGANISÉ VERTICALEMENT
   $ find src/ -mindepth 3 -maxdepth 3 -type d \
   > |while read d; do echo $(find $d -name '*.php' |wc -l) $d; done \
   > |sort -rn \
   > |head -10
   384 src/Lrqdo/Application/ApiBundle
   251 src/Lrqdo/DomainBundle/DoctrineMigrations
   234 src/Lrqdo/Domain/Criterium
   176 src/Lrqdo/Domain/Service
   155 src/Lrqdo/Application/AdminBundle
   151 src/Lrqdo/DomainBundle/Form
   147 src/Lrqdo/Domain/Model
   80 src/Lrqdo/Application/CliBundle
   76 src/Lrqdo/Domain/Repository
   54 src/Lrqdo/Application/EmailBundle
   

   View Slide

9. LE CODE À FAIRE ÉVOLUER EST DIFFICILE À TROUVER
   $ find src/ -name '*.php' \
   > |xargs -n 1 wc -l \
   > |sort -rn \
   > |head -10
   1913 src/Lrqdo/Domain/Repository/DistributionRepository.php
   1425 src/Lrqdo/Domain/Model/Entity/Hive.php
   1424 src/Lrqdo/Domain/Model/Entity/Company.php
   1370 src/Lrqdo/Domain/Model/Entity/Distribution.php
   1331 src/Lrqdo/Domain/Model/Entity/Order.php
   1113 src/Lrqdo/Domain/Model/Entity/Farm.php
   831 src/Lrqdo/Domain/Repository/OrderRepository.php
   760 src/Lrqdo/Domain/Model/Entity/Product.php
   715 src/Lrqdo/Application/ApiBundle/Controller/DistributionController.php
   642 src/Lrqdo/Application/ApiBundle/Controller/ProductController.php
   

   View Slide

10. NOS PRATIQUES DOIVENT CHANGER
    Nos besoins :
    ● mettre en évidence les sous-domaines
    ● clarifier les interactions entre sous-domaines
    ● grossir horizontalement plutôt que verticalement
    ● rassembler le code qui implémente une fonctionnalité
    Notre objectif :
    Limiter la charge cognitive lorsque nous modifions du code
    

    View Slide

11. RÉVÉLATION : LA NOTION DE « BOUNDED CONTEXT »
    https://martinfowler.com/bliki/BoundedContext.html
    L’idée est de définir des groupes de
    fonctionnalités et d’expliciter leurs
    interactions.
    La taille importe peu, ce qui importe
    est de définir un contrat pour le
    monde extérieur.
    Comment faire techniquement ?
    

    View Slide

12. Première tentative de modularisation
    LES MICROSERVICES
    

    View Slide

13. EXTRACTION D’UN PREMIER SERVICE
    Le positif :
    ● un commit tous les 10 jours
    ● une release tous les 2 mois
    ● la majorité des développeurs n’ont jamais cloné ce dépôt
    

    View Slide

14. CONSÉQUENCES MALHEUREUSES
    Le nouveau service apporte son lot de complexité :
    ● pendant le développement
    ● pour comprendre l’architecture globale
    ● pour le faire communiquer avec le monolithe
    ● pour déployer et opérer l’ensemble de l’architecture
    Le nouveau service reste couplé au monolithe : la base de données est partagée.
    

    View Slide

15. ATTENTION AVANT DE CÉDER À UNE MODE !
    https://martinfowler.com/bliki/MicroservicePrerequisites.html
    https://twitter.com/ircmaxell
    

    View Slide

16. NOTRE SEUL MICROSERVICE À CE JOUR
    Nous voulons extraire des services métiers et nous anticipons des difficultés :
    ● les dépendances (découverte automatique ?)
    ● la communication (un bus ?)
    ● la cohérence (à terme ?)
    ● le monitoring
    ● l’orchestration
    Notre équipe est de taille trop modeste pour le moment.
    

    View Slide

17. RÉVÉLATION : MODULAIRE ≠ DISTRIBUÉ
    https://twitter.com/simonbrown
    http://www.codingthearchitecture.com/presentations/sa2015-modular-monoliths
    

    View Slide

18. Seconde tentative de modularisation
    LES HEXAGONES
    

    View Slide

19. View Slide

20. ARCHITECTURE HEXAGONALE
    http://alistair.cockburn.us/Hexagonal+architecture
    

    View Slide

21. UN DE NOS HEXAGONES
    Survey
    API
    Persistence
    Notification
    Symfony
    Controllers
    Doctrine
    Repositories
    Mailer based
    on SwiftMailer
    CLI
    Symfony
    Commands
    

    View Slide

22. Le fonctionnel est bien borné.
    On retrouve :
    ● du code objet découplé
    ● des interfaces claires
    ● des patrons de conception
    Ce code est autonome donc facilement
    testable unitairement.
    CODE MÉTIER
    

    View Slide

23. CODE TECHNIQUE
    Par convention, nous utilisons un
    répertoire nommé Bridge.
    On y retrouve :
    ● les dépendances techniques
    ● les implémentations des interfaces
    ● les configurations des outils
    

    View Slide

24. Quelques conseils pratiques
    Introduire des événements
    métiers
    D’autres contextes pourront réagir
    comme ils le souhaitent
    Éviter de coupler les différents
    contextes
    Une relation Doctrine n’est pas
    obligatoire, une référence peut suffire
    Écrire du code qui est facile à
    supprimer
    Plutôt qu’écrire du code qui est facile
    à étendre
    Définir des objets valeurs pour
    les références
    Tout concept représentant une valeur
    mérite d’être explicité
    Nommer de la même manière
    les mêmes concepts
    Sans pour autant utiliser la même
    classe omnisciente
    

    View Slide

25. Aujourd’hui
    RETOUR D'EXPÉRIENCE
    

    View Slide

26. OBJECTIF ATTEINT
    ● les sous-domaines sont évidents
    ● le code à modifier est facile à trouver
    ● le code métier est facile à tester
    ● le code grossit de manière contrôlée
    ● la dette technique se résorbe
    Nous avons réussi à limiter la charge
    cognitive lorsque nous modifions
    du code.
    

    View Slide

27. AVIS DE L’ÉQUIPE
    On a plein de
    sous-domaines, c’est plus
    clair pour tout le monde,
    ancien développeur
    comme nouveau
    développeur.
    C’est vraiment plus
    confortable d’avoir du code
    dont on ne se soucie pas car
    il n’est pas dans le même
    sous-domaine.
    Maintenant quand on
    modifie du code, on
    est bien plus confiant
    car les fonctionnalités
    sont cloisonnées.
    Les « Pull Requests » sont
    moins dispersées, le code
    modifié est localisé dans le
    même dossier ce qui rend la
    relecture plus simple.
    C’est génial d’avoir de la
    visibilité sur les services
    métier qu’on pourrait extraire
    si on décidait de se remettre
    aux microservices.
    

    View Slide

28. CHEMIN PARCOURU
    Monolithe Monolithe
    Service
    Monolithe
    Service
    

    View Slide

29. Merci !
    https://joind.in/talk/b7a0f
    

    View Slide