Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Les hexagones de la Ruche qui dit Oui !

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

70a6e5c61ba886bbdea1401197def8c7?s=128

Benoît Merlet

October 27, 2017
Tweet

More Decks by Benoît Merlet

Other Decks in Technology

Transcript

  1. LES HEXAGONES DE LA RUCHE QUI DIT OUI ! Benoît

    Merlet ‒ benoit@lrqdo.fr ‒ @trompouet
  2. None
  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

  19. None
  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