120 lines
7.5 KiB
Plaintext
120 lines
7.5 KiB
Plaintext
[quote]
|
||
----
|
||
If you think good architecture is expensive, try bad architecture
|
||
-- Brian Foote and Joseph Yoder
|
||
----
|
||
|
||
|
||
[quote]
|
||
----
|
||
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.
|
||
|
||
==== Politiques et règles métiers
|
||
|
||
TODO: Un p'tit bout à ajouter sur les méthodes de conception ;)
|
||
|
||
|
||
==== 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.
|
||
|
||
> 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 not only to survice, but also to thrise and win in the marketplace
|
||
> The DevOps Handbook, Part III - The Principles of Flow - Architect for low-risk release (page 182)
|
||
|
||
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.
|
||
|
||
[quote]
|
||
----
|
||
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.
|
||
|
||
NOTE: A noter que les services et les « architectures orientées services » ne sont jamais qu’une définition
|
||
d’implémentation des frontières, dans la mesure où un service n’est jamais qu’une fonction appelée au travers d'un protocole
|
||
(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.
|
||
|
||
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.
|