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