Ceci sera un récit des impressions sur le livre, ainsi qu'une analyse de certains concepts et connaissances qui, grâce à ce livre, ont été acquises.
Architecture
Pouvez-vous, en lisant cette publication, donner une réponse claire à la question : qu'est-ce que l'architecture ? Quelle est l'architecture dans le contexte de la programmation et de la conception ? Quel rôle joue-t-elle ? Il y a encore beaucoup d'ambiguïtés autour de ce terme. Tout semble clair, mais c'est d'une certaine manière abstrait et sans précision. Martin estime, et je suis d'accord avec lui, qu'une application a deux composantes :
- Le comportement (behavior) — les fonctions et les tâches que le programme (composant, service) exécute.
- L'architecture — ce terme est en grande partie lié à la modification de l'application.
Mais même si l'application accomplit très bien la tâche qu'elle doit réaliser, cela ne signifie pas qu'elle a une bonne architecture. L'architecture n'est pas une question de comportement de l'application. L'architecture concerne la facilité de modification, l'architecture concerne la facilité de déploiement, l'architecture concerne l'indépendance du développement. L'architecture concerne la rapidité avec laquelle un nouvel arrivant dans l'équipe comprend le système.
Et c'est ainsi que construire cette architecture, comment se débarrasser de la douleur lors de petits changements dans les exigences du PM ou des parties prenantes : c'est ce que le livre met en lumière.
À propos des auteurs
Avant de parler de ce livre, je voudrais dire un peu sur moi.
Actuellement, je suis un développeur Strong Junior, spécialisé dans le développement de services avec ASP .NET CORE.
Je travaille depuis un an dans une petite entreprise, et je gère plutôt bien.
J'ai déjà lu ce livre deux fois, et je le recommande à tous :
- aux développeurs de systèmes embarqués ;
- aux développeurs front-end ;
- aux développeurs back-end ;
- et même aux devops.
En gros, à tous ceux qui sont en quelque sorte impliqués dans le développement de logiciels, je veux dire le développement direct de divers logiciels ; les PM et autres ne sont pas inclus (bien que cela pourrait aussi être utile de comprendre pourquoi un dev peut mettre deux fois plus de temps sur une tâche), je recommande de lire ce livre.
Et maintenant, je vais essayer d'argumenter pourquoi je pense cela.
Un peu sur l’auteur de ce livre (car pour moi, l’autorité de l’écrivain joue un grand rôle). Je pense que vous me comprendrez, bien que ce ne soit pas toujours juste, mais si une personne autorisée dans le domaine vous parle, vous faites généralement plus confiance à ce qu’elle dit. Par exemple, je pense que vous croirez davantage au diagnostic posé par un médecin qu’à celui d’une personne lambda ayant simplement googlé des symptômes.
Robert Martin, également connu sous le nom d'Oncle Bob, travaille dans le domaine de la programmation, notamment dans divers systèmes (des services web aux systèmes embarqués), depuis 1970. Il est consultant technique et architecte, a écrit pour diverses revues techniques, est lui-même un programmeur très expérimenté et une personne qui a joué un rôle clé dans la création des célèbres principes SOLID (on peut dire qu'il en est le créateur). De plus, je tiens à ajouter que ce livre m’a été recommandé par mon team lead avec plus de 15 ans d'expérience.
À propos du livre
Dépendances
Avant de lire le livre, j'ai lu pas mal d'articles sur le même sujet, où un mot revenait souvent : 'dépendance'. Qu'est-ce que c'est, qui dépend de qui, que signifie exactement 'dépendre', et comment une certaine classe peut-elle dépendre d'une autre ?
Et au fur et à mesure que je lisais le livre, j'ai compris deux choses :
La dépendance est un terme signifiant qu’une classe (composant, service) connaît une autre classe (composant, service), et cette connaissance est définie au niveau du code (à présent, les développeurs Java, C#, C sont sur la même longueur d’onde) par une certaine importation de namespace. En d'autres termes : si vous avez la classe A avec le namespace Default.Classes et la classe B avec Another.Classes. Ainsi, si le code source de la classe A contient 'using Another.Classes ;' — cela signifie que la classe A dépend de la classe B.
Pour comprendre sur le schéma, où se trouve la classe dépendante et où ne le sont pas — regardez la direction de la flèche : dans 1), la flèche pointera de la classe A vers la classe B. Cela signifie que la classe B est plus indépendante que la classe A. Et les changements dans la classe A ne causeront aucun "dommage" à la classe B.
SOLID
L'une des principales raisons qui m'a poussé à lire ce livre est l'explication des principes SOLID à la source, car Oncle Bob a développé ces principes et on peut dire que grâce à lui, nous entendons ce nom : SOLID.
Pour ceux qui ne sont pas au courant, ces principes recommandent de concevoir vos applications selon 5 règles :
S — SRP (Principe de responsabilité unique)
O — OCP (Principe ouvert-fermé)
L — LSP (Principe de substitution de Liskov)
I — ISP (Principe de séparation des interfaces)
D — DIP (Principe d'inversion des dépendances)
Tous ces principes peuvent être appliqués au niveau des classes et des objets, au niveau des modules et des composants, ainsi qu'au niveau des couches (services).
Si vous pensez que le principe de responsabilité unique concerne un classe ou un module ne doit faire qu'une seule chose, vous devez absolument lire au moins le chapitre sur SOLID. En effet, la définition donnée ci-dessus est une conséquence, mais pas la définition même du principe.
Sur l'inversion des dépendances
Je veux attirer une attention particulière sur l'explication du principe d'inversion des dépendances (celui qui est D dans SOLID). En lisant le livre, j'ai compris que ce n'est pas juste un principe, mais aussi un mécanisme et un outil grâce auquel vous pouvez changer la direction de vos dépendances, et rendre, par exemple, la logique métier (DOMAIN) indépendante des détails de mise en œuvre de la couche d'accès aux données (DAL).
Bien que le principe, comme les autres dans SOLID, signifie un peu moins que le mécanisme, ce même mécanisme est utilisé tout au long du livre et c'est l'un des principaux moyens d'inverser et de changer la direction de vos dépendances, qui d'ailleurs est utilisé dans DDD.
Sur la prise de décisions architecturales
Le livre mentionne très souvent le principe de prise de décisions architecturales importantes : quel SGBD utiliser, quel framework adopter, quelle bibliothèque intégrer, quel moteur de recherche utiliser, etc.
Ainsi, l'auteur estime que vous devez prendre le moins de décisions de ce type POSSIBLE. En effet, les exigences peuvent changer, les contraintes de performance aussi, et le comportement a tendance à varier. Au cours du développement, une certaine décision peut sembler moins efficace qu'une autre, moins pratique qu'une autre. Et la force de votre architecture déterminera à quelle vitesse et sans douleur vous pourrez remplacer une technologie par une autre (d'ailleurs, c'est ce que dit l'OCP).
Par exemple, soudainement, vous décidez d'utiliser MongoDB à la place de PostgreSQL, ou même des fichiers, ou d'utiliser des données mockées, dont les opérations seraient effectuées en mémoire. Et dans certaines conditions, cela peut obliger à réécrire presque toute la logique.
Pour éviter de telles situations, nous pouvons utiliser certains mécanismes qui repoussent au maximum le moment de la prise de décision. L'un de ces mécanismes est l'abstraction.
Références au DDD
DDD — Domain Driven Design — est une approche de développement de services avec une logique métier complexe, critique aux changements, qui vise une compréhension maximale des postes de direction dans le projet (PMs, responsables des ventes, etc.) par les membres de l'équipe. Cela signifie qu'il doit y avoir un langage omniprésent entre tous les membres du projet, ce qui permet à chacun de comprendre l'autre et de penser dans un même domaine avec des règles commerciales identiques.
Si vous êtes un partisan du DDD, ou si vous souhaitez le devenir, ou si vous ne comprenez pas encore tout mais désirez comprendre — ce livre est incontournable, en particulier la deuxième partie.
Ici, l'auteur explique l'existence de la Règle de Dépendance, et pourquoi, en la suivant, vous construirez la bonne architecture d'application. Pourquoi les dépendances doivent suivre la direction des composants de Haute Politique, pourquoi domaine (Un composant de Haute Politique) doit être indépendant de l'infrastructure et comment cela facilitera votre déploiement et développement
Abstraction
Tonton Rob explique également comment les détails d'implémentation peuvent nuire à votre système et l'empêcher d'évoluer sans douleur par la suite.
N'oubliez pas !
La BD est un détail d'implémentation
Les Clients (Web, Mobile, etc.) sont des détails d'implémentation
Les Frameworks sont des détails d'implémentation
Il est essentiel de s'abstraire au maximum de tout cela et de ne pas en dépendre, en utilisant l'Inversion de Dépendance décrite ci-dessus avec des interfaces et des abstractions, la Règle de Dépendance et d'autres mécanismes.
Méthodes de construction de modules
Cette section m'a particulièrement plu en tant que développeur de services sur ASP .NET CORE. Car elle traite des méthodologies de construction d'une architecture de service unifiée à partir de composants existants.
Robert a décrit 4 schémas possibles de séparation des couches.
Il a fait comprendre pourquoi le mécanisme si souvent utilisé de l'architecture à 3 couches : UI (contrôleurs), Services (Domaine), DAL (Base de données) — est assez mauvais par rapport à d'autres. J'ai vu assez peu de projets, mais dans chacun, par exemple dans un micro-service, l'architecture à trois couches est justement utilisée à l'arrière-plan.
De plus, l'architecture un-composant-un-service est également utilisée assez souvent. Dans l'ensemble, les deux sont raisonnables, mais cette approche présente de nombreux inconvénients, notamment par rapport à la façon dont l'architecture est construite avec l'utilisation de DDD, en particulier pour les services critiques aux modifications et complexes.
Eh bien, cet aperçu du livre touche à sa fin. J'ai beaucoup aimé le livre, je ne regrette pas ma lecture, merci à l'auteur. À vous, chers lecteurs, merci pour votre attention, ne jugez pas trop sévèrement — cette publication est basée sur mes impressions de lecture et mon enthousiasme personnel.
Source : habr.com
