Considérations

Considérations sur les frameworks

Un framework n’est qu’un outil, et pas une obligation de structuration. L’idée sous-jacente est que le framework doit se conformer à la définition de l’application, et non l’inverse cite:[clean_architecture(196)] : en général, mais également dans le cadre de l’utilisation de Django, c’est un point critique à prendre en considération, car une fois que vous aurez fait ce choix, vous aurez extrêmement difficile à faire machine arrière :

• Votre modèle métier sera largement couplé avec le type de base de données (relationnelle, ici),
• Votre couche de présentation sera surtout disponible au travers d’un navigateur,
• Les droits d’accès et permissions seront en grosse partie intégrés directement au framework,
• La sécurité dépendra de votre habilité à suivre les versions,
• Les fonctionnalités complémentaires (que vous n’aurez pas voulu/eu le temps de développer) dépendront de la bonne volonté de la communauté.

Le point à comprendre ici n’est pas que “Django, c’est mal”, mais qu’une fois que vous aurez défini la politique, les règles métiers, les données critiques et entités, et que vous aurez fait le choix de développer en âme et conscience votre nouvelle création en utilisant Django, vous serez bon gré mal gré, contraint de continuer avec. Cette décision ne sera pas irrévocable, mais difficile à contourner.

“At some point in their history most DevOps organizations were hobbled by tightly-coupled, monolithic architectures that while extremely successfull at helping them achieve product/market fit - put them at risk of organizational failure once they had to operate at scale (e.g. eBay’s monolithic C++ application in 2001, Amazon’s monolithic OBIDOS application in 2001, Twitter’s monolithic Rails front-end in 2009, and LinkedIn’s monolithic Leo application in 2011). In each of these cases, they were able to re-architect their systems and set the stage ot only to survice, but also to thrise and win in the marketplace. cite:[devops_handbook]”

Ceci dit, Django compense ses contraintes en proposant énormément de flexibilité et de fonctionnalités out-of-the-box, c’est-à-dire que vous pourrez sans doute avancer vite et bien jusqu’à un point de rupture, puis revoir la conception et réinvestir à ce moment-là, mais en toute connaissance de cause. La difficulté à se passer du framework va surtout consister à basculer vers “autre chose” et a remplacer chacune des tentacules qui aura poussé partout dans l’application.

Astuce

A noter que les services et les “Architectures Orientées Services” ne sont jamais qu’une définition d’implémentation d’un périmètre et de frontières, dans la mesure où un service n’est jamais qu’une fonction appelée au travers d’un protocole (REST, SOAP, …).

Ainsi, une application monolotihique sera tout aussi fonctionnelle qu’une application découpée en microservices. Juste qu’elles auront chacune leurs poins positifs et négatifs, et que le choix de l’une ou de l’autre ne sera jamais qu’une affaire de compromis cite:[software_architecture]

Considérations sur l’inversion de dépendances

Dans la partie SOLID, nous avons évoqué plusieurs principes de développement. Django est un framework qui évolue, et qui a pu présenter certains problèmes liés à l’un de ces principes.

Les Releases Notes de Django 2.0 date de décembre 2017; parmi ces notes, l’une d’elles cite l’abandon du support d’Oracle 11.2. En substance, cela signifie que le framework se chargeait lui-même de construire certaines parties de requêtes, qui deviennent non fonctionnelles dès lors que l’on met le framework ou le moteur de base de données à jour. Réécrit, cela signifie que:

• Si vos données sont stockées dans un moteur géré par Oracle 11.2, vous serez limité à une version 1.11 de Django,
• Tandis que si votre moteur est géré par une version ultérieure, le framework pourra être mis à jour.

Nous sommes dans un cas concret d’inversion de dépendances ratée: le framework (et encore moins vos politiques et règles métiers) ne devraient pas avoir connaissance du moteur de base de données. Pire, vos politiques et données métiers ne devraient pas avoir connaissance de la version du moteur de base de données.

En conclusion, le choix d’une version d’un moteur technique (la base de données) a une incidence directe sur les fonctionnalités mises à disposition par votre application, ce qui va à l’encontre des 12 facteurs (et des principes de développement).

Ce point sera rediscuté par la suite, notamment au niveau de l’épinglage des versions, de la reproduction des environnements et de l’interdépendance entre des choix techniques et fonctionnels.