Ce sera une histoire sur l'impression du livre, ainsi que certains concepts et connaissances qui, grâce à ce livre, ont été étudiés
L'architecture
Pouvez-vous, en lisant cette publication, donner une réponse claire à la question, qu'est-ce que l'architecture? Qu'est-ce que l'architecture dans le contexte de la programmation et du design? Quel rôle joue-t-elle? Il y a beaucoup d'ambiguïtés dans ce terme. Et tout semble clair, mais en quelque sorte abstrait et sans précision. Martin estime, et je suis d'accord avec lui, que la demande comporte deux volets:
- Comportement (comportement) - fonctions et tâches exécutées par le programme (composant, service).
- Architecture - ce terme désigne davantage la modification des applications.
Mais même si l'application exécute très bien la tâche qu'elle doit effectuer, cela ne signifie pas du tout qu'elle a une bonne architecture. L'architecture ne concerne pas le comportement des applications. L'architecture concerne la facilité de changement, l'architecture concerne la facilité de déploiement, l'architecture concerne l'indépendance du développement. L'architecture concerne la vitesse à laquelle la compréhension vient à une nouvelle personne dans une équipe
Et voici comment construire cette architecture, comment se débarrasser d'un mal de tête avec un petit changement dans les exigences de PM ou d'une partie prenante: c'est ce que le livre dira
À propos des auteurs
Avant de dire quoi que ce soit à propos de ce livre, je veux parler un peu de moi.
En ce moment, je suis un développeur junior fort spécialisé dans le développement de services via ASP .NET CORE.
Je travaille sur une "galerie" depuis un an maintenant, et il me semble que je fais un peu
J'ai déjà lu ce livre 2 fois et je le recommande à tous de lire:
- développeurs de systèmes embarqués;
- endchikers avant;
- endossement au dos;
- et même devopsam.
En général, pour quiconque est au moins en quelque sorte lié au développement du PP, je veux dire le développement direct des différents Saylov et PM'ov ici, nous ne prenons pas en compte ici (bien qu'il serait également utile de savoir pourquoi une femme de chambre passe parfois 2 fois plus de temps sur une tâche), je vous conseille de lire ce livre.
Et maintenant, je vais essayer de faire valoir pourquoi je pense que oui
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 correct, mais si une personne faisant autorité dans le domaine vous dit quelque chose, vous montrez beaucoup plus de confiance dans ce qu'il a dit. Par exemple, je pense que vous préférez croire au diagnostic que le médecin vous pose plutôt qu'à une personne de la foule (google les symptômes)
Robert Martin - alias Ankle Bob (Uncle Bob) - travaille dans le domaine de la programmation et de divers systèmes (des services Web aux systèmes intégrés) depuis 1970. Il est consultant technique et architecte, il a écrit dans diverses revues techniques, il est un programmeur très expérimenté et une personne qui a joué l'un des rôles clés dans la création des principes SOLID bien connus (vous pouvez dire le créateur). Aussi, je veux ajouter que mon chef d'équipe avec plus de 15 ans d'expérience m'a conseillé sur ce livre
À propos du livre
Dépendances
Avant de lire le livre, j'ai lu pas mal d'articles sur le même Habré, où apparaissait un mot comme «dépendance». De quoi s'agit-il, qui dépend de qui, que signifie exactement «dépendre de» et comment une classe peut-elle dépendre de quelqu'un?
Et en lisant le livre, j'ai appris deux points:
La dépendance est un terme signifiant qu'une classe (composant, service) connaît une autre classe (composant, service), et cette connaissance au niveau du code est déterminée (maintenant les javists, sharpists, sishniks me comprendront) par une certaine importation d'espace de noms . En d'autres termes: vous avez une classe A avec un espace de noms Default.Classes et une classe B Another.Classes. Donc, si le code de classe A apparaît en utilisant Another.Classes; - cela signifie que la classe A dépend de la classe B.
Pour comprendre selon le schéma où se trouve la classe dépendante et où non - regardez le sens de la flèche: 1) la flèche pointera de la classe A dans le sens de la classe B. Cela signifie que la classe B est plus indépendante que la classe A. Et les changements dans la classe A , aucun «dommage» à la classe B
SOLIDE
L'une des principales raisons de la lecture de ce livre a été l'explication des principes SOLID à partir de la source originale, car l'oncle Rob a développé ces principes et nous pouvons dire que grâce à lui, nous entendons ce nom - SOLID.
Pour ceux qui ne sont pas au courant - ces principes sont énoncés et conseillés pour concevoir leurs 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égrégation des interfaces)
D - DIP (principe d'inversion de dépendance)
Tous ces principes peuvent être appliqués au niveau des classes et des objets, au niveau des modules et composants, et au niveau des rails (services).
Si vous pensez que le principe de responsabilité unique concerne le fait que la classe ou le module ne devrait faire qu'une seule chose, alors vous devriez certainement lire au moins le chapitre sur Solid. Car la définition donnée ci-dessus est une conséquence, mais pas la définition du principe lui-même
À propos de l'inversion de dépendance
Je veux prêter une attention particulière à l'explication du principe d'inversion de dépendance (celui que D est de SOLID). Au cours de la lecture du livre, j'ai compris que ce n'est pas seulement un principe, c'est aussi un mécanisme et un outil avec lesquels vous pouvez changer le sens de vos dépendances et rendre, par exemple, la logique métier (DOMAIN) indépendante des détails de l'implémentation de la couche d'accès aux données (DAL'a)
Bien que le principe lui-même avec les autres dans SOLID signifie quelque chose d'autre que le mécanisme, le mécanisme lui-même est utilisé tout au long du livre, et c'est l'une des principales méthodes pour inverser et changer la direction de vos dépendances, qui d'ailleurs est utilisée avec DDD
Prendre des décisions architecturales
Très souvent, le livre mentionne le principe de la prise de décisions architecturales importantes: quelle base de données utiliser, quel cadre utiliser, quelle bibliothèque connecter, quoi utiliser comme moteur de recherche, etc.
Donc, l'auteur croit: vous devriez DÈS QUE POSSIBLE prendre ce genre de décision. Parce que les exigences peuvent changer, les restrictions de performances aussi, le composant comportemental lui-même a tendance à changer. Au cours du processus de développement, une solution 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 pouvez remplacer une technologie par une autre (OCP le dit d'ailleurs).
Par exemple, tout d'un coup, vous décidez d'utiliser MongoDb au lieu de Postgresql, ou des fichiers en général, ou d'utiliser des données simulées, dont les opérations seront effectuées en mémoire. Et sous certaines conditions - cela peut permettre de réécrire presque toute la logique.
Pour éviter de telles situations, nous pouvons utiliser certains mécanismes qui repousseront le plus possible le temps de prise de décision. L'un de ces mécanismes est l'abstraction.
Références DDD
DDD - Domain Driven Design - une approche de développement de services avec une logique métier complexe, critique aux changements, qui vise à maximiser la compréhension des postes de gestion de projet (PM, directeurs des ventes, etc.), avec des rameurs. Autrement dit, il y aurait un langage omniprésent entre tous les membres du projet, et tout le monde pourrait comprendre l'autre, et que tout le monde pense dans le même domaine avec les mêmes règles commerciales.
Si vous êtes un partisan de DDD, ou si vous voulez en être un, ou si vous ne comprenez pas quelque chose à ce sujet, mais que vous voulez comprendre, le livre est une lecture incontournable, en particulier la deuxième partie du livre.
Ici, l'auteur explique l'existence de la règle de dépendance et pourquoi, à la suite de celle-ci, vous construirez l'architecture d'application appropriée. Pourquoi les dépendances devraient suivre envers les composants High Policy, pourquoi le domaine (composant High Policy) devrait être indépendant de l'infrastructure et comment cela simplifiera le déploiement et le développement pour vous
Abstraction
Oncle Rob explique également comment les détails de mise en œuvre peuvent endommager votre système et l'empêcher d'évoluer sans douleur à l'avenir.
N'oubliez pas!
DB est un détail d'implémentation
Clients (Web, Mobile, etc.) - détails d'implémentation
Les cadres sont un détail d'implémentation.
Il est nécessaire d'abstraire autant que possible et de ne pas en dépendre, en utilisant l'inversion de dépendance décrite ci-dessus avec des interfaces et des abstractions, une règle de dépendance et d'autres mécanismes
Méthodes de construction de modules
J'ai particulièrement aimé cette section en tant que développeur de services sur ASP .NET CORE. Car il décrit les méthodologies de construction d'une architecture de service unifiée à partir de composants prêts à l'emploi.
Robert a décrit 4 schémas de séparation de couches possibles.
Il a expliqué pourquoi le mécanisme si souvent utilisé de l'architecture à 3 couches: interface utilisateur (contrôleurs), services (domaine), DAL (base de données) - est suffisamment mauvais par rapport aux autres. Je n'ai pas vu beaucoup de projets, mais dans chacun, par exemple, un micro-service, à l'arrière, il utilise une architecture à trois couches.
De plus, assez souvent, une architecture à un composant et à un service est utilisée. En général, ils sont tous les deux bons, mais ils présentent de nombreux inconvénients, en comparaison, par exemple, comment l'architecture est construite à l'aide de DDD, en particulier lorsqu'elle est critique pour changer, et des services complexes.
En général, cette critique du livre a pris fin. J'ai vraiment aimé le livre lui-même, je ne regrette pas ce que j'ai lu, merci à l'auteur. Merci de votre attention, chers lecteurs, ne jugez pas strictement - cette publication est basée sur l'impression du livre et mon enthousiasme personnel
MISE À JOUR 1.0
Au cours des discussions, il peut être entendu que le changement de stockage SOUDE et FACILE ne sera pas facile, d'une manière ou d'une autre. Dans certains cas, même une abstraction et une encapsulation très douloureuses et pourtant de l'accès au magasin, on peut douter de ce qui aggravera la situation, mais plutôt un peu mieux, du moins en raison de l'indépendance de la composante variable des autres.