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
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
4. Été 2015 NOTRE BASE DE CODE
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
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
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.
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
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
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
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 ?
12. Première tentative de modularisation LES MICROSERVICES
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
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.
15. ATTENTION AVANT DE CÉDER À UNE MODE ! https://martinfowler.com/bliki/MicroservicePrerequisites.html https://twitter.com/ircmaxell
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.
17. RÉVÉLATION : MODULAIRE ≠ DISTRIBUÉ https://twitter.com/simonbrown http://www.codingthearchitecture.com/presentations/sa2015-modular-monoliths
18. Seconde tentative de modularisation LES HEXAGONES
20. ARCHITECTURE HEXAGONALE http://alistair.cockburn.us/Hexagonal+architecture
21. UN DE NOS HEXAGONES Survey API Persistence Notification Symfony Controllers Doctrine Repositories Mailer based on SwiftMailer CLI Symfony Commands
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
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
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
25. Aujourd’hui RETOUR D'EXPÉRIENCE
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.
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.
28. CHEMIN PARCOURU Monolithe Monolithe Service Monolithe Service
29. Merci ! https://joind.in/talk/b7a0f