Le Mythe du framework agile

Agile * 2013

Jean-Baptiste Dusseaut, arpinum.fr / @bodysplash

Arpinum

Le gros framework d'entreprise

Les remarques entendues…

  • C'est compliqué
  • C'est difficile à tester
  • C'est bugué
  • Le support est déplorable
  • Si un cas n'est pas prévu, il faut hacker dans tous les sens pour s'en sortir

Mais quelle(s) différence(s) avec ?

  • Play ?
  • Rails ?
  • Roo ?
  • Grails ?
  • Cake ?
  • Django ?

Les promesses

  • Prend les décisions de module pour vous
  • Prend les décisions de sécurité pour vous
  • Plein de documentation
  • Système de plugin
  • Enorme communauté

Et aussi...

  • Interface d'admin automatique
  • Migration de schéma
  • Authentification
  • Sessions et cookies
  • Internationalization

Mais...

La règle des 80/20

  • Passer 2 mois à écrire 80% de votre application
  • Passer 8 mois à écrire les 20% restants

Les comportements que cela encourage

  • «Fat» contrôleurs
  • Passé le hello world, le ticket d'entrée n'est pas si petit
  • Encourage l'émergence d'une application monolithique
  • Le métier est très fortement couplé à la base
  • Le métier est très fortement couplé à la manière de le représenter
  • Difficultés de mise à jour

Un framework, c'est lui qui vous utilise

MVC n'est pas une architecture

!=

Mais qu'est-ce donc une bonne architecture ?

  • Permet de retarder les décisions
  • Minimise le couplage
  • Facile à changer
  • Testable !

Inspirations

  • DDD !
  • Architecture hexagonale
  • CQRS
  • Clean architecture
  • Et bien d'autres

Mettre le(s) métier(s) au coeur des préoccupations

«Stable dependencies principle»

  • Accepte parfaitement le TDD
  • La base de données n'existe pas

Encapsuler les cas d'utilisation dans des commandes

  • Permet de brancher facilement n'importe quoi (Web, Socket, Tests d'acceptation)
  • Peut permettre de déduire de meilleures interfaces graphiques
  • Éventuellement exécutable sur un autre serveur
  • Accepte parfaitement du TDD
  • La base de données n'existe pas

Mettre la lecture dans un autre modèle

  • Évite de brouiller le métier avec des considérations d'affichage
  • Permet de demander à la base ce qu'elle sait faire de mieux : recherche, indexation, full text, etc
  • Un peu plus difficile à tester :(
  • Devoir garder deux modèles en cohérence si on attaque la même source de données :(

Un service REST

  • Une certaine similarité de forme avec les concepts DDD
  • Accepte facilement éventuellement des tests de haut niveau
  • Accepte parfaitement le TDD
  • La base de données n'existe pas

Assemblage de l'ensemble au runtime

  • Tout est dans le code, pas de conventions plus ou moins tordues à se rappeler
  • C'est simple, pas simpliste

Et exposons ça dans une jolie application

Pour conclure

  • Avons-nous respecté les critères d'une bonne architecture ?
  • C'était pas si compliqué finalement
Are we really so naive as to think that the best way to write a complex system is to throw a bunch of components into a bag and shake it until it works?
Uncle Bob