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

A computer program is a detailed description of the policy by which inputs are transformed into outputs.
-- Robert C. Martin, Clean Architecture

Au delà des principes SOLID dont il est question plus haut, c’est à nouveau dans les ressources proposées et les cas démontrés que l’on comprend leur intérêt: plus que de la définition d’une architecture adéquate, c’est surtout dans la facilité de maintenance d’une application que ces principes s’identifient.

Derrière une bonne architecture, il y a aussi un investissement quant aux ressources qui seront nécessaires à faire évoluer l’application. Ne pas investir dès qu’on le peut va juste lentement remplir la case de la dette technique.

Good architecture makes the system easy to understand, easy to develop, easy to maintain and easy to deploy. The ultimate goal is to minimize the lifetime cost of the system and to maximize programmer productivity. — Robert C. Martin, Clean Architecture, Chapitre 15, what is architecture ?, page 137

L’objectif d’une bonne architecture est également de garder le plus d’options possibles, de se concentrer sur les détails (le type de base de données, la conception concrète, …​), le plus tard possible, tout en conservant la politique principale en ligne de mire. Cela permet de délayer les choix techniques à « plus tard », ce qui permet également de concrétiser ces choix en ayant le plus d’informations possibles. — Robert C. Martin, Clean Architecture, page 141 - What is architecture ?

Une architecture ouverte et pouvant être étendue n’a d’intérêt que si le 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

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.

When any of the external parts of the system become obsolete, such as the database, or the web framework,
you can replace those obsolete elements with a minimum of fuss.
-- Robert C. Martin, Clean Architecture, page 209

Avec Django, la difficulté à se passer du framework va consister à basculer vers « autre chose » et a remplacer chacune des tentacules qui aura pousser partout dans l’application.