Mise à jour de 'source/part-1-workspace/maintainable-applications/clean_architecture.adoc'

source/part-1-workspace/maintainable-applications/clean_architecture.adoc

@@ -84,3 +84,23 @@ d’implémentation des frontières, dans la mesure où un service n’est jamai
 (rest, soap, ...).
 Une application monolotihique est tout aussi fonctionnelle qu’une application découpée en microservices. 
 (Services: great and small, page 243).
+
+==== Un point 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 [https://docs.djangoproject.com/en/2.0/releases/2.0/](release notes) de Django 2.0 date de décembre 2017; parmi ces notes, 
+l'une d'elles cite l'abandon du support d'[https://docs.djangoproject.com/en/2.0/releases/2.0/#dropped-support-for-oracle-11-2](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:
+
+1. 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
+2. 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.
+
+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.