From 0224c6c35b2157d0a7eb1a8df915efca2edbf579 Mon Sep 17 00:00:00 2001 From: Fred Date: Fri, 30 Jul 2021 15:51:39 +0200 Subject: [PATCH] =?UTF-8?q?Mise=20=C3=A0=20jour=20de=20'source/part-1-work?= =?UTF-8?q?space/maintainable-applications/clean=5Farchitecture.adoc'?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../clean_architecture.adoc | 33 +++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/source/part-1-workspace/maintainable-applications/clean_architecture.adoc b/source/part-1-workspace/maintainable-applications/clean_architecture.adoc index 87ec89b..e7405b2 100644 --- a/source/part-1-workspace/maintainable-applications/clean_architecture.adoc +++ b/source/part-1-workspace/maintainable-applications/clean_architecture.adoc @@ -28,3 +28,36 @@ Une architecture ouverte et pouvant être étendue au travers de plug-in n’a d développement est suivi et que les gestionnaires (et architectes) s’engagent à économiser du temps et de la qualité lorsque des changements seront demandés pour l’évolution du projet. +==== Considération sur les frameworks + +[quote] +---- +Frameworks are tools to be used, not architectures to be conformed to. +Your architecture should tell readers about the system, not about the frameworks you used in your system. +If you are building a health care system, then when new programmers look at the source repository, +their first impression should be, « oh, this is a health care system ». +Those new programmers should be able to learn all the use cases of the system, +yet still not know how the system is delivered. +-- Robert C. Martin, Clean Architecture, page 199 +---- + +Le point soulevé ci-dessous est qu'un framework n'est qu'un outil, et pas une obligation de structuration. +L'idée est que le framework doit se conformer à la définition de l'application, et non l'inverse. +Dans le cadre de l'utilisation de Django, c'est un point critique à prendre en considération: 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, indépendamment +- Votre couche de présentation sera surtout disponible au travers d'un navigateur +- Les droits d'accès et permissions seront en grosse partie gérés par le frameworks +- La sécurité dépendra de votre habilité à suivre les versions +- Et 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. + +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.