Il nous paraît évident qu’implémenter des solutions d'architecture plus complexes telles que l'hexagonal, le CQRS, voire même le DDD nécessite une réflexion approfondie et que l'utilisation de ces patterns se doit d’être soigneusement considérée.
De nos jours, le Modèle-Vue-Contrôleur ou MVC semble faire office d’exception, ayant acquis ces dernières années un véritable passe-droit, il s’impose désormais comme un choix d’architecture par défaut … où disons le autrement, par habitude.
Avez-vous réellement considéré les choix qui s’offraient à vous et les contraintes de votre business avant même de créer votre premier controller ?
Le MVC a comme principale force de proposer un cadre relativement généraliste ne se limitant pas à des choix architecturaux spécifiques, cette souplesse est également sa plus grande faiblesse, le MVC ne répond à aucune contrainte ou orientation spécifique.
Un mariage
Nous avons progressivement considéré qu’un framework était une architecture à part entière, nous avions tort, un framework est seulement un ensemble de composants ne connaissant pas vos préoccupations, répondant à un besoin généraliste.
La relation que vous entretenez avec votre framework est probablement à sens unique et nous nous rendons trop facilement dépendants de ce dernier.
En adoptant un framework, vous vous engagez envers celui-ci, tandis que les créateurs du framework ne prennent aucun engagement envers vous, à vos risques et périls.
Le framework que vous utilisez n'est qu'un détail de votre application, cette idée, qui me paraissait auparavant saugrenue vous apparaîtra comme une évidence dès lors que votre application aura atteint une taille critique et détiendra une grande richesse fonctionnelle.
Une fois empêtré dans un framework il sera difficile, voir tout simplement impossible, de vous en défaire sans peine, surtout si les composants de votre application sont fortement couplés à ce dernier.
Certes, ce mariage est dans une certaine mesure inéluctable, par exemple, il sera probablement inintéressant financièrement ou techniquement de réécrire vous-même une solution de routing pour votre application plutôt que d’utiliser celle fournis par un framework, en plus d’être une perte de temps il est fort à parier que votre solution sera moins fonctionnelle et efficace.
Ce mariage doit cependant être considéré en tout état de cause et dûment réfléchi car il est fort probable que ce choix impactera l’entièreté de la vie de votre application.
En définitive, gardez en tête que votre logique métier est bien plus précieuse et cruciale que le nom de votre framework.
Vous ne vendez pas à vos clients l’utilisation de telle ou telle technologie mais la réalisation de fonctionnalités répondant efficacement à leurs besoins, le framework est avant tout un outil répondant à nos exigences techniques et non l’inverse.
Il devient alors essentiel que nos choix architecturaux découlent d'une compréhension approfondie de nos besoins plutôt que pour satisfaire une paresse émanant de notre zone de confort.
Un éventail de possibilités
L'origine du MVC est parfaitement louable, créé à la fin des années 70 dans l’objectif d'améliorer le découplage des applications, ce n'est que bien plus tard que ce pattern s'est imposé pour devenir la référence que nous connaissons tous.
Depuis maintenant plus de 10 ans, le pattern est omniprésent dans le paysage des applications web en PHP, probablement porté par l'explosion en popularité des frameworks MVC tels que Zend ou CakePHP, pour les plus anciens, jusqu’à Symfony en passant bien évidemment par Laravel.
Il doit vous paraître évident qu’un cadre de travail généraliste, une boite à outils, ne devrait pas vous imposer un style d’architecture plutôt qu’un autre, pourtant, nous avons accepté ce choix systématique du MVC plébiscité par ces frameworks sans prendre le moindre recul critique.
Pour autant, des dérivés au MVC existent, du Model-View-Presenter (MVP) au Model–View–ViewModel (MVVM) chacun de ces patterns offrants des variations intéressantes aux classiques MVC permettant de répondre différemment aux enjeux de votre application et d’imaginer votre architecture autrement.
Une architecture modulaire sera une piste intéressante pour réorganiser les dossiers de votre application en mettant l'accent sur un découpage en modules de vos fonctionnalités, cette forme d'architecture est également peu contraignante à mettre en place et ne perturbera que peu l'organisation existante de votre Laravel.
Des architectures plus dogmatiques sont également envisageables comme le CQRS que nous vous avons présenté à plusieurs reprises ou bien encore l’architecture hexagonale à base de port et d’adapteur qui sera bien plus complexe à mettre en oeuvre mais offrira des perspectives intéressantes en termes de flexibilité et de séparation des préoccupations.
Si votre application développe une grande richesse fonctionnelle et se retrouve noyée sous sa logique métier, une approche Domain Driven Design (DDD), ou l'un de ses nombreux dérivés, pourrait également être extrêmement salvatrice pour votre application.
Ne vous battez pas contre votre framework, cela en vaudra rarement la peine, mais établissez toujours une limite claire sur les composants à coupler avec Laravel et laissez-le, autant que possible, éloigné du coeur de votre business.
Restez honnête
L’idée sous-jacente derrière cet article était simplement de souligner une certaine passivité concernant un choix d’architecture important que nous faisons tous, bien trop souvent, par défaut.
Le MVC reste bien évidemment un choix envisageable et totalement pertinent selon les besoins spécifiques de votre l'application, de la complexité de votre projet ou tout simplement des compétences de votre équipe.
Au fil des années, une absence de réflexion concernant votre architecture sera préjudiciable pour la pérennité et la bonne santé de votre application et vous risquez malheureusement de l’apprendre dans la douleur si aucune disposition n’est prise à temps.
Soyez de véritables artisans, restez pleinement maitre de vos outils et placer toujours l’architecture de vos projets au coeur de vos préoccupations !
Ni l’architecture ni un code propre n’insistent sur la perfection, uniquement sur l’honnêteté de faire de son mieux.
A lire
Autres articles de la même catégorie
Vous avez le droit de commenter
Et si parfois on s'autorisait à commenter notre code ?
Il y aura toujours des bugs
Quelqu'un qui pense qu'une application peut-être exempte de bugs est un fou.
Vous écrivez pour être lu
Les bons développeurs écrivent du code que les humains peuvent comprendre.